System Info Reporter

As part of supporting a software system which is in production, the support people usually keep track of a lot of information about the production servers. This information may have to do with hardware (how much physical memory is installed, what is the capacity of hard drives) or with software (what version of .Net is installed, how much have the tables of the production database grown, what are the versions of the .Net assemblies deployed). With the complexity of even small scale solutions growing every day, system information can become important for the support personnel. Unfortunately in the majority of cases no particular methodology is used to extract and keep track of such vital information.

System Info Reporter (SIR) is a tool which can be used to provide such information. Implemented as a .Net console executable, SIR tries to provide a small footprint and is meant for scheduled or manual execution. Once run, SIR scans the server it runs on (or other servers) and collects information. That information is written out to system information reports which can be sent to support or monitoring personnel on a regular basis, creating a trail that shows the current state of the server.

The architecture of SIR is highly modular to allow for easy extensions and customizations. The core of SIR is comprised of a simple console client that loads two types of plugins: writers and collectors. Writers are .Net libraries that create the system info report step by step. Collectors are .Net libraries that implement a data gathering method suitable for a particular situation.

Provided functionality

The current version of SIR offers the following build-in plugins:

• Debug writer. This is mostly a test-bed writer plugin. It outputs collected information to the windows debug output stream.
• HTML writer. This writer generates a simple HTML report.
• Text writer. This writer generates a simple text report.
• PDF writer. This writer generates a simple PDF report. This is achieved by using iTextSharp.
• WMI collector. The WMI collector can be used to run WMI queries and search the results for particular pieces of information. Given the power of WMI, this collector can be used to gather a lot of information out of a system.
• Services collector. This collector gathers information about the configured windows services of the local server.
• Registry collector. The registry collector reads sections of keys from the registry and includes them in the system info report.
• MSSQL collector. The MSSQL collector connects to a Microsoft SQL server and executes a query or series of queries against a specified database, then includes the results to the system info report.
• Event log collector. This collector retrieves entries from a given event log of the local machine or from a remote server.
• Directory collector. The directory collector traverses specified directories looking for files matching a given file mask, then outputs the details of these files to the generated report.
• Assembly collector. Works much like the directory collector, but tries to load .Net assemblies and report on their version.
• GAC collector. Gets information about the assemblies located in the global assembly cache.
• Ping collector. This collector can ping a series of servers to determine whether they are reachable or not.
• TCP port collector. The TCP port collector attempts to establish a TCP connection to a series of server ports and determine the availability of TCP services.

If a writer creates file-based output, SIR can compress the file contents in a zip file. This is achieved by using SharpZipLib.

Who would use SIR?

System administrators and support personnel tasked with monitoring and supporting a system.

Limitations

Considering the fact that SIR can gather information from a lot of sources in a batch-mode manner and generate a report, it is a good tool to use for that job. However, SIR is in no way a substitute for more tight monitoring of a server and that's the main reason why there is no Performance Counter collector. If perfmon seems more like the tool to use for a monitoring job, then it's certain that SIR is not a good alternative.

On the presentation level SIR writers are data-agnostic, meaning that they have no knowledge about what the information they output to a report represents. Although that is a good way to promote abstraction of writers, it also imposes a limitation and is the reason why nifty-looking reports cannot be created by SIR.