Getting the most out of Foglight's .NET Monitoring - Part 2: Agent Configuration Specifics and Best Practices

In Part 1 of this article we covered some conceptual basics concerning .NET application monitoring. Here in Part 2 we'll explain some details concerning .NET agent configuration and best practices for ensuring the agent is configured the way you want it to be. In a third article we'll walk through a specific configuration example. Special thanks once again to my colleague Keith O'Leary for contributing excellent content to this article.

.NET Application Types

We're going to distinguish here between a few different types of .NET applications:

- Windows Executable Applications - including Windows Console applications and Windows Forms

- Web Applications, Web Services, and Web Sites (e.g. applications that use ASP.NET and/or ADO.NET)

- COM+ applications that use .NET

- Windows Services that use .NET

We're drawing these distinctions here because the way you configure details in Foglight's .NET agent varies among these application types.

.NET Agent Properties - Using the Foglight UI vs Using the Intercept Studio

The .NET Agent properties can be configured through the Foglight UI or through the Intercept Studio on the target host. Whenever possible, all agent properties should be set through the Foglight UI. However there are some configurations that must be set from the Intercept Studio. The following table summarizes things:

* - For Web Applications, setting namespaces for performance monitoring is currently per agent, not per web application

** - For Web Applications, you may use the Foglight UI to specify Entry Points for only one web application. For all other web applications you must use the Intercept Studio to configure Entry Points

*** - you may enable the performance monitoring of all namespaces from the Foglight UI by using the Collect Additional Performance Diagnostic Data radio button in the Agent Properties page, however for more detailed namespace configurations you must use the Intercept Studio.

**** - you may enable the exceptions monitoring of all namespaces from the Foglight UI by using the Collect Additional Exception Diagnostic Data radio button in the Agent Properties page, however for more detailed configurations you must use the Intercept Studio.

When you can’t modify a property using the Foglight UI, modify it using the Intercept Studio. There are a few other important considerations:

• Any agent configuration you set using the Foglight UI will be transmitted down to the Intercept Studio on the target host if those settings exist both in the Foglight UI and the Intercept Studio

• However, any agent configuration you set using the Intercept Studio will not be transmitted up to the Foglight Management Server and will not be reflected in the agent's properties in the Foglight UI. A restart of the .NET agent will cause the Intercept Studio to load its settings from the FMS thereby overwriting any changes on the Intercept Studio.

• For those agent properties that can be configured in the Foglight UI and on the Intercept Studio, the Foglight UI settings will take priority i.e. when the agent restarts on the target host, the agent and Intercept Studio will load up its property settings from the FMS, thereby overwriting the property settings in the Intercept Studio. This behavior can be disabled using the Configure using Management Console Only radio button in the Agent Properties page.

Performance Counters

Troubleshooting Performance Counters are collected continuously within a 15 minute windows. When a .NET exception or performance event occurs all performance counter data from that particular 15 minute window are collected and reported. By default there are a number of performance counters that are captured when an event occurs. The set of collected counters can be customized using the Intercept Studio.

Best Practices for Managing Agent Overhead in Production Environments

As the agent is designed to run in a production environment the number of namespaces/classes monitored out of the box are kept to a minimum so as to keep the level of overhead at an acceptable level (i.e. 3%-5%). Out of the box the agent will monitor the more important namespaces and classes, such as System.Web.Mvc.MvcHandler.ProcessRequest. The more namespaces/classes that are monitored for either performance or exceptions, the more events and detail will be captured and the more overhead will be introduced into the application.

In a production environment there may be a need to capture data only for particular namespaces. In a non-production environment you can simply monitor all namespaces by setting the Collect Additional Performance Diagnostic Data and Collect Additional Exception Diagnostic Data to true, using the radio buttons on the agent properties page in the Foglight UI. However in a production environment this is not advised - you will want to configure only those namespaces you need using the detailed settings in the Intercept Studio.

In production environments it is also recommended that Event Throttling be used. Event Throttling helps to improve system performance by constraining the number of events that are collected by their event group over time. If a particular event group is generating a significantly high number of the same events, throttling will limit the number of events so as not to inundate the .NET agent and FMS with the same event. Event Throttling may be enabled or disabled from the Intercept Studio.

I hope you found this article useful. Stay tuned for a specific tuning example in Part 3!

Robert Statsinger