Logging and Application Instrumentation

In the final instalment in this series on logging in the .NET world, the focus will switch to enterprise tools that allow operations staff to collect the output of the various logging frameworks and techniques that have been covered to date, and, once this data has been collected, act and report on this data in a timely manner. After looking at how these products work, and focusing in on Microsoft’s offering in this area, the article will conclude with an overview of how developers can ensure that the systems they build interact well with monitoring tools and also cover techniques for deeply integrating with these tools.

The motivation for an enterprise-level management tool is obvious to those that have been involved in or observed the operational management of any sizable IT department. Users and managers expect the systems that they rely on to get their job done to be available and capable of delivering high levels of performance. As the number of hardware and software assets under management grows, the small-shop practice of regularly scanning event logs and occasionally ensuring hard-disks are not too low on storage rapidly fails to scale to the increase management demands. A management tool that can automatically perform these tasks, and raise timely alerts in the event of a system failure, is required.

This material is often seen as little interest to developers, and the traditional view has been that once the code is cut, tested and built into a deployment package, the hard work is done. This attitude is clearly naïve, and organisations will typically spend more money on applications during the post-deployment operational phase rather than the pre-deployment development phase. Given that development can strongly influence how easy it is for an application to be managed, it is worth conducting this brief detour from the code-centric view of the developer into the world of the IT operations management team.

Management Packs group Rules into Rule Groups, and have various other configuration sections like Computer Groups that Rules Groups apply to, Providers for use in creating the Rules and Override Groups that can override rules for a particular computer or group of computers. One item of particular interest is Tasks. A task is a command that can be executed either on the MOM server in the case of a Console Task or on the monitored computer in the case of a Runtime Task. Tasks provide a way to store a script or action that can be run to diagnose or rectify a problem relevant to the Management Pack. For example, a Console Task may involve pinging the monitored machine to see if it is responsive and a Runtime Task may involve running IPConfig on the monitored machine to flush the DNS cache and renew the IP address.

From this description, it is apparent that a Management Pack is essentially a codified operations manual and set of best practices that would have been performed manually in the days before shrinking IT budgets and increased server numbers made manual monitoring infeasible. Large IT departments will clearly want to develop custom Management Packs that conform to their existing workflows and procedures, but for smaller organisations , and even larger organisations looking for a good starting point, pre-built Management Packs will be preferred.

MOM Server 2005 ships with a Management Pack that monitors the actual MOM Server, and the MOM distribution disk also contains Management Packs for the Baseline Security Analyzer, Exchange Server, SMS Server, SQL Server, Active Directory, Base Windows Operating System, DNS, IIS and Windows Clustering. In addition, there are literally hundreds of Management Packs available from the http://www.microsoft.com/management/mma/catalog.aspx, and these include packs from various vendors like Dell, HP and Citrix as well as ISVs that specialize in management software. For all off-the-shelf software and hardware systems, there is a strong likelihood that there will be a Management Pack available to support its monitoring.