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.

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 transaction table has a column for each policy violation type and you can sort the table by clicking on the column headers. Transactions are not shown in the form of a call tree, but completely flat. This means that it also shows transactions that are not entry points but only invoked as nested transactions. For detailed analysis, go to the data views.

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.

The drop-downs at the top provide three ways to adjust the range of the displayed transactions in the dashboard: