About the Intercept MMC

Overview

All basic monitoring configuration is performed through the AVIcode Intercept Management Console. The console is accessible via:

The Management Console allows you to:

The MMC's on-the-fly configuration:

The Management Console has two vertical panes. The left pane is the console tree and the right is the details pane. The panes resize by dragging the divider bar. The detail pane naturally reflects whatever item you select from the console tree pane. The type of icon displayed in the Management Console will indicate the current monitoring state of any node in the console tree:

No monitoring of web applications (Executables , Windows Services , COM+ )

Operations Mode monitoring of web applications (Executables , Windows Services , COM+ )

 

Each tree node also has some additional menu options available from the right-click button, which may include:

Most of the configuration in the Management Console is done through the Properties pages, including enabling or disabling monitoring, setting performance thresholds, selecting which exceptions to collect, enabling event log monitoring, etc.

Can't open the console or console nodes? Make sure that you have administrator privileges on the monitored server. The main configurable tree nodes in the Intercept MMC Console are:

When you open the Intercept Management Console, it will automatically check that AVIcode has tested your installed version of the .NET Framework with the monitoring agents to verify compatibility. If your framework version has not been tested, a pop-up window will appear that says application monitoring has been disabled because the framework version has not been verified, and to notify AVIcode about the problem. Once AVIcode has been notified, framework support can be enabled via the 'Applications' node menu. Please see Configure System Settings later in this manual for instructions.

Concepts

This section describes each of the main concepts and terms that you will need to understand in order to properly configure the Intercept Studio monitoring agents. Please review this section before you configure the system. Note that sections of this page are in alphabetical order.

Adding All Namespaces

This option may be found via:

This setting will enable operations monitoring of all functions in Operations Mode, except those functions specifically excluded from monitoring or belong to namespaces or classes explicitly excluded from monitoring, such as the System namespace.

Enabling operations monitoring for all namespaces may lead to a high volume of data and should be used with caution.

Alerting Thresholds

Alerting thresholds are used by the Operations Monitor to determine if an event needs to be reported. The monitor measures the execution time of an Entrypoint (a top-level function), and reports an event if the Alerting threshold is exceeded. If the threshold is not exceeded, then the operations monitor disposes of the data. Alerting thresholds are measured in milliseconds, and are set to 5000 ms by default. This threshold can be modified for:

The following precedence rules apply when the Operations Monitor evaluates whether or not to report a performance event:

Alerting Thresholds set for: take precedence over... Alerting Thresholds set for:
Custom Function Entrypoints ASP.NET Page, Web Service Calls and Windows Form Calls Entrypoints, Individual Web Applications, Individual Executable Applications, Individual Windows Services and Individual COM+ Applications
ASP.NET Page, Web Service Calls and Windows Form Calls Entrypoints Individual Web Applications, Individual Executable Applications and Individual Windows Services, All Web Applications
Individual Web Applications All Web Applications

As you can see from this table, Web application wide or system wide threshold settings are used by the monitor only when application specific threshold settings are not defined. That is, application-specific threshold definitions take precedence over those set for all web applications. Alerting thresholds also take precedence over Sensitivity thresholds. The following are some examples to help demonstrate when performance events will be generated. In these examples, MyFunction() resides in MyFirstPage.aspx, and MyFirstPage.aspx is part of MyWebApplication running under IIS.

Example 1:

The following is an example of using the default alerting threshold set at the 'Web Applications' node level. Since no threshold is set at the Individual Web Application or Entrypoint level, and MyWebApplication does not exceed the default 5000ms, no event is reported.

Level Name Alerting Threshold (ms) Actual Time (ms) Event Reported?
'Web Applications' node 5000 -
Individual Web Application MyWebApplication not set 3100 No
ASP.NET Page Entrypoint MyFirstPage.aspx not set 2100 No
Custom Function Entrypoint MyFunction() not set 1100 No

Example 2:

The following is an example of defining alerting thresholds for an Individual Web Application. Since settings at the Individual Web Applications level takes precedence over settings at the 'Web Applications' level, and the actual execution time for MyWebApplication is 3100 ms which exceeds the threshold of 3000 ms, an event is reported.

Level Name Alerting Threshold (ms) Actual Time (ms) Event Reported?
'Web Applications' node 5000 -
Individual Web Application MyWebApplication 3000 3100 Yes
ASP.NET Page Entrypoint MyFirstPage.aspx not set 2100 No
Custom Function Entrypoint MyFunction() not set 1100 No

Example 3:

The following is an example of defining alerting thresholds for an ASP.NET Page Entrypoint. Since settings at the ASP.NET Page Entrypoint level take precedence over settings at the Web Applications level, and the actual execution time for MyFirstPage.aspx is 2100 ms which exceeds the threshold of 2000 ms, an event is reported.

Level Name Alerting Threshold (ms) Actual Time (ms) Event Reported?
'Web Applications' node 5000 -
Individual Web Application MyWebApplication not set 3100 No
ASP.NET Page Entrypoint MyFirstPage.aspx 2000 2100 Yes
Custom Function Entrypoint MyFunction() not set 1100 No

Example 4:

The following is an example of defining alerting thresholds for a Custom Function Entrypoint. Since settings at the Custom Function Entrypoint level take precedence over settings at the ASP.NET Page Entrypoint, an event is reported for MyFunction(), because it exceeds its own 400 ms threshold. An event is also reported for MyFirstPage.aspx and MyWebApplication, but because they are the parents of MyFunction(), not because they crossed their own thresholds.

Level Name Alerting Threshold (ms) Actual Time (ms) Event Reported?
'Web Applications' node 5000 -
Individual Web Application MyWebApplication 900 500 No
ASP.NET Page Entrypoint MyFirstPage.aspx 500 490 No
Custom Function Entrypoint MyFunction() 400 450 Yes

'All' Exceptions

This option may be found via:

'Applications' node

The 'Applications' node allows you to access and modify properties which apply to the monitoring system as a whole, such as choosing the desired storage type, testing connectivity to SE-Viewer, setting event throttling, etc.

Assembly Inspector

The Assembly Inspector supports browsing managed assemblies when adding functions. It displays all namespaces, classes, functions, exception handlers and resource calls related to a selected application and allows users to select items to be added for monitoring. It displays the full name of selected function in the status bar at the bottom of the window. It also allows user to find functions, classes or namespaces in an assembly by searching for all nodes that have a name which includes a user input string as substring.

Symbol Key

The  Assembly inspector uses different icons to identify different types of functions (public, protected, etc.) and groups get/set methods of class properties as shown in the key below:

Assembly

Namespace

Public Class

Non Public Class

Property

Public Method

Public Constructor

Public Static Method

Public Static Constructor

Protected Method

Protected Constructor

 

Protected Static Method

Protected Static Constructor

Internal Method

Internal Constructor

Internal Static Method

Internal Static Constructor

Private Method

Private Constructor

Private Static Method

Private Static Constructor

 

The Assembly Inspector displays class functions without a parameters list. As result, functions with the same name but a different parameters number or types are shown as one function. Additionally, the Assembly Inspector does not consider any inherited members, it only considers those members declared at the level of the supplied type's hierarchy. Also be aware that the Assembly Inspector omits:

To open a new assembly to inspect:

To find an element in an assembly:



'COM+ Applications' Node

The 'COM+ Applications' node allows you to configure the default settings for each COM+ application added under it in the tree. By adding individual COM+ applications under this node, you can begin monitoring for them.

'Critical' Exceptions

This option may be found via:

Intercept defines Critical Exceptions as being those that lead to a monitored component's failure. For ASP.NET applications, a critical exception results in the user seeing either the standard or a custom error page. For web services, critical exceptions are those that ASP.NET serializes into valid SOAP messages on the server-side, and deserializes to SoapExceptions on the ASP.NET client. The default definition of a critical exception may be extended to include exceptions that pass through your own custom handlers by clicking on the Exception Handlers... button.

The alternative to collection only critical exceptions is to collect All Exceptions.

Entrypoints

This option may be found via:

Entrypoints, or top-level functions, are the point from which Intercept Studio begins timing execution for slow performing business transactions. A separate performance event is generated for each entrypoint whose execution time exceeds the alerting threshold set for it.

Intercept Studio comes preconfigured with many well-known entry points (see below), but also lets you extend the default list by defining your own entrypoints. In addition to adding functions as entrypoints, you may also define entire Namespaces to act as entrypoints, so that the system begins timing execution the first time that it encounters the namespace during execution. Additionally, the Intercept Agent collects the values of variables for each entrypoint at the time the event occurs. Intercept Studio installs out of the box with a list of well-known Microsoft .NET framework functions that are monitored for slow performance and exception data collection. The list can be viewed in 'Appendix - Default Performance MonitoringEntrypoints

Event Log Monitoring

This option may be found via:

Intercept Studio can monitor for events that appear in the Windows Event Log. This feature exists so that:

Event Viewer

Access to the Windows Event Log is provided as a convenience in the Intercept Management Console. Note that there is a custom event log called 'Intercept' in the event viewer for all events generated by Intercept Studio's own components.

Exception Handlers

This option may be found via:

Exception handlers are application functions that are called in exception catch blocks to report errors and perform some error handling. By default, Intercept Studio defines critical exceptions as unhandled exceptions, top-level ASP.NET exceptions, web service and .NET Remoting exceptions. By adding your own exception handlers to this list, you are adding to Intercept Studio's definition of what a critical exception is. In effect, any exceptions handled by these functions will be considered critical exceptions. The advantage to doing this is that you maintain the benefit of streamlined reporting of critical exceptions only, but you have the additional benefit of reporting functions that are of interest to you.

'Executable Applications' Node

The 'Executable Applications' node provides a menu for adding new .NET WinForms and Console Applications written in .NET to be monitored by Intercept Studio. When selecting the Executable Applications Node in the console tree, the details pane displays all of the executable applications that you have added, as well as their current monitored state.

Individual COM+ Applications Node

AVIcode Intercept Studio monitors for exceptions and performance issues in COM+ application, which, unlike web applications, are required to be added to the Intercept Management Console tree.

Individual Executable Application Node

AVIcode Intercept Studio monitors for exceptions and performance issues in executable applications, which, unlike web applications, are required to be added to the Intercept Management Console tree.

Individual Web Application Node

When you add a web application to the Intercept Management Console, you may set properties for it, which are different from the default properties set at the 'Web Applications' node. This is particularly useful for disabling monitoring for an individual application, or setting unique performance thresholds for it. Web applications are added to the Management Console by name. The 'Display name' is used for web application identification. The settings of this web application item are applied to all web sites and virtual directories where IIS property 'Application name' matches Intercept property 'Display name'.

Individual Windows Service Node

AVIcode Intercept Studio monitors for exceptions and performance issues in Windows Services, which, unlike web applications, are required to be added to the Intercept Management Console tree.

Local Storage

Local storage is provided to enable event collection for:

Please see the 'Incident Utilities manual for additional information.

Monitored Functions

The Monitor sends an alert when an exception is raised in a monitored function. 'Monitored Functions' button enables collection of runtime data for a function or namespace.

Intercept Studio installs out of the box with a list of well-known Microsoft .NET functions that are monitored for exceptions. The default list includes namespaces and functions, some of which have monitoring disabled by default::

This list may be extended via the Monitored Functions...' button. If a function is in this list (or a function is implied to be in the list by virtue of belonging to a listed namespace or class), then runtime information will be collected for that function at the time an exception occurs.

Namespaces as Entrypoints

This option may be found via:

Entrypoints, or top-level functions, are the point from which Intercept Studio begins timing execution for slow performing business transactions. Intercept Studio comes preconfigured with many well-known entry points (see the section on Entrypoints), but also lets you extend the default list by defining your own entrypoints. In addition to adding functions as entrypoints, you may also define entire Namespaces to act as entrypoints, so that the system begins timing execution the first time that it encounters the namespace during execution. Additionally, the Intercept Agent collects the values of variables for each entrypoint at the time the event occurs. Subsequent encounters with the namespace that occur within the scope of the first encounter will be treated as Time-Only Entrypoints (see 'Namespaces for Time-Only Monitoring' below).

Please also see Appendix - Avoiding Performance Overhead for Monitoring Time-only Namespaces in this manual.

Each time an entrypoint exceeds the alerting threshold a new event will be generated.

Namespaces for Time-Only Monitoring

This option may be found via:

Entire namespaces may be added to the default list to gather execution time for all functions within that namespace. These namespaces may also be called 'Time-only Functions', where only the execution time will be captured, without any runtime variables. If you need runtime info about a function, you should define a function as an entrypoint or as a resource.

Please also see Appendix - Avoiding Performance Overhead for Monitoring Time-only Namespaces in this manual.

Operations Mode

Operations Mode provides concurrent monitoring of exceptions and performance. The operations monitoring mode has all of the same features as operations monitoring had in earlier releases of Intercept Studio. The exception monitoring under Operations Mode  does not collect exceptions that have never reached a well-known function or a known handler .

Operations Monitoring Mode

See Operations Mode

Operations Monitoring for Performance

Intercept Studio uses the Operations Mode to evaluate whether business transactions on the monitored server are taking longer to execute than the user-defined time limit. This user-defined time limit is the Alerting Threshold, or Service Level Agreement (SLA). When the Alerting threshold is exceeded, a performance event will be sent to SE-Viewer.

If a business transaction spans multiple servers, for example an ASP page that calls a Web Service, and both parts of the transaction exceed the thresholds defined for them, then the resulting performance events will be correlated in SE-Viewer. More information about correlated performance events may be found in the SE-Viewer section of this manual.

In order to determine whether to generate a performance event, the Operations Mode first checks the Alerting Thresholds for set for Entry Points in specific Web Applications, Executable Applications, Windows Services and COM+ Applications . If there are user-defined thresholds set, then the Operations Mode reports a performance event if the event meets the criteria. Sensitivity thresholds set for Resources at the Application level of the Intercept Management Console Tree. If no user-defined thresholds are set at that level, the Operations Mode then determines if there are user-defined thresholds set (under the default 'Settings' from the Operations Monitor tab) at the Application level of the Intercept Management Console Tree.

Operations Mode does not require any code changes in order to work.

Performance Counters

Intercept Studio provides the ability to collect ASP.NET performance counters and correlate them with application exception and performance events. Intercept provides two types of performance counter monitoring: Troubleshooting and State, which are described below. The following is the list of some counters that are collected by default, but you may extend the list with additional counters.

Thread Counters:

Physical Disk Counters:

Web Service Counters:

.NET CLR Memory Counters:

.NET CLR Data Counters:

.NET CLR Exceptions Counters:

ASP.NET Counters:

Troubleshooting Performance Counters

Troubleshooting performance counters are collected continuously within a 15 minute window. When a .NET exception or performance event occurs, all performance counter data from the 15 minute window leading up to the event are captured and stored.

State Performance Counters

State performance counters are used to monitor the immediate health state of an application by collecting a snapshot of configured performance counters at 5 minute intervals. This data is available for viewing trends SE-Viewer.

Resources

This option may be found via:

This option provides access to the default list of functions that make calls to resources (e.g. Oracle, Sybase, SQL, file IO, etc.) and their associated sensitivity thresholds. Intercept Studio installs out of the box with a list of well-known Microsoft .NET framework functions that are monitored for slow performance and exception data collection. The list can be viewed in Appendix - Default Performance Monitoring 'Functions

Sensitivity Thresholds

Sensitivity thresholds apply to resource calls, and are less than or equal to the alerting threshold (generally being set to approximately 100 ms). The sensitivity threshold causes the Intercept Agent to collect information about specific resource calls that take longer than the preset threshold.

Alerting and Sensitivity thresholds can be defined for specific applications or for all web applications. Web application wide or system wide threshold settings are used only when application specific threshold settings are not defined. That is, application-specific threshold definitions take precedence over those set for all web applications. Alerting thresholds take precedence over Sensitivity thresholds.

The Operations Monitor uses sensitivity thresholds to define if a resource call node needs to be included in a performance tree. In a staging or test environment, setting the sensitivity threshold to zero will allow Intercept to report performance information on all resource calls, including those that took no time.

In a production environment however, you should reduce overhead by eliminating the reporting of resource calls that took a negligible amount of time. This will help to eliminate extraneous information, which is of no interest in the alert.

For example, on the client-side, a Remoting Call is a resource call, so the Sensitivity Threshold drives it. On the server-side, the Alerting Threshold determines whether the event is delivered. If the execution time for the Remoting call falls below both the Sensitivity and Alerting Thresholds, it will not be reported

SE-Viewer Server Event Storage

Events may be sent from the monitoring agents to the SE-Viewer web service, called SELog, for database storage and viewing with the SE-Viewer web application. The database used may be either Microsoft SQL Server or Microsoft SQL Express.

State Performance Counters

See 'Performance Counters'.

Time-Only Entrypoints

See 'Namespaces for Time-Only Monitoring'.

Troubleshooting Performance Counters

See 'Performance Counters'.

'Web Applications' node

The 'Web Applications' node allows you to configure the default settings for all applications running under IIS. There is no need to add an individual application under this node unless you want the application to have settings which differ from the default. Additionally, you can Restart/Recycle IIS from the right-click menu.

'Windows Services' node

When selecting the 'Windows Services node in the console tree, the details pane displays all of the services that you have added, as well as their current monitored state.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Last update: Tuesday, December 07, 2010 03:38:57 PM