This article discusses the general exceptions monitoring configuration including “All Exceptions” / “Critical Exceptions” check box, Exception Tracking and Exception Handlers options explanation.
As you know AVIcode is capable to collect not only information about performance violations but also exceptions your .NET application.
In 5.7 there is no explicit Debugger Mode (as it used to be in the previous versions). To tell the truth it wasn’t popular enough among customers and that is why it was decided to exclude it from 5.7.
The exception monitoring can be configured on “Monitoring Settings” tab of “Properties” menu of the Intercept management console.
As usual, AVIcode is good at collecting relevant data out of the box. Sometimes, however, the data being collected is redundant, and sometimes it is insufficient… This is true for the exception monitoring as well so let us see how it can be tweaked.
We have three configuration options concerning exception monitoring:
-
- “All Exceptions” / “Critical Exceptions” check box.
- “Monitored Functions…” (don’t let the name deceive you – it is actually relevant to the exception monitoring). If you happen to come accross somewhere (say, in User Manual, or in this blog, etc) exception tracking being mentioned, don’t be confused. Just keep in mind it is all under “Monitored Functions…” in MMC).
- “Exception Handlers…”
“All Exceptions” / “Critical Exceptions” check box
This is a simple one. AVIcode divides all exceptions based on severity level defined. In SEViewer you can notice two types of exceptions represented as red icon with white X letter (these are critical or unhandled exceptions) and as white icon with red X (handled or non-critical exceptions).
But how does Agent determine which exceptions are critical and which are not?
Exceptions can happen as a part of the business logic, for example as a part of the input validation. These exceptions are not disturbing the user experience and therefore are not considered a problem. Other exceptions may result in unexpected application behavior and may break the user experience. We definitely consider those exceptions a problem and therefore want to know about them. How do you tell them apart? Normally you have one “catch-all” method in the application which either formats an error output for a user, sends the exception in the log or just silently ignores it. When an exception passes through this kind of method we may suggest that it is not handled by the code and probably is an indicator of something bad happening.
Therefore, the rule is: if the exception is passed through one of the functions added as Exception Handler it will be marked as critical. Critical exceptions are usually ones causing application failure.
The check box defines whether to collect all or critical only exceptions for the application.
“Monitored Functions…” (Exception tracking)
To collect exceptions for some function Agent wraps this method into try{}/catch{} block. Through “Monitored Functions…” you can specify what functions/classes/namespaces should be instrumented for exception tracking, in other words in which functions Agent will track exceptions.
Well, you can add here explicit methods or classes, but it’s also OK to enable “All Namespaces” for exception tracking. Unlike the similar configuration option for time-only (“Namespaces…”) monitoring this doesn’t affect performance much, since methods wrapping is applied during JIT-compilation and thus it may decrease only the first request performance.
So if you want to collect more exceptions and to get evident exception stack as well as to gather parameters for methods in the stack you need to add more namespaces/functions to exception tracking.
“Exception Handlers…”
As I’ve already mentioned in this article, Exception Handlers functions let Agent recognize critical exceptions. Out of box several default exception handlers are specified. You can find them listed in “ss:handlers” section of “PMonitor.config”. Of course you can add your own custom functions here in order to mark exceptions handled by these functions critical. This may have sense, for example, when some exceptions are caught and handled in your application code in try{}/catch{} block, – that’s a good practice to add functions in catch{} block as exception handlers, so you will receive exception event in any case (regardless “All Exceptions” / “Critical Exceptions” check box value).
In conclusion I would mention that Throttling (if enabled) is applied to exception events as well. If you miss some exceptions that’s the first thing you should check.
In this article I have tried to cover general information over exception monitoring in AVIcode 5.7. Hope I’ve managed to do that intelligibly enough and fewer questions about exception monitoring will still persist opened.
Good luck!
