Now that we’ve addressed an easy configuration change that one of our customers made in order to collect the full command text for large SQL queries, it seems appropriate to provide a quick tip for further fine tuning of AVIcode’s monitoring and data collection related to SQL queries.

By default, AVIcode’s solutions are configured to collect only the first 20 parameters and associated values within a SQL command. There are cases, though, where an application passes more than 20 parameters, and application performance troubleshooting efforts require you to extend this diagnostic data collection.

This is a straight forward configuration change, much as collecting the full command text change described earlier:

1.      Locate, backup and edit the configuration file on the monitored server: %Program Files%/AVIcode/Intercept/Agent/%Version%/Configuration/

a.      If using the .NET 1.1 framework, the configuration file is PMonitor.default.config

b.      If using .NET 2.0 or later, the configuration file is PMonitor2_0.default.config

2.      Next, find the class with the command definition related to the database provider. For example, System.Data.SqlClient.SqlCommand or System.Data.Odbc.OdbcCommand.

3.      Within the command definition, edit the detailLevel value for the parameters member. The default value is “3/20”, where the second number is the maximum number of parameters collected. AVIcode recommends changing the value to “3/40”, but depending on your specific needs, a different number may be required.

4.      Finally, save the configuration file and recycle IIS to start collecting all parameters values for the SQL queries and stored procedures .

Application monitoring requirements vary greatly between applications and organizations. There is no one-size-fits-all approach. AVIcode’s application performance monitoring solutions are designed to be highly scalable and easily configurable in order to meet varied and evolving monitoring needs.  This quick tip demonstrates just another example of AVIcode’s extensibility and flexibility.

Detecting, identifying and diagnosing the root cause of application failures or performance bottlenecks can be a challenge without an application performance monitoring solution that is suited for in-production, always-on monitoring.  The problem resolution challenges are further complicated when you take into consideration the distributed nature of applications and the multiple dependencies of that application.

AVIcode’s low-overhead APM solutions are uniquely suited for in-production monitoring. Recently, we had a customer tell us about the value of monitoring in-production when it came to an issue with a dependency on a database.  AVIcode was able to help that customer detect the details of a performance issue, including the SQL command text. The challenge for the customer was that AVIcode’s default configuration limited the command text to collect only the first 4KB of data, which is generally enough to isolate a problem. But, in this situation, the application in question was using very large queries, instead of stored procedures, and extending the default collection limits was the best option.

Fortunately, this was an easy configuration change: 

1.       The customer located, backed up and edited the configuration file in this folder on the monitored server: %Program Files%/AVIcode/Intercept/Agent/%Version%/Configuration/.  If using .NET 1.1, the file to modify is PMonitor.default.config. In this case, and with .NET 2.0 and later framework versions, the file to modify is PMonitor2_0.default.config.

2.       Next, the customer found the class with the command definition related to the used database provider like SQL, ODBC, DB2, OleDb. For example, this could be System.Data.SqlClient.SqlCommand or System.Data.Odbc.OdbcCommand.

3.       Within the command definition, the stringLimit value for the cmdText member was edited. The default value is “4196”, and we recommended adjusting this value to “10240” for the large SQL statement.

4.       The last step was to save the configuration file and recycle IIS. The full SQL command text was then received.

With this easy configuration change, AVIcode's customer was able to capture the full command text valuesof their SQL queries and quickly identify and resolve their application performance issue.

The challenge of tackling a perceived application performance problem can be very time-consuming and costly. For example, an AVIcode client recently had a specific website page that was loading several controls based on the logged in user.  The default performance alert setting for the site was five seconds, and the sensitivity for resource calls was set to 100ms for all requests to this application.

The website page in question surpassed the performance alert setting, but the generated event only revealed a very limited execution tree. It simply showed four SQL calls with the parameters that broke the 100ms sensitivity. The "resource view", however, showed nearly 500 SQL calls, totaling 70% of the page build time. We knew the page build required too many SQL calls, and now had two directions we could go in to continue the problem resolution process, both required some configuration changes.

In this situation, our first step was to enable the SQL database open and close methods of the data class. In the resource configuration of the management console, we simply enabled these within the Operation Mode tab. Next, we configured monitoring for the application by choosing "add web application" within the management console and selecting the application in question. This allowed us to add an "entry point" under the Operations Mode tab (within the application properties dialog).  With that page added as an entry point, we could then set a specific page alerting and sensitivity threshold. With the entry point added, we set our thresholds to zero for alerting in order to capture every request, and then lowered the sensitivty to 10ms. These settings allowed us to capture the recursive function(s) that caused the performance problem. With this information, the last step was for our client to decide whether to change the stored procedure to operate more efficiently or alter the application in order to limit the number of calls to the database by caching or other means. As a side benefit, our client also told us that the data we collected and the process described above promoted better communication and more positive conversation between their DBAs and developers.

We occasionally see situations where it is necessary to duplicate the exact same monitoring configuration from one server to another.  For example, this is sometimes required when a client would want to undo changes made during testing. Repeating a monitoring setup is straightforward. AVIcode's management console snap-in modification of XML-based monitoring agent configuration files. These files are unique in that they are not server-centric, in other words, they are not aware of server-specific configurations like server name or IP address. Rather, the configuration files are application-specific.

As a best practice, we recommend clients make backups of their main configuration files for the the various types of servers being monitored. These files are typically located in the %Program Files%/AVIcode/Intercept/Agent/%Version%/Configuration/ folder on the monitored system. A local network share should be created called //AVIcode/Backups and folders created for each type of monitoring being performed.  In one recent implementation, an AVIcode customer simply created a "Production" folder for the backup configuration files for production systems and a "QA" folder for the files from their QA servers.

These backups become the catalyst for employing repeat monitoring configurations. When you deploy a new agent, simply start the management console snap-in (agent configuration utility) and test its connectivity. This is a required step in order to apply configurations, and should be done both before and after xcopy.  Next, copy the appropriate "backup" files to the new server or desktop configuration directory. Consider the option of configuring a scheduled xcopy job to either pull the backups or push them out to reset the servers on a set schedule. That's all there is to it - enabling repeat monitoring configurations is quick and simple.

By default, Intercept Studio does not collect parameters or member variables if they have a null value. This is because, typically, seeing a null value is not critical while examining the root cause details of application problems. However, if you are struggling with a System.NullReferenceException or System.ArgumentNullException issue, collecting null values may be critical to successfully diagnosing and troubleshooting the problem.

Enabling Intercept Studio to collect null values is simple. First, update the agent configuration file, PMonitor.config, by adding the following item to the "options section": <ss:emptyObjects print="true" />. Then save the configuration file and restart the application. That's it - you're on your way to resolving the null reference or argument exception.

Recently, several AVIcode customers asked if AVIcode could begin publishing quick tips to help them get the most value out of their application performance monitoring implementation. They've asked for tips and tricks that will best help them integrate and implement AVIcode solutions like Intercept Studio, the AVIcode .NET Management Pack, and Intercept uX within their application environments. As we receive questions that have widespread customer appeal, such as configuration tips to help monitor SharePoint or BizTalk applications, we'll publish them here, and we encourage you to submit your questions, as well.

AVIcode was recently included in Gartner Inc.'s first "Application Performance Monitoring"¹ Magic Quadrant market study. AVIcode is "regarded as the market leader in the management of .NET based applications", and the company offers a broad range of solutions covering all five of the Gartner-defined "dimensions" of application performance monitoring.

The Magic Quadrant positions vendors according to their "Ability to Execute" and their "Completeness of Vision."

All vendors were evaluated on the five most recognized dimensions of the application performance monitoring (APM) market:

• End user experience monitoring
• User-defined transaction profiling
• Application component discovery and modeling
• Application component deep dive monitoring
• Application Performance Monitoring database

In order to be qualified for inclusion in the magic quadrant, a vendor must have at least 50 customers who use its APM products actively in the production environment for at least two of the APM dimensions or functionalities listed above, adn the vendor must have a global sales presence. AVIcode addresses all five dimensions and provides customers with a complete keybaord-to-eyeball solution. In addition, AVIcode has extensive indirect and direct sales channels that provide the company with a worldwide presence.

As the acknowledged market leader, AVIcode is honored to be recognized by Gartner and represented in the first Magic Quadrant for the Application Performance Monitoring space. To learn more about the magic quadrant, or to discuss how AVIcode's solutions for .NET, SharePoint, BizTalk and SQL Reporting services monitoring were evaluated, please contact us directly - http://blog.avicode.com/contact.aspx.

In our previous post, we provided an example of a security issue that could not be diagnosed solely with event details collected by ASP.NET health monitoring. Some developers have asked us about the open source Error Logging Modules and Handlers (ELMAH) and how that would have helped in this same situation.

ELMAH is becoming a popular tool for error logging. Many find it more flexible and easier to use than ASP.NET health monitoring. Both tools provide good visibility into application health state changes, including start, shutdown, heartbeat, audit messages, etc. ELMAH extends the exception problem details available via health monitoring to include the ability to log error data from custom error handlers.

The ELMAH API also provides support for different data storage methods and web-based access for error data. In production environments, this data often helps improve and speed support team access to error data.

This information is very valuable for troubleshooting efforts. However, AVIcode's ability to collect runtime parameters that are passed through the methods in the call stack makes root cause diagnosis much easier and more straightforward than health monitoring and ELMAH. In addition, AVIcode's monitoring solutions provide greater visbility into all the problem details for both handled and unhandled exceptions, as well as performance problems. These details can also be consolidated and correlated with key performance counters over time to provide a more complete picture of application behavior and its effect on the IT environment.

One common example of a typical exception that is very difficult to diagnose with ELMAH or other standard error logging APIs is a NullReferenceException. For this (and all other) application problems, AVIcode collects the runtime parameters and member variable values, enabling analysis of the code stack and determination of the application health state. The screenshot below shows a typical example with the AVIcode collected data. 

In addition, AVIcode enables linking to the PDB file, even after data is collected in production, in order to show the source file name and precise line number where the exception occurred. This is accomplished without the PDB files needing to be deployed to a production server, which is typically against corporate IT policy and certainly not recommended. 

Another advantage that AVIcode provides over ELMAH is a secured, centralized web console for managing data access.  The AVIcode console can be integrated with Windows or Forms authentication and allows for differentiating access privileges based on logical hierarchies and account/application log access rules.  The console is web-enabled, so authorized users can view, search, filter and group data by various parameters. For example, grouping errors by unique issues, with a count of instances or occurrences, helps to eliminate the clutter created by multiple instances of the same error.

ASP.NET health monitoring is an easy way to monitor the health of deployed web applications and to gather information related to the health status and performance characteristics of instrumented applications.

What happens, though, when an ASP.NET health monitoring event does not contain the root cause diagnostics related to isolate and resolve an exception? It's a situation AVIcode encounters with organizations quite often, even those companies that are .NET experts and masters at configuring ASP.NET health monitoring.

We recently came across this situation with a security problem that remained undiagnosed by ASP.NET health monitoring. Because the application was already in production, re-configuring health monitoring and modifying the application code was not a reasonable option. Rather, the organization chose to install Intercept Studio.

The following screenshot depicts a typical exception event, similar to what this organization was able to collect, for the security failure. All runtime information, including the call stack, page and user details, parameters passed, custom user code methods, and additional details throughout the exception chain are provided to ensure rapid problem identification, triage and resolution.

In the case of the security problem this particular organization was encountering, Intercept Studio also provided the resource name, failed action details and security context.

The following screenshot shows the event details for a more sophisticated security issue which occurred within the SQL server executing a stored procedure that caused the application code to fail. 

The fact is, it is not possible to be always-prepared for any problem that can occur. And, problems do occur. When instrumentation is not enough, and when modifying in-production code is not an option, a low-overhead solution like Intercept Studio can be implemented on-the-fly to monitor the application state and speed problem resolution by clearly showing you what is going wrong and why.

Welcome to AVIcode's new company blog. We hope to provide you with a range of valuable information related to your end-to-end application performance monitoring efforts, including news, opinions, real-world case studies and application monitoring resources. In addition, AVIcode's technologists are eager to share their experiences and best practices in order to help you ensure the availability and reliability of your critical business applications. We welcome your comments, suggestions and requests. We will do our best to respond in a timely and informed manner. Please check back often or subscribe to our feed so you can be assured of receiving the latest and most timely information.