Skip to content
CA Application Performance Management - 10.2
Documentation powered by DocOps

Configure ErrorDetector

Last update October 14, 2016

Contents

ErrorDetector allows IT teams to:

  • Determine the frequency of anomalous transactions
  • Determine whether logged exceptions affect users
  • See exactly where errors occurred within the transaction path
  • Obtain the information that is required to reproduce, diagnose, and eliminate serious errors

Verify Prerequisites for ErrorDetector

Before you enable ErrorDetector:

Types of Errors

We defined criteria to describe serious errors, which are based on information that is contained in the J2EE/.NET specifications. ErrorDetector considers both errors and exceptions to be errors. The most common type of error is a thrown exception.

Some examples of common errors are:

  • HTTP errors (404, 500)

    Note: Occasionally, HTTP 404 errors originate in a web server instead of an application server. If such an incident occurs, ErrorDetector cannot detect the web server error through the agent.
  • SQL statement errors
  • Network connectivity errors (timeout errors)
  • Backend errors (for example, cannot send a message through JMS, cannot write a message to the message queue)

If you do not consider some of the errors ErrorDetector tracks to be important, you can ignore them. To track more errors, you can use error tracers to create new directives to trace them.

Advanced Error Data Capture

Although ErrorDetector captures many common error types by default, We provide options for customizing error detection.

You can use the following error-related tracers to create ProbeBuilder Directives (PBDs) to capture errors.

  • ExceptionErrorReporter reports standard exceptions.
  • MethodCalledErrorReporter reports when specific methods get called.
  • ThisErrorReporter reports a current object as an error.
  • HTTPErrorCodeReporter captures HTTP error codes and associated error messages.

Place any new directives that you create with the tracers in the errors.pbd file in the <Agent_Home> directory.

Important! The default errors.pbd is designed to report serious errors, while minimizing overhead as much as possible. Overuse of error tracing, for example, applying ExceptionErrorReporter to every monitored method can result in a high volume of "false positives." For example, entering California in a numeric field, can cause a NumberFormatException. You would not want to report this exception as a serious problem.

ExceptionErrorReporter

The ExceptionErrorReporter tracer can be used to verify for exceptions being thrown from the instrumented method. If an exception is thrown, this tracer treats it as an error. The error message is obtained from the exception and it is the most common definition of an error.

To capture error messages, the ExceptionErrorReporter tracer must be used with a "...WithParameters" directive. For example:

TraceOneMethodWithParametersOfClass: com.bank.CustomerAccount getBalance ExceptionErrorReporter "CustomerAccount:Errors Per Interval"

This directive specifies that any exception that is thrown from the getBalance() method on the CustomerAccount constitutes an error.

Note: Use a ...WithParameters directive to increase the errors per interval metric, but you only have to specify a ...WithParameters directive once for any method to make the parameters available for all tracers on that method. For example, you can specify:

TraceOneMethodWithParametersOfClass: com.myClass myMethod BlamePointTracer

This directive makes the parameters for the com.myClass myMethod method available to other tracers, including the ExceptionErrorReporter tracer.

MethodCalledErrorReporter

The MethodCalledErrorReporter tracer is used on methods where the very act of the method being called means that an error has occurred. For example:

TraceOneMethodOfClass: com.bank.CheckingAccount cancelCheck MethodCalledErrorReporter "CustomerAccount:Canceled Checks Per Interval"

This directive specifies when the cancelCheck() method is called, it is an error. The error message states the class and method that was called.

ThisErrorReporter

If you do not know which methods can throw an exception or error, use the ThisErrorReporter tracer. The ThisErrorReporter tracer is similar to the MethodCalledErrorReporter, but it constructs the error message by calling toString() on the instrumented objects. This tracer is most useful to put on an exception class constructor as shown in the following two examples:

In a Java environment:

TraceOneMethodWithParametersOfClass: ezfids.util.exception.EasyFidsException <init> ThisErrorReporter "Exceptions|{packageandclassname}:Errors Per Interval"

In a .NET environment:

TraceOneMethodWithParametersOfClass: ezfids.util.exception.EasyFidsException .ctor ThisErrorReporter "Exceptions|{packageandclassname}:Errors Per Interval"

To capture error messages, the ThisErrorReporter tracer must be used with a ...WithParameters directive.

The directives specify when the constructor ("init" or ".ctor") of an InvalidPINException is called, it constitutes an error. The error message is determined by calling toString() on the InvalidPINException. Generally the Application Developer specified the returned error message.

Use this tracer when you have a custom error management system that is based on your own exception types.

Note: In a Java environment, CA Introscope (R) cannot instrument any code in the java.* packages. So, placing this tracer on java.lang.Exception or java.sql.SQLException does not work.

HTTPErrorCodeReporter

The HTTPErrorCodeTracer tracer reports error codes from servlets and JSPs or ASP.NETpages. The tracer is a per interval counter that counts incidents of:

  • HTTP response codes 400 or higher
  • The javax.servlet.http.HttpServletResponse subclass invocations of sendError or setStatus, for codes 400 or higher in a Java environment
  • The .System.Web.IHttpHandler subclass invocations of ProcessRequest, for codes 400 or higher in a .NET environment

Enable ErrorDetector in the Agent

The agent installation installs ErrorDetector automatically and includes a PBD file that is called errors.pbd. Configure Introscope to use the errors.pbd and enable ErrorDetector.

The property introscope.agent.errorsnapshots.enable must be set to true to enable the agent to capture error data. By default, the agent is enabled to capture error data.

Follow these steps:

  1. Open IntroscopeAgent.profile.
  2. Confirm that the introscope.agent.errorsnapshots.enable property is set to true.

    Note: You can change the configuration of this property during run time and the change is picked up automatically. To disable ErrorDetector, set introscope.agent.errorsnapshots.enable to false.
  3. Save IntroscopeAgent.profile.
    ErrorDetector is enabled.

Configure ErrorDetector Options

Enabling the default options in ErrorDetector captures error data without incurring much overhead. The out-of-the-box throttle is set at 10 errors per 15 seconds. To capture more errors during this time period, increase the throttle. But increasing the throttle incurs more overhead.

Use the introscope.agent.errorsnapshots.throttle property to configure ErrorDetector to limit the maximum number of errors the agent sends to the Enterprise Manager.

Follow these steps:

  1. Open IntroscopeAgent.profile.
  2. Enter a new value for the introscope.agent.errorsnapshots.throttle property. This property specifies the maximum number of error snapshots that the agent can send in a 15-second period.
    Default: 10

    Note: Changes to this property take effect immediately and do not require the managed application to be restarted.
  3. Save IntroscopeAgent.profile.
    The number of errors that are captured in a 15-second period is configured.
     
  4. Use the introscope.agent.errorsnapshots.ignore property to configure the agent to ignore errors you do not want to track. The information that you specify to "tag" the error can be the exact error message. The information can also be any portion of the message, with the "wildcard" asterisk character. Changes to this property take effect immediately and do not require the managed application to be restarted.
     

Important!

  • You cannot use the introscope.agent.errorsnapshots.ignore property to filter SOAP error messages.
  • When smart instrumentation is enabled, Introscope automatically collects a transaction trace when an error occurs. Application errors that are configured to be ignored do not trigger automatic transaction traces.

More information: Configure Smart Instrumentation, Collect and Analyze Transaction Traces, Detect and Analyze Stalls and Errors.


Follow these steps:

  1. Open IntroscopeAgent.profile.
  2. Use the introscope.agent.errorsnapshots.ignore property to specify the information that identifies the type of error.
    For example, the following ignore property would ignore any errors with the term IOException found anywhere within it:

    introscope.agent.errorsnapshots.ignore.0=*IOException*
    

    To ignore more errors, add more ignore properties sequentially. For example, to ignore two types of errors, the properties can be specified as follows:

    introscope.agent.errorsnapshots.ignore.0=*IOException*
    introscope.agent.errorsnapshots.ignore.1=*HTTP Error Code *500*
    
    Note: You can specify as many filters as you need using the index identifier that is appended to the property name. For example, .0, .1, .2 ...). Changes to this property take effect immediately and do not require the managed application to be restarted.
  3. Save IntroscopeAgent.profile.
    No error snapshots are generated for errors matching the filters that you define. Also, no error events are sent to the Enterprise Manager for them.

ยท     

Was this helpful?

Please log in to post comments.