BlamePointTracer Doesn't Actually Capture Errors?

Document created by Chris Kline Employee on Jan 7, 2015
Version 1Show Document
  • View in full screen mode

When writing custom instrumentation (PBD) it is a common practice to use the BlamePointTracer to get the 5 common metrics for method call(s):

  1. Average Response Time
  2. Responses Per Interval
  3. Concurrent Invocations
  4. Stall Count
  5. Errors Per Interval


The BlamePointTracer would normally look something like:


TraceOneMethodOfClass: com.sample.MyFavoriteClassImpl execute BlamePointTracer "Sample|{classname}|{method}"


Did you know that while BlamePointTracer sets up all five of those metrics, it won't actually cause errors to be gathered?  In other words, using BlamePointTracer alone, you'll always have zero (0) for the error value.  When you watch errors, you also need to gather an ErrorSnapshot to explain what occurred in when the error was caught.  To do this, you need an additional tracer.  While there are several tracers that will do the job, ExceptionErrorReporter is likely the one you'll wish to use.



A per interval counter based on the number of exceptions being thrown (i.e. uncaught) from the identified method(s). If an exception is thrown, the error message is based on the return value of the getMessage() method called on the exception object. In order to capture the error message, must be used with a *WithParameters* Directive, otherwise will only increment the Errors Per Interval metric.


So, in addition to BlamePointTracer, you would want to instrument errors with the following PBD syntax:


TraceOneMethodWithParametersOfClass: com.sample.MyFavoriteClassImpl execute ExceptionErrorReporter "Sample|{classname}|{method}:Errors Per Interval"


This will result in all five BlamePoint metrics being produced, along with ErrorSnapshots that capture the content of error exceptions as they occur.


Learn more about configuring ErrorDetector.