Analyze Exceptions and Log Messages

Content
Goal of this HowTo Scenario Requirements Detailed Steps Prepare your own application Montoring Functional Health Identifying Errors Identifying Exceptions Identify Root Cause of Error Logs Automatically capturing PurePath on exception Conclusion Author: Usability: Review: Michael Kopp

Goal of this HowTo

Any application has errors and exceptions from time to time. The normal logging functionality of application makes it often hard to identify the root cause of the problem though. In this HowTo you will learn how you can use dynaTrace to diagnose the root cause of exceptions and error log messages.

Scenario
For this scenario you can either use the attached easyTravel session or use your own application with dynaTrace injected.

Requirements
dynaTrace Client if you work with the attached session Any Application with dynaTrace agent injected

Detailed Steps
Prepare your own application
If you use your own application simply make sure that the Exception and Logging Sensors are placed which they should be on default. The Java Exception Sensor will not capture any JDK exception on default, you can change this in your system profile. Go to the appropriate Agent Group to the Sensor Configuration. Once there click on Properties for the Exception Sensor (or .NET Exceptions for .NET).

For logging dynaTrace will only capture errors and warnings normally. If you want to capture DEBUG messages you can change this in the Sensor Configuration as well. This can be found in the Properties of the Logging and .NET Logging Sensor.

Capturing DEBUG logging will lead to considerable overhead in your application

dynaTrace detects errors in your application using a configurable set of error detection rules. These rules base on exceptions, HTTP response codes, and log messages. Errors by transaction will be counted, the node triggering the error will be marked in the PurePath, and, optionally, the transaction can be marked as failed. Error detection rules are configured per system profile, with a number of out-of-the-box rules to cover main problems in applications, e.g., unhandled exception thrown outside transaction scope or HTTP 500 responses, already provided. For details on configuring error detection rules, see System Profile - Error Detection.

Montoring Functional Health

For a quick overview on the functional health of your application, you can use the [Functional Health Overview] dashlet which provides you with an overview on transaction load and failure rate compared to another time frame. Either from there or directly via Diagnose Events/Errors you can head to the [Errors dashlet] which shows you an overview on all errors detected in a timeframe.

Identifying Errors
The Errors dashlets is split into the Error Overview Pane (top) and the Error Details Pane (bottom). The overview pane provides you with an overview on errors and their occurrences, while the details pane shows information on the exception class together with the exception message for the selected group of error rules or a single rule.

Identifying Exceptions
Either go to your system profile or use the attached session\. Go to Diagnose Events and open the Exceptions dashlet. This will show you all exceptions that occurred in the stored session or in the PurePaths of your live session. You will see not only the exception class itself, but also the message, which class threw the exceptions and how often it occurred. Right click and use the Drill down to PurePath to identify exactly where it came from and use the PurePath to analyze why it happened

If you want to know which transaction triggered this you can simply drill down to Business Transactions (if you have any for your application) or Web Requests.

Identify Root Cause of Error Logs

Identifying root cause of log messages works exactly the same. Simply choose the Logging dashlet instead of the Exceptions. You can again drill down to the PurePath and analyze exactly why it happened.

Automatically capturing PurePath on exception

Especially in production or load test environments it is not always possible to check exceptions right away. There it makes sense to automatically store the Transaction with certain exceptions for later analysis. To this we have to define subscribe a measure and define an incident. The easiest way to do this is to this from the exception dashlet. Simply right click on the exception that you are interested in and subscribe a measure for it (give it a nice name!). Set the Severe Threshold to 1. Please note: you can only try this in a running application - either your own or easyTravel. There are no images attached to this page. Now that the measure is subscribed open the system profile and go to the measure section. Look for your new measure. If you have not forgotten to set the threshold you will notice that the "Create Incident Rule" button is enabled, click it. (if it is not edit the measure and set a threshold).

On the Actions tab you can configure additional actions to be taken should an incident occur. For example, an email notification can be configured. There are no images attached to this page. Now whenever the exception occurs you will get an incident and you can then drill down to the PurePaths. In case the exception happens multiple times you will get a single incident with multiple PurePaths attached to it.

Conclusion
Identifying exactly where and why exceptions happened is very easy with dynaTrace.