Updated on 8/1/18
You may want to configure Error Detection to ignore a number of known exceptions. For example, you may see a recurring exception that is thrown from a framework you are using. However, the exception is well-known and insignificant so you want to eliminate it from the error list.
The first thing you need to know for each message is whether AppDynamics is detecting it as a thrown exception or a message written to a log file with severity ERROR. If it is an exception, the snapshot's Error Details tab should have a stack trace. If you only see the error message, it's a logger.
Example: Logged error message:
You can dispose of it by ignoring logged messages such as:
This is the error message:
com.appdynamicspilot.persistence.ItemPersistence.com.appdynamicspilot.persistence.
ItemPersistence : Critical transaction Error, rolling back changes. Order execution aborted.
Below is the configuration to ignore the error message:
The next two examples are thrown exceptions, both from the same place:
Response-xslFile :null; IsActivationCompleteSuccess:false; IsValidated :false;
OrderType :QUERY; AccountNumber :null; CustomerQualification :null;
CapErrorCode :00602; capErrorType :1; CapErrorCategory :CDE; CapErrorDesc
:Account_Data_Discrepency; OperationMode :null; OperationStatus :null;
ActivationDate :null
SUBMIT_ACTIVATION_DETAILS : Transaction Id:xx-23341105-1 -
Controller:handleRequest() > An Exception is caught
Dependent object contains ... [details deleted] CarrierErrorCode
:null;
The exception message is
:com.company.bb.cap.exceptions.CarrierBusinessRulesException:
Controller:handleRequest(): Transaction failure response from
Carrier.
You can exclude these by specifying
com.company.bb.cap.exceptions.CarrierBusinessRulesException
as the class and ignoring particular values of CarrierErrorCode
(which are buried in the full message).
If it is a true exception, please note whether it's nested inside another exception. You'll need to specify the exact sequence in the Error Detection config. It will look like this:
java.net.WebException : com.company.bb.cap.exceptions.CarrierBusinessRulesException: Controller:handleRequest(): Transaction failure response from Carrier
.
Pay close attention to what is in the stack trace. For example, a stack trace similar to the following might show up in the Error Details section of a snapshot:
java.lang.reflect.InvocationTargetException:com.company.eppi.client.exceptions.
ClientException:
java.lang.reflect.InvocationTargetException.null
at sun.reflect.GeneratedMethodAccessor1249.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
... <details deleted>
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
Caused by: com.comodo.epki.client.exceptions.ClientException :
com.comodo.epki.client.exceptions.ClientException: Not authorized agent
at
com.comodo.epki.extra.agent.ws.CcmExtraAgentServer.authorizeAgent
(CcmExtraAgentServer.java:210)
at
com.comodo.epki.extra.agent.ws.CcmExtraAgentServer.getExtraCommand
(CcmExtraAgentServer.java:70)
Don't create the exclusion on the "caused by" exception. Instead, use the first one in the stack trace. In the example above, you would set the Fully Qualified Class Names for Exceptions field as java.lang.reflect.InvocationTargetException:com.company.eppi.client.exceptions.ClientException
. You would not put it on com.company.epki.client.exceptions.ClientException
.
The configuration for this example would like the screenshot below:
This is the exception:
org.springframework.transaction.CannotCreateTransactionException:org.eclipse.persistence.
exceptions.DatabaseException:org.apache.tomcat.dbcp.dbcp.SQLNestedException:java.util.
NoSuchElementException
Below is the configuration to ignore the error message:
For more detailed information on error detection and specifically how to ignore exceptions and log messages, see: Ignore Exceptions and Log Messages as Error Indicators.