While configuring .NET management pack, you’ll inevitably run into this screen:
.NET MP transactions
This screen represents a really interesting feature which is often ignored. It might be because the terminology is a bit misleading, but it all comes down to the monitoring of particular pages/functions/web service methods. You can use this screen to define additional monitors for those application entities:
Essentially, that allows for a very granular (per page/per method) monitoring. What’s interesting, though, is that the monitors depend on “statistic counters” functionality provided by the Intercept Agent. If you look at the names of the monitors, there is direct correlation with the names of Intercept statistic counters:
So, here is how it works:
– First of all, you have to define a transaction(a web page, a custom function, or a web service method)
– For every transaction, you can define additional monitors (see screenshot above)
Once that is done and new configuration is propagated to the SCOM agent, .NET MP will apply that configuration to the Intercept Agent. What you’ll see as an end result is a set of statistic counters configuration files in the Intercept Agent folder:
And that will let you observe the health of your “transation” in the Operations Manager Console.
Actually, this feature is specific to the .NET MP – there is no other Intercept Studio UI tool that allows you to create statistic counters(should there be one? Probably)
This was another example of how custom actions(statistic counters in this case) can be utilized to implement better monitoring of your application.
And, just to finalize this set of articles about custom actions, here is what you cannot do with custom actions/statistic counters:
– You cannot make the application fail by using a custom action because Intercept Agent will hide all exceptions that happen inside a custom action (well, in practice, it is probably not true. You can generate some sort of native exception, or you can end up with a stack overflow inside your custom action. That will likely still break the application.
– Every custom action is a separate method call, so you don’t have access to the members of the method for which your custom action was created. You have access to the parameters of that method, though(because they are passed to the custom action. Whether you can modify those parameters depends on the type of each particular parameter).
Note: While working on this article I noticed that .NET MP does not remove custom actions from the statistic counters configuration file when you change configuration settings. For instance, you will see two statistic counters on the screenshot below:
Counters Configuration File
It might be a good idea to remove obsolete statistic counters from this file from time to time, especially if you are going to upgrade configuration settings frequently.