Policies


Configuration

Policies detect anomalous conditions with respect to transactions. Each transaction definition has associated policy definitions.

Policies create the following anomalous transaction states:

If policies are not defined for a transaction definition, perfino continues in the list of transaction definitions until it finds a matching entry where policy definitions are enabled. This allows you to define the same policies for multiple transaction definitions, in the most extreme case with a "catch-all" entry that has no naming definition, but only policy definitions.

Sometimes, you want to go the other way and define more granular policies for certain transactions within a single transaction definition. For example, you might have a single EJB transaction definition which captures all your business transactions. If the acceptable durations depend on the transaction name, you can define policy specializations to avoid having to re-add the transaction definition and its naming scheme multiple times.

Unlike the parent transaction definition, which filters classes in this case, the policy specialization filters on the result of the transaction naming.

Policies in the call tree

Both call tree and hot spots views have a policy mode drop-down at the top. By default, the call tree is split for different policy violations. For example, this means that you can see slow transactions separately from normal transactions. This is important, since the cause of a slow transaction will often be visible from nested transactions or a slow database statement. Transactions with policy violations show their transaction type icon in the color of the policy violation so you can easily spot them in the call tree.

When you set the policy mode to "merged", all policy splits are added so that there is only one transaction of the same name and type on the same call tree level.

In the screen shot above, you can also see the policy selector at the bottom the view. By default it is set to "All". If you choose a particular policy violation type, the tree will be filtered immediately. For example, selecting "Error" will show all transactions that have been marked as an error, regardless how deep they are in the call tree. These transactions will be expanded and all ancestor nodes are shown, even if they are not transactions with errors. When you also add a filter text, only transactions with errors will be searched for the filter expression.

Policies in the dashboard

The dashboard is your first stop for checking the health of your application. That's why policy violations are featured prominently in the dashboard. The problems view shows transactions with policy violations. By default, "Overdue", "Error" and "Very slow" are displayed. With the configure above the problems view you can select different policy violations and set absolute and percentage limits for each policy violation type. As in the transaction table, problems can originate from transactions that are not entry points but only invoked as nested transactions. For a detailed analysis, click on the problem row to go to the call tree view in the "VM data views" tab.

To visualize the proportion of policy violations with respect to the total amount of transactions, a policy pie chart is shown next to the transaction table. Numbers and percentages are shown as tool tips and by clicking on the legend entries, you can hide selected policy violation types.

Clicking on the slices of the pie chart will take you to the call tree view in the "VM data views" tab and set the filter drop-down below the call tree to the selected policy violation type.