The actual mechanics of flipping the Performance Monitor switch has changed a bit since Windows NT, but not significantly from Windows 2000. The major components consist of the System Monitor, Performance Logs, and Alerts. The System Monitor simply displays realtime information that is being monitored. Counters can be added by right-clicking on the counter pane in the lower right-hand corner of the window. The System Monitor portion of Performance Monitor is your primary realtime troubleshooting tool.

Performance Logs and Alerts is the primary tool by which you can create baselines, document activity, and also track objects and counters over a period of time. The purpose behind creating baselines and tracking data over a period of time is to perform what’s known as trend analysis, which is basically the concept of gathering enough information to be able to point out specific patterns in the data that point to real actions that are going on elsewhere on the system. An example might be if you found that processor queue lengths increased every day around 8am, then you might conclude that the logon traffic generated over the network might be taxing the CPU. Rather than purchasing an additional CPU, you can modify server and domain configurations in such a manner as to perhaps offload some or all of the login processing to another system, and thereby relieve the stress on the CPU. Again, if the current CPU queues at 8am do not exceed the norm CPU queues at that time, you’ll need to look further and deeper for the culprit(s).

The Performance Logs and Alerts section is divided into three subsections: Counter Logs, Trace Logs, and Alerts. With Windows NT, all logs were the same, and these divisions didn’t exist, which often made it easier to create a new log rather than use an older one.

Counter Logs are the logging equivalent of what you see within System Monitor. Right-clicking on an empty section of the right pane will enable you to create a new log and subsequently define the logfile, its output type (text, binary, etc.), and the objects/counters that the log will maintain. Again, objects are the equivalent of major systems or hardware on the server. Counters track specific events related to a given object. Unlike Windows NT, you have the option for choosing all counters within a single object, or choosing multiple counters that belong to separate objects. The purpose, again, is to enable you to track only the information that has the impact that you are searching for.

Trace Logs are something of an extension of the Event Viewer, in that they essentially track everything that the system does, but only after a specific event has occurred, such as a page fault or disk i/o. These events are tracked for a specified period of time, and each triggered trace log is stored in a separate file or in a single FIFO (first in, first out) bucket, which will reduce disk space, and trend analysis capabilities accordingly. Generating a new logfile for each event allows for both quick and enhanced viewing: simply looking at the number of logs generated over a period of time for a page fault might alert you that there are either paging or disk problems on the horizon. Looking at the trace data itself (which must be parsed for viewing) can glean additional specific information about the system at the time the fault occurred.

Alerts are similar to trace logs in that they perform one or more tasks based upon a specific event occurrence, however, they offer more flexibility in the types of events that are available, and also the tasks that can be performed. Just like System Monitor and Counter Logs, Alerts are counter-based, and are generated once a set threshold has been met. Once this threshold (or event) has been met, the system has some pretty powerful capabilities. First, it can generate an event in the Event Viewer. It can also send a network message to someone (usually an administrator), or run a program (any program actually) that will page or e-mail someone with information. The true value in the Alerts option lies in the fact that once a threshold has been met, it has the ability to start a Counter Log that has already been saved and configured to handle further monitoring after the event has occurred. As an example, let’s say that page faults are running high, and an alert has been created based upon your pre-existing knowledge of what the norm is, and what you would perceive to be ‘high’ based upon the specific system. Page faults can be due to disk problems or memory problems. Following the road toward the process of elimination, you can set up an alert to subsequently trigger a counter log that monitors both disk and memory performance. The result is that with little or no intervention from you, you can then view the counter log and determine where the offender is, and take the appropriate actions.

There are several new commands with Windows Server 2003 which allow you to administer Performance Monitor on the command line. These commands are: LOGMAN, RELOG, TRACERPT, and TYPEPERF. All of these commands involve a hefty syntax. Logman is the command equivalent of Counter Logs; Relog is used to copy logfiles into new files of different filetypes; Tracerpt is the command equivalent of Trace Logs with the additional feature of being able to create comma-delimited files for trace logs, which is a feature that is currently unavailable for the GUI-tool; Typeperf is similar to the TYPE command in that it displays performance monitor data on the screen without requiring that the log be translated (RELOG) into a human-readable format. [Diana Huggins]