Event Response

Windows event logs are a crucial source of information for Windows IT pros. They can warn you of impending problems and alert you to security incidents—but only if you keep on top of them so that you can react to problems quickly. Unfortunately, that's easier said than done. Each Windows system has at least three event logs: System, Application, and Security. Domain controllers (DCs) have even more: Directory Service, File Replication Service, and sometimes DNS. Additionally, various Windows components (e.g., IIS, RRAS, DHCP, Internet Authentication Service—IAS) create other text-based logs. With all your administrative and support tasks, you can't hope to effectively respond to those logs' valuable activity without a tool to monitor them and provide immediate alerts. And alerting is only part of the event-log management problem. For the sake of security, capacity-planning trend analysis, and other reasons, many administrators need reporting and event-correlation functionality. Others need to archive their security logs to meet information-security policy requirements or to adhere to recent healthcare legislation for publicly traded companies. Before I share my findings about the three products in this comparative review, I want to take a good look at the functionality you should look for in such a tool.

Agent-Based vs. Agentless
The Windows API that all event-log managers use lets you access event logs on other computers on the network the same as you would logs on the local computer. Therefore, installing an agent component on each system that needs to be monitored isn't strictly necessary. A single process can monitor multiple systems' event logs over the network. Agentless solutions reduce rollout work and don't require that you install software on the servers whose logs you need to manage, which might be especially important if other administrators own the servers and are resistant to installing software with which they're unfamiliar.

However, agent-based systems offer distinct advantages. When monitoring local event logs, the log manager doesn't need to periodically poll the log for new events—it can wait for the OS to wake it up whenever a new event gets logged. Therefore, agents can be more CPU-efficient, depending on how frequently you want to remotely poll a server. Also, local event-log monitoring enables immediate notification, sending you alerts more quickly than is possible with a remote solution. Network traffic is also heavier when you monitor logs from across the network. Although traffic isn't typically a problem when you're monitoring computers on the same LAN, it can create a problem when you need to monitor servers on the other side of a WAN connection.

Alerting
A common capability among event-log management tools is the ability to specify filter criteria based on the standard fields of event-log records, including event type (i.e., informational, warning, error, and audit success or failure), user, event source, category, and so on. You can also filter events according to the contents of the event's description, which can be crucial if you want to generate alerts triggered by specific error codes or other strings in an event's description. To simplify administration, most products (including the three in this review) let you group filters and treat them as a unit. You also typically have more than one way to configure the product to notify you of important events. Email is the most common alert method, but some organizations might prefer to have the product directly page the operator. For such organizations, the event-log manager needs a modem for delivering alerts to numeric or alphanumeric pagers. Most pager services provide speedy delivery of email-based messages, but one of the benefits of modem/dialing paging is that it's out-of-band from an email/IP network−based solution. Therefore, if a page is signaling that your network is down, the out-of-band solution would be resilient and the message would get through.

A more valuable alert method is the ability to specify a command to execute upon the detection of certain events. This option gives you the flexibility to write a script that does whatever you want—for example, restarting a service or taking some other type of automatic corrective action. Although running a static command when certain events are detected is useful, it's more powerful if you can feed details about the event (e.g., event ID, username) to the command so that it can react dynamically. This capability also lets you insert incidents in your Help desk management system.

Speaking of integration, SNMP integration is often valuable for larger organizations because they might already have a systems management infrastructure in place that lacks the ability to monitor Windows event logs. Such companies have been successful implementing a product that monitors Windows event logs and feeds alerts up to the main management infrastructure through widely supported SNMP traps. Similarly, organizations that are UNIX- or Linux-centric appreciate the ability to feed alerts to the already-in-place Syslog server.

Just about every event-log management solution I've seen implements some kind of pop-up alert method, ranging from features that use Windows' built-in Messenger service (aka Net Send or NetBIOS messages) to special client programs that monitor for alerts and pop up appropriate messages. Pop-ups assume that you're in front of your computer—but, of course, we all know that whenever something bad happens, you aren't there.

Another alert method that's closely related to pop-ups is the alert console, which gives you a central view of recent alerts. Sometimes you have errors flooding in from different servers simultaneously, and you don't want to deal with them from a pager. It's better to have a nice, tidy console from which to tackle each event and, as appropriate, acknowledge them and get them "off the scope." A cool feature that I like to see in alert consoles is the ability to enter free-form notes about the resolution of the event.

Three other alert-management features that are important to consider are what I call false-positive suppression, flood prevention, and threshold alerts. You can configure alert criteria for a log manager in two ways. You can configure it to look for specific event IDs, in which case you won't get a lot of needless alerts about unimportant errors and warnings. Or you can use a broader criterion: "Alert me to any warning or error except for those that I specifically say to ignore." I recommend the latter method because you can't foresee every possible situation that deserves attention. However, after you implement broad alert criteria, you'll likely receive false-positive alerts about nonessential errors and warnings. When these alerts occur, you need a way to prevent them from bothering you in the future. Ideally, you could open the log manager's console, select the alert, and suppress the associated event. However, none of the products in this review offer such a turnkey suppress feature—although with some effort and imagination, you can configure them to suppress unimportant events.

By flood prevention, I refer to a situation that sometimes occurs during log monitoring. You've probably witnessed system problems that generate a lot of duplicate events in a short time period. This scenario occurs when a program repeatedly attempts a task but fails consistently and reports the problem to the event log. Flood prevention is a feature that says, "Don't notify me about the same event more than once every 5 minutes"—or whatever time period you specify.

Threshold alerts let you configure the log monitor so that it alerts you only when a specific event gets reported a certain number of times within a certain time frame. This capability is useful for an event that occurs regularly but doesn't indicate a problem unless the system starts logging it very frequently.

   Previous  [1]  2  3  Next