Author: Michael Kopp

Usability:  

Review:  

Analyze Exceptions and Log Messages

Content

Goal of this HowToScenarioRequirements

Detailed StepsPrepare your own applicationMontoring Functional HealthIdentifying ErrorsIdentifying ExceptionsIdentify Root Cause of Error LogsAutomatically capturing PurePath on exception

Conclusion

Goal of this HowToAny application has errors and exceptions from time to time. The normal logging functionality of application makes it often hard to identify the rootcause 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 or use your own application with dynaTrace injected.attached easyTravel session

Requirements

dynaTrace Client if you work with the attached sessionAny 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 JavaException Sensor will not capture any JDK exception on default, you can change this in your system profile. Go to the appropriate toAgent Groupthe 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 theSensor 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 responsecodes, and log messages. Errors by transaction will be counted, the node triggering the error will be marked in the PurePath, and, optionally, thetransaction can be marked as failed. Error detection rules are configured per system profile, with a number of out-of-the-box rules to cover mainproblems in applications, e.g., unhandled exception thrown outside transaction scope or HTTP 500 responses, already provided. For details onconfiguring 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 dashlet which provides you with[Functional Health Overview]an overview on transaction load and failure rate compared to another time frame. Either from there or directly via Diagnose Events/Errors you canhead to the which shows you an overview on all errors detected in a timeframe.[Errors dashlet]

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 anoverview on errors and their occurrences, while the details pane shows information on the exception class together with the exception messagefor the selected group of error rules or a single rule.

Identifying Exceptions

Either go to your system profile or use the . Go to Diagnose Events and open the Exceptions dashlet. This will show you allattached session\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 themessage, which class threw the exceptions and how often it occurred. Right click and use the Drill down to PurePath to identify exactly where itcame 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) orWeb 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 drilldown 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 automaticallystore the Transaction with certain exceptions for later analysis. To this we have to define subscribe a measure and define an incident. The easiestway 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 forgottento 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 beconfigured.

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 multipletimes you will get a single incident with multiple PurePaths attached to it.

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