Showing posts with label scripts. Show all posts
Showing posts with label scripts. Show all posts

17 May, 2007

Ticks & Leeches

One of my tasks as a System/LAN/Windows Administrator is putting together performance graphs of various systems I administer. Among these systems is an e-mail content scanner that performs content and virus scanning of incoming e-mail before it reaches the back-end storage server. Like most applications, this e-mail content scanner works fairly well once it is properly configured and the annoyances are beaten out of it. To properly beat the annoyances out of an e-mail gateway, it helps to have current and historical information about its performance in an easy to read web interface-- and 9 out of 10 IT managers love it. To this end, I use MRTG.

My method, while involved, is rather straight forward: Install a configurable SNMP provider on the host(Windows); create custom MIB/OIDs that use the NT Performance Counters provided by the application; populate an MRTG configuration file with these custom OIDs as targets. As long as the performance counters I want to query exist, this works like a charm.

Let me tell you why I am mad: Between major version releases the good folks from whom I purchase e-mail content scanning software decided to replace a counter I considered integral to monitoring the performance of the software: "messages queued for processing." They chose to include a counter of the time difference between the receipt of a message and its processing. While the latter is quite useful, it is no replacement for the former. Who would not want to know how many messages are piled up on the server awaiting an available processing thread? My only conclusion to the rationale for this is they, the software manufacturer, want to sell a plugin (pronounced: custom dll) for the SNMP agent/provider of their choosing.

The workaround: I will write a quick and dirty script to count the files the queues on the content scanning server; make this an extension in my configurable SNMP provider with its own MIB/OID that calls this script; and configure an MRTG target with this OID. Subsequently, I shall prepare myself a sandwich.