However, you may require the monitoring of other components or counters that are not covered by these default rules; for this purpose, you can now quickly perform this operation by adding any custom rule to Xian Network Manager.

We are going to add a custom rule to monitor CPU load on an HP switch as an example. These would be the detailed steps needed to add a custom rule:

Read the entire article here

That is good and bad at the same time. It gives the users more control over what’s going on in the management group, and that’s definitely good. However, this sort of management pack behaviour is unexpected by both end users and SCOM itself, so that creates a couple of problems:

- Management pack usability
- Management pack reliability

Usability problem is not so much a problem of the management pack as it is a problem of what users expect from the management packs. Usually, initial management pack configuration comes down to defining the groups and overrides. However, those changes are mostly supposed to enable monitoring rather than to deploy/configure some underlying components.

In case with .NET management pack, the things are different. You’ll see it right away when you decide to install the management pack. There is simply no “MP”/”XML” file in the installation package. However, there is an MSI. Sounds like a heresy, right?

However, it’s not because AVIcode does not know how to install MP files properly. It is simply because this management pack is more than a management pack. The MSI file you get there contains other components of .NET monitoring solution provided by AVIcode, and that includes Intercept Agent and SEViewer at the very least. All those components are integrated with the management pack, so the purpose of that MSI is to ensure that, from the integration standpoint, all the required steps are done properly during the installation(rather than they are left to the end user). On top of that, MSI will install a few utilities to let some of the MP tasks work correctly.

That’s not all, though. Once you have installed the management pack, it will not start monitoring .NET applications for you right away. Yes, it will start discovering .NET applications, but discovery itself does not provide the value. What you’ll have to do after that is to configure the templates. Following that, the management pack will go ahead and deploy required portions of the monitoring solution on the SCOM agents, and, only after that, you’ll start getting some data in the Operations Console.

Did you notice that I mentioned automatic deployment above? If it happened to slip through the net of your attention because of all the other stuff, let me stress it out once again. Unlike most of the other management packs, this one is closely integrated with the underlying .NET monitoring components from AVIcode. In particular, it is designed to deploy those components on the monitored servers transparently for the end users.

Here comes the first problem. SCOM does not provide out of the box mechanisms to implement that kind of functionality, so it has to be done through the use of some extensions. In this particular case, vbs scripts are utilized. In a nutshell, .NET management pack utilizes http/https to download required components from the SEViewer server(and that’s part of AVIcode Intercept Studio that gets installed with the management pack). As I wrote, it is done through the use of vbs scripts.

That’s, probably, one of the first problems you will see if you decide to install the management pack. In fact, you just need to keep that background processing in mind when working with this MP. In particular, if there is no HTTP(s) link between SCOM agent and SEViewer server, you will not be able to use the MP. Neither you’ll be able to use it if you do not specify correct SEViewer location while installing the management pack(or after that, through the use of overrides).

This behaviour can be totally unexpected by some SCOM users, and, as no one reads the manuals, that may lead to the usability problems. At the same time, that brings up a question about management pack reliability because of the potential HTTP connectivity issues.

If and when everything is properly configured, though, this management pack can do wonders. Normally, you have to install AVIcode Agent manually on the servers to be monitored. You don’t have to worry about it once the management pack is there – just add your server to the required .NET groups, and that’s all that is needed. .NET Management Pack will take care of AVIcode Agent deployment and/or configuration after that.

I almost hate to say that, but, in case with this management pack, make sure to read the manuals. You will find more than you can expect from the management pack – make sure you know what to expect.

“Step by step” follows in Part 2.

AVIcode provides a mechanism to run additional custom code when the application being monitored enters/leaves particular functions. The list of such functions can be defined in the configuration file, and the custom code to run can be compiled independently.

There are some limitations, of cause. First of all, the code is supposed to be implemented as a static method defined according to some rules. Also, the assembly containing that code is supposed to be deployed into the GAC.

This mechanism is called "Custom Actions".

There are two types of custom actions. SimpleSyncAction does not require AVIcode to collect any data, so SimpleSyncAction is faster and less resource consuming than a SyncAction. SyncAction, in turn, makes AVIcode collect application function call parameters and pass collected data to the SyncAction.

It may look confusing so far, but it comes down to this:

1. You can instruct AVIcode to call additional static methods when the application being monitored enters/leaves specific application functions

2. In order to do that, you need to come up with the assembly that will implement those methods,  and you need to create two configuration files:

- .instrument.config
- Optional: .action.config

The first file is where most of the magic really is. That file defines which application functions to instrument with your custom actions, and it also defines which custom actions will be triggered when/if the application does something. Here is an example of the "instrument.config" file:

Basically, this configuration file defines custom actions assembly name, and it also defines which application function will be instrumented with which custom actions.

Note: it is important to make sure that the methods you are using to implement custom actions always have the same predefined names: SimpleSyncAction and SyncAction. AVICode will not be able to use your custom actions otherwise.

Take a look at the definition of custom action methods:

public static void SyncAction(object[] args, object prefixParams, object postfixParams, object entryPointGUID, Int32 executionTime, object exception, Int32 functionID)

public static void SimpleSyncAction(object[] args, object entryPointGUID, Int32 executionTime, object exception, Int32 functionID)

As you can see, the only difference between SimpleSyncAction and SyncAction is that prefix/postfix parameters are not passed to simple actions. In many cases, that's not even required. All the parameters(+ "this" pointer) of the instrumented method will still be passed to both types of custom actions through the "args" array. However, AVIcode allows to define custom data collection rules, and prefix/postfix parameters will be formed according to those rules.

Here is a zip file that you can download to try custom actions for yourself:

AVIcode Custom Actions Step 1

There is a VS 2008 solution file for the custom action, and there is a configuration file that should be uploaded to the AVIcode agent configuration folder:

\Program Files\AVIcode\Intercept\Agent\v5.7.491\Configuration\Standard

Please note that if your version of AVIcode is different from 5.7.491, you may have to adjust version numbers in the path above and in the configuration file.

Once you compile the solution, you'll get a CustomActionTest.dll assembly that should be deployed into the GAC on the agent server.

You may also have to create a log file on the C drive: "data_dump.txt". Make sure IIS application pool accounts can write to that file.

Follow these steps to test your custom action after that:

- Enable monitoring of all web applications in the Intercept MMC console

- Restart IIS

- Open any ASP.NET web page from your server

- Open the log file ("c:\data_dump.txt") and see the results. For every page load you'll see a couple of lines in that file. That's not so much, but the idea was to illustrate how it works and to come up with a working example

In the next part, we'll see how AVIcode uses Custom Actions to implement .NET statistic counters and what you can do with the Statistic Counters independently/through the management pack. After that, we'll take a look at the data collection rules (in general and being applied to the custom actions).

Remember that AVIcode splits exceptions into two categories: “critical” exceptions and “all” exceptions. .NET exceptions are always handled, this way or another. They can be handled by the application, or they can be handled by the framework. In fact, “Critical” exceptions are those which are handled by the framework rather than by the application itself. AVIcode considers an exception to be critical if that exception is handled by a pre-configured exception handler.

Take a look at the picture again:

Exception Handler

There is a method called “ExceptionHandler”, and it gets called from the catch block. The name is not really important, but what’s important is that when this method gets called, there is still some .NET exception on the stack.

There are methods like this in the .NET framework, but every application can introduce additional methods of this kind. Here are a few examples of the framework methods:

• System.Web.UI.Page.HandleError
• System.Windows.Forms.DataGridView.OnDataError
• System.AppDomain.OnUnhandledExceptionEvent

When one of those methods is called in response to an exception , AVIcode believes a critical exception has occurred, and critical exceptions are always captured.

So, here is how you can use it. If there is an exception that can be raised by your application, and that exception is handled by the application, you can make such an exception “critical” from AVIcode standpoint by introducing an exception handler method and by adding that method to the list of exception handlers recognized by AVIcode:

Exception Hanlders button

Exception Handler List

Once you have done it, all such exceptions will be treated as “critical” exceptions by AVIcode.

Buggy Code

Assume that somewhere else your application makes a call to the EntryMethod. “WE HAVE A FAILURE!!” exception will be handled inside that method, so, if that’s the only method that is instrumented for exception monitoring by AVIcode, the exception will never be caught by AVIcode.

Basically, the same logic applies to some other situations. For example, you might have a method that raises an exception and handles it right away.

There is, also, another reason why some exceptions will not be captured. In the example above, “WE HAVE A FAILURE!!” exception is handled inside “EntryMethod”. For AVIcode that means that there is a handled exception, and such exceptions will be captured(assuming everything is instrumented properly) only when “all exceptions” option is selected in the Intercept MMC Console:

Choosing the Exception Type

Otherwise, only those exceptions which are not handled by the application will be captured by AVIcode.

So, there are 2 main scenarios when you may not see an exception in AVIcode:

1. You have not configured instrumentation properly. Go to the Intercept MMC console->"monitored functions" and make sure you have all the required functions/namespaces. The main idea is that your application exception has to pass through AVIcode try-catch in order to be captured.
2. There is a handled exception, and you have configured AVIcode to capture “critical” exceptions only. In this scenario, you may have to re-configure AVIcode to start capturing all exceptions instead.

Note: you can intentionally disable data collection for some exception classes – more on that later.

The question is: what can you do if there is an exception that never leaves the method where it happens? You can't instrument such method properly. Also, is there a way to capture a handled exception if you don’t really want to start capturing all handled exceptions?

There is a solution, and it is called “exception handlers”. I’ll talk about that solution in part 3.