Configuration

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

Policies create the following anomalous transaction states:

• Slow

  The threshold after which a transaction is classified as slow can be specified as an absolute time or as a relative percentage value with respect to the average duration of transactions that are generated by this transaction definition.

• Very slow

  Another time-based threshold like "Slow", only for a more severe category. You can partition "Slow" and "Very slow" so that "Slow" transactions can occur without notifications and "Very slow" transactions trigger notifications.

• Overdue

  After a third time-based threshold which is usually an absolute time and much larger than the "Very slow" threshold, you can view a transaction as deadlocked or hanging.

• Error

  Transactions that result in an error require special attention. There are three sources of errors:

  1. Exceptions

     Exceptions derived from java.lang.Error (errors), java.lang.RuntimeException (runtime exceptions) and java.lang.Exception (checked exceptions) can be activated separately. Checked exceptions are usually handled by the application and do not necessarily result in a transaction error.

  2. Logged errors

     If your application logs an error with a logging framework, perfino can mark the transaction with an error. java.util.logging, log4j, JBoss logging and Logback are supported by perfino. Optionally, you can also configure that warnings result in a transaction error.

  3. Specific conditions

     Certain transaction types have their own built-in error conditions. For example, as shown in the screen shot above, web transactions can use the HTTP status code to detect an error. By default, all status codes >= 400 are handled as errors. If some of these status codes should not be viewed as errors, you can list them here.

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.