These products make it easy to monitor and manage your event logs
Editor's Note: In the October 2007 Table of Contents, John Green's "VPN Firewalls for SMBs" was mistakenly printed with InstantDoc ID 95955. To read this October comparative review, please see InstantDoc ID 97173.
Our servers, applications, and network appliances are, at least from one perspective, black boxes that provide few external indications of what each is actually doing. Event information they produce is one of the few views we have on their activity. As anyone who has used event log information knows, it can be arcane and voluminous. Turning all that raw data into actionable information is as much an art as a skill. Common motivations for using event log information include:
Looking for clues to understand why something didn’t work as expected
Security monitoring—that is, detecting unauthorized activity
Monitoring the health of systems and applications so you can respond quickly to issues
Archiving and reporting information in support of regulatory compliance
Event Log monitoring and archiving is the common thread linking the six products I review here. All support Windows event log and syslog monitoring and archiving, and several offer additional monitoring functions.
Vista adds another wrinkle to event log management. Its new Windows Eventing 6.0 infrastructure significantly extends the capabilities of Event Tracing for Windows (ETW), the APIs and interfaces in use since Windows 2000. Microsoft reports that “enhancements are provided while preserving full compatibility with the existing Event Log and ETW APIs, which means that all existing applications will continue to work without change." In the course of my testing, I learned that in some aspects, this is not strictly true. For all of these products, specific Vista support is forthcoming and not available in current product releases.
Breakout Software MonitorIT 8.0.19
Breakout Software’s MonitorIT version 8.0.19 is more than an event log management tool. MonitorIT monitors not only Windows event logs but also syslog output; IP-based services such as SNMP, HTTP, FTP, SMTP, POP3, DNS, and Telnet; and SQL Server and Oracle database servers. In addition, this product lets you create custom monitors for any IP port. Systems running the MonitorIT agent can also monitor services, processes, files, and performance counters.
MonitorIT requires a license for each monitored system, including the number of monitored IP addresses. Breakout Software also licenses the application to Engagent, which markets the application under the name Sentry II.
Architecture
MonitorIT is a server-based application that communicates with an agent service installed on each monitored system. Although, you use the MonitorIT Configuration File Utility to set a very few server-oriented settings, administrators perform most setup and administration tasks using an Internet Explorer (IE)–based console. Agents initiate all communication with the server with encrypted data via a proprietary protocol, including a periodic heartbeat packet that the server reflects back to the agent. Although the IE-based console initiates communication by default via port 81, console ActiveX Controls encrypt and transmit data between the console and the server via the agent port.
Using the IE console, Administrators create monitoring rules, called "watches." You can configure several kinds of watches. Server Watches monitor IP service ports, such as mail and Web. SNMP watches monitor SNMP traps sent to the MonitorIT server from authorized devices, whereas SNMP Counter watches poll SNMP MIBs on remote devices. Syslog watches receive syslog output from appliances and Linux/UNIX devices, with options to log all output to a text file, and some events to the database. Windows systems running the MonitorIT agent can load Event Log Watches, Process Watches, Windows Services watches, File Watches and Windows Performance Counter watches. For each watch assigned to a monitored device, MonitorIT writes the related information to its database. Each watch type offers a variety of capabilities. For example, Process watches will alert you to high levels of CPU and memory utilization in addition to the simple presence or absence of specific processes. MonitorIT lets you configure watches and alerts for custom Windows event logs in addition to its set of predefined standard event logs—you simply provide MonitorIT with the name of the associated EVT file.
When you create a watch, you can configure associated actions, called "alerts." Most alert actions notify you of the presence or absence of specific conditions. Notification may occur via email pager, beeper, and syslog and SNMP trap. You can also execute a program or script, either initiated on the remote system by the MonitorIT agent, or executed on the MonitorIT server.
Monitor IT will make use of an ODBC database such as SQL Server, and defaults to using an Access format database. Breakout Software also supplies a MonitorIT.mdf file, which you can copy to your SQL Server system and attach when you create the MonitorIT ODBC Data Source Name (DSN).
Hands On
Initial installation of MonitorIT took only a few minutes. I chose to use the included Access database rather than a SQL server. Upon starting the console, I was presented with some basic startup steps to guide me through the initial configuration of systems, watches, and alerts. I started by using MonitorIT’s Discovery feature to display a list of available systems. I selected one and had MonitorIT push an agent out to one system, which it did with no problem. I also installed the agent to another server using the “pull” method, initiated by using IE to browse to an InstallAgent.asp file on the MonitorIT server Web site. In both cases, MonitorIT then displayed the system as a valid target I could assign watches to.
I’ve worked with quite a few products that made use of Web-based management consoles and have noticed large differences in their look, feel, and overall utility. Some consoles seem to respond slowly and have a design that isn’t particularly efficient for the task at hand. MonitorIT’s console was usually responsive—I didn’t often sit and wonder when the screen would respond. Relatively slow reporting tasks were a notable exception. The console’s organization made it easy to find the function I wanted. As Figure 1 shows, an Outlook style menu is along the left side, and a pull-down menu supporting the task in a new window is available on the right—a convenient option.
I assigned watches to systems from the Server’s Agents and Devices screen by displaying the server name, clicking the Eligible Watches button, and selecting the watches I wanted to apply from the screen that displayed.
MonitorIT archives event log data by saving and compressing event log files and copying them to a central storage location. The Archive menu provides options to create archive schedules and assign them to servers. A schedule designates how often event logs will be copied to the archive location and allows administrators to have logs archived on the basis of how full the logs are.
The Web console includes extensive Help information, which I found useful whether I wanted a general understanding of some aspect of the program or of what a specific configuration option would do.
MonitorIT seemed to use a lot of CPU cycles. Running in a virtualized Windows Server 2003 system, the Task Manager display for the host system showed one of the two CPU usage history displays at 100 percent utilization, and the utilization stayed at that level. Stopping the MonitorIT server service in the virtual server returned CPU utilization to less than 10 percent on both processors. After I restarted the MonitorIT Server service, one CPU ran again at a consistent 100 percent. This could have been a result of using the Access database on the same server, because I used a version of SQL Server in my testing of other products.
MonitorIT is supplied with only a few standard reports. It does let you view current and archived event logs subject to a specified date range and event filters you can create and save, with an option to report from either archived EVT files or events captured in the database via watches. Once MonitorIT generated a filtered view of event log data, it gave me the option to print, email, or export the report data to a comma-separated value (CSV) file on the server.
Summary
If event log reporting is your primary need, MonitorIT doesn’t provide an ideal solution. Its strengths lie more in the area of system and application monitoring. It had fewer predefined event log alerts and filters than the other products I reviewed and didn’t have a facility to create a new watch from an existing event log entry. It does a good job copying native Windows event log files to a central location for archiving but doesn’t provide tools for archiving metrics written only to the database. It is an effective, value-priced application--just expect to spend some time customizing your implementation.
|
Breakout Software MonitorIT 8.0.19 Pros: Monitors a broad range of metrics in addition to Windows event logs and syslog output; the ActiveX-based Web console is responsive and easy to navigate Cons: Relatively few predefined Watches and reports, no explicit procedures for archiving database-resident metrics Rating: 3 stars Price: Starts at $110 for 1–499 servers, $38 per server for 500–999 servers Recommendation: Although MonitorIT is an effective, value-priced alternative for system monitoring and log archiving, expect to spend some time customizing your implementation. Contact: Breakout Software ? http://www.breakoutsoft.com ? 908-561-5210 |
Dorian Software Total Event Log Management Suite
Dorian Software's Total Event Log Management Suite comprises four separately available and installable components. Event Alarm 5 monitors servers and performs notification. Event Archiver 6 collects events and manages event retention in files and a database. Event Analyst 5 supports reporting against archived events in Total Event Log Management Suite–created databases and saved event log files. Event Rover 1.1 retrieves and displays events remotely from active and saved event log files, primarily for rapid ad hoc analysis. The first three components make use of a database—SQL Server, Oracle 9i, or Access—to record and work with monitored events. Together, the components of Total Event Log Management Suite monitor and manage Windows event logs and syslog output. Dorian licenses the suite on a per-monitored-server basis, and lets administrators choose whether to install a software component locally or to monitor the server remotely. Syslog sources don’t require a license.
Architecture
Each of the three key components is supported by services running on the server on which they're installed. Windows event log monitoring is performed by the Event Alarm service without an agent installed on a monitored system. A single Event Alarm server monitors systems throughout the local network, although Dorian recommends that administrators install additional Event Alarm servers at remote sites and in isolated or protected network segments. The Event Alarm Syslog Bridge service receives syslog output from network appliances and Linux/UNIX systems and places the messages into the Windows application log, where the Event Alarm server processes them. The priority of the syslog message becomes the event category in the application log, and the Syslog Bridge service places the source IP address and message text in the Description field.
Within Event Alarm, administrators configure alarms and associated notifications based on log events, and Event Alarm installs with many preconfigured alarms. Administrators may create alarm groups, which are named collections of alarms. Assigning alarm groups to servers with similar monitoring requirements reduces your administrative effort.
Event Alarm allows you to create named sets of notification options, resulting in one or more of the following notification actions: email and pager messages, Windows console pop-up messages, messages to Event Alarm Listener Consoles and syslog host consoles, and insertion of the event into a database. The ability to consolidate both syslog messages and Windows event log messages and to forward selected messages to a syslog host server supports a unified event notification option for organizations that have a Linux/UNIX orientation. Similarly, the Event Alarm Listener Console, intended for use on administrative workstations, provides unified event notification for Windows-oriented administrators. Minimizing to the system tray, the Listener Console alerts the workstation user to the presence of new alarms.
To begin monitoring, you assign alarms, alarm groups, and notification sets to event logs on individual servers. Event Alarm allows you to designate alarms and alarm groups as "Events to Ignore," which takes precedence over monitoring specifications. As a result, you can create broadly inclusive monitoring groups and filter out specific events you know are of no interest. Event Alarm offers several tools that ease the configuration of multiple monitored servers. Rapid Configuration Setup is a check-box approach to selecting monitored servers and alarms by which Event Alarm creates alarm groups for the alarms you select and assigns them to the appropriate event logs on the servers you specify. A pair of wizards lets you create or modify a monitoring configuration with greater granular control, including the ability to specify "ignore" events. Other wizards let you set uniform event logging and event log file management policies across monitored servers.
Event Archiver collects and consolidates Windows event logs locally or remotely by using the standard Windows event log API and shared folders. Event Archiver runs as a service, using an account with administrative access to monitored systems. Administrators specify how frequently Event Archiver will stage a copy of the event log in EVT file format and optionally clear event log files on the target system. Event Archiver will convert the file to a comma-delimited format or load the data into an Access, SQL Server, or Oracle database. (Access need not be installed on the server for Event Archiver to create an Access format database file.) As with Event Alarm, a pair of wizards supports setup and maintenance of archiving schedules for multiple systems. In the event of any kind of a failure during archiving, Event Archiver will retry the operation over a two-day interval and will send notifications that you can configure. Event Archiver will compress event files and move them to a network share or FTP sever for long-term retention. When you need to use historical data, Event Archiver will move a selected set of event files to the database of your choice. An option to include or exclude specified event types lets you reduce the database disk space used. An optional utility, Event Archiver Importer, which is free when you purchase the full Total Event Log Management Suite, will automatically consolidate event logs collected by several Event Archiver servers. Administrators would need to configure each Event Archiver server to send event files to a common network destination. Event Archiver Importer monitors that folder, automatically loading log files to your database.
Event Analyst reports on and exports event log information. It will use data from active event logs, event files, and text files that Event Archiver creates and database tables that Event Alarm or Event Archiver creates. When you use Event Analyst to open a file or database table, it displays some of the records in a View window. The records displayed depend on a maximum display count you configure and on event filters you apply before opening an event log source. You can filter the retrieval and display of EVT and text log files by using Basic filters, and you can use Advanced filters—which allow for advanced filtering, including matching text strings and time-of-day filtering—database tables. Event Analyst ships with many preconfigured Basic filters. From the View window, you can display event details and link to a Dorian Web site for more information about many event types. You can export filtered or unfiltered data in comma delimited, HTML, or Access database format, or send it to an ODBC database. Event Analyst ships with many predefined report formats and lets you create custom reports as well. When running or scheduling reports, you can request that they be written to network shares in either HTML format or comma-delimited text file format.
Hands On
Installation to a Windows 2003 system was fairly uneventful. Curiously, the documentation supplies lots of useful information relevant to various implementation scenarios but never describes the actual installation procedure. I needn’t have fretted. The first time I started up the Event Alarm Control Panel, it walked me through an initial configuration. After designating an administrative service account and setting some preferences, the Event Alarm Control Panel started the Rapid Configuration Tool, which allowed me to select systems, logs, and events to monitor and to create notification sets to use for alarms. I specified writing events to raise an alarm to a database. The tool walked me through creation of an ODBC DSN. Because I wanted to store events in a SQL Server 2005 system, I needed to first create the database (using SQL Server Management Studio) to specify in the ODBC DSN. Event Alarm took it from there, creating the table before adding event records.
I installed Event Archiver next. Like Event Alarm, it is preconfigured with events and event groups for easy startup. I created a new database to specify in the ODBC DSN and selected the option that had Event Archiver create separate tables for each event log type. I found I could group server configurations together or create a configuration unique to a particular server and event log. The ability to have Event Alarm and Event Archiver log events to different databases using different filtering criteria added both complexity and flexibility. For example, an administrator could use Event Alarm to log events for immediate follow-up, and create Event Archiver filters with compliance reporting in mind. I configured Event Archiver to manage event logs for several systems, requesting hourly processing and sending event log data to the database, and compressed event log files to a network share. It all happened easily. I also enabled the option to prune old records from the database—I set it to one day for the test—and let it run. I also had Event Archiver create a SQL Server table using some of the compressed EVT files for another reporting test. None of this was difficult.
Event Analyst was next. Again, the installation proceeded quickly, and using the Event Analyst GUI I was able to open and view events from the database tables I had created and from EVT files. Running a report was a three-step process: open an event log source, apply a filter to limit the events included in the report, and run the report. I ran quite a few reports against both database sources and EVT file sources. Event Analyst limits EVT file input to a single file but makes it easy to select many EVT files and load them into an Access, SQL Server, or Oracle database file. Creating custom reports in Event Analyst is as easy as I’ve seen. As Figure 2 shows, the Report Designer presents you with a grid of boxes. Each click on a box reveals the next available data field. A single field in one of the top rows defines a sort and grouping field. The last row defines the fields you want to appear in the detail line.
Summary
Total Event Log Management Suite is an attractive event archiving and reporting solution. The modular approach mean you can purchase only the function you really need and didn’t seem to seriously complicate administration, except perhaps when it came to defining filters and alarms. Because both are based on the same sets of events, there is potential for some synergies by sharing the common elements and exposing across the three modules. Implementation is simplified by the lack of a need to install agent software on managed systems. Overall, I found it easy to use, with a useful set of predefined filters and reports and relatively easy procedures for creating custom filters and reports. It is strictly a log management solution and lacks the system-monitoring features found in some of the other products I tested. This isn’t a bad thing when log management is really all you need. The ability to collect from syslog sources without additional license requirements will appeal to administrators responsible for many network appliances and those who want to centralize syslog archives from Linux/UNIX systems.
Dorian Software Total Event Log Management Suite |
GFI Software EventsManager 7.1
GFI Software's EventsManager 7.1 monitors and archives Windows event logs, syslog output, and World Wide Web Consortium (W3C) log file information. It installs with a large number of predefined filters, facilitating a quick implementation. Event filters let you configure real-time notification for selected high-priority events, and EventsManager offers suggested remedial actions for many events. A new add-on of interest to larger organizations consolidates into a single database the event information collected by EventsManager servers at various company locations and incorporates facilities to help you manage database size and record retention. The separately installed GFI EventsManager ReportPack, included in the product license, includes a variety of predefined reports and enhances your ability to report on events that EventsManager collects.
Architecture
EventsManager is a server-based product and doesn't install an agent on monitored systems. To collect Windows EVT and W3C logs, an Event Retrieval Engine logs on to the remote system and retrieves event data by using standard Remote Procedure Calls (RPCs) and the ETW API at times determined by a schedule you set. An Event Receiving Engine on the server acts as a syslog host to collect syslog information directed to it. Once event data is received, EventsManager processes the events against a set of rules and optionally archives the events to a SQL Server database. Another option lets EventsManager unconditionally archive all events for all specified logs on selected servers without invoking rules. When you call for the use of rules, EventsManager will filter out uninteresting events and optionally alert you to selected events. Alerting actions may include notification via email, Short Message Service (SMS) and Network Messaging (Net Send), and you can run a script or program (typically to perform some remedial action).
Rules let you specify the criteria within an event that will cause EventsManager to select the event for further processing. Rules can be organized into named rule sets for ease of management and application. Monitored computers can also be organized within named groups. An Event Log Scanning Profile is a named set of rules and rule sets that you can apply along with other configuration settings to monitored computers or groups of computers. Administrators can apply several Scanning Profiles to a computer or a group. This lets administrators augment profiles that apply to many or all systems with Scanning Profiles that are customized for a particular application or server. Administrators can use predefined or custom queries and event filters to browse and report on collected events stored in the database.
Hands On
EventsManager is intended for installation on Windows Server systems configured with Microsoft Data Access Components (MDAC) and .NET Framework 2.0. Access to a system running MSDE or SQL Server 2000 (or later versions) is also required. I installed to a Windows 2003 system with SQL Server Express 2005 Advanced Edition also installed. Initial software installation was quick, and left me with the GFI EventsManager Management Console, a GUI-based program, displaying a Component Configuration Quick Start menu. It guided me through configuring the SQL Server database, configuring an Administrator account and alerting options, and finally designating systems to monitor. It took just a few minutes to complete the first three steps, and not much longer to designate a few systems to monitor. EventsManager installs with fourteen predefined groups, each configured to use a collection of rule sets appropriate to the group. Four other groups—for Windows domain controllers (DCs), other Windows systems, Microsoft IIS W3C collection, and syslog collection—are preconfigured to simply archive collected events without processing rules. I can’t imagine an easier way to get an initial configuration up and running.
By default, EventsManager connects to monitored systems by using the administrator account that the EventsManager service runs under, which I provided during installation. If necessary, you can provide alternate credentials by using a system or group Properties panel.
The GFI Events Manager Console, which can’t be installed at a workstation for remote management, is well designed and easy to navigate. As Figure 3 shows, the primary tabs Status, Configuration, Events Browser, and General are gateways to key functional areas. Status screens show collection counts, the status of monitored devices, and a log of recent collection activity. Configuration screens are where you configure rules, rule sets, and monitored systems and configure rule processing and archiving. Events Browser provides access to recent event information.
Display and reporting of collected events are the measure of the utility of log management products. I found the Events Browser to be easy to use for quick investigation of events. Facilitating real-time alert response, EventsManager displays a user-friendly interpretation of selected events, as Figure 4 shows. When browsing Windows event logs, each monitored event log displays along the left side of the display. Under each log type, a series of predefined folders and/or queries is presented. Each query filters the display of collected events. For example, within the security events log, Account Usage is a query category, with queries filtering for successful logons, failed logons, and account lockout events. One of the predefined event processing rules selects logon events occurring outside of normal working hours, and I was able to quickly create a custom filter displaying only events captured by that rule.
Reporting is supported by the EventsManager ReportPack, a separately purchased module that runs within the context of GFI’s Report Center 3.5, which manages reporting for many of GFI’s products. I downloaded and began the ReportPack install, and it in turn downloaded and installed Report Center. Like EventsManager Console, Report Center presents an Outlook 2003–like interface. It includes 34 default reports that you can customize and schedule by using easy-to-follow wizards. I found I could run any report from its right-click menu for any of several time periods relative to today. After manually running a report, I could email it in PDF, Word, Excel or RTF formats, or export it to a file in any of those formats in addition to HTML and a data-only Excel format. When scheduling reports, I could select any specific date or date range or one of the five relative date ranges: that is, today, yesterday, last seven days, this month, and last month. The reports I examined all included both graphic and tabular representations of selected data. This is a very well implemented reporting feature.
Summary
Overall, I was impressed by GFI’s EventsManager and ReportPack. It seems apparent to me that the product’s designers had both ease of implementation and ease of use in mind and accomplished those objectives in these products. The key area in which I felt EventsManager fell short is the lack of support for remote workstation installation of the GUI console. EventsManager is easy to recommend to anyone whose log management needs are limited to the three types EventsManager supports.
|
GFI Software EventsManager 7.0 Pros: Many predefined events to facilitate implementation; a well designed, easy to navigate GUI console; and many predefined display filters that can be easily augmented with custom display filters Cons: The GUI console can’t be installed remotely, so you must use a remote desktop product for remote administration; has a facility to log all events to the database but not to archive raw EVT files Rating: 4.5 stars Price: Starts at $800 for three nodes Recommendation: Events Manager is a well-designed, easy-to-use log management product for Windows event logs, W3C format log files, and syslog output, with an excellent report management option. Contact: GFI Software ? http://www.gfi.com |
Prism Microsystems EventTracker 5.6
Prism Microsystems' EventTracker monitors and manages Windows event logs, several variants of syslog output and text-based log files. Version 5.6 is about to be supplanted by version 6.0 later this year, which will offer full support for Vista’s event channels. Another product, EventLogCentral, provides Web-based access to reporting and analysis using the data that EventTracker collects. Other optional components are available that support monitoring server health and receiving SNMP traps.
Architecture
The EventTracker server is recommended for installation on a Windows 2003 system and is supported under Win2K and XP as well. An agent installed on monitored Windows systems manages event logs, and EventTracker also supports agentless monitoring of Windows systems with a more limited capability, which I describe shortly. Functionally, EventTracker consists of a Console Server, which communicates with monitored systems; several services, which run on the console server; three Web sites for remote administration and reporting; and agent services. which run on monitored systems. Prism Microsystems offers two optional agents for use with EventTracker. A High Performance agent is designed for use on DCs, where event-generation rates can create performance problems. An agent for Solaris C-2 translates Basic Security Model data into EventTracker events.
Data storage is in Microsoft-style compressed cabinet format (CAB) files, rather than an ODBC-style database. Prism Microsystems determined that for log management, using a CAB data structure resulted in both disk space and performance advantages, as well as eliminated the need for database-management skills.
EventTracker uses Active Directory (AD) user-based authentication and defines access roles for each user that determine what the user can do and permissions that specify which systems a user can work with. By using the Web interface, you can safely grant appropriate access to the information EventTracker collects to various group in the organization—Help desk staff and auditors, for example.
The EventTracker Correlation engine, EventTracker's rule-processing component, works using Linux/UNIX style regular expressions for matching rules to events, which provides a powerful, flexible approach to rule correction. I didn’t count them, but Prism Microsystems advertises that they include more than 500 predefined rules in EventTracker to facilitate rapid implementation.
As an event log monitor, ET collects events from Windows Vista/XP/2003/2000/NT, syslog and syslog-ng, Solaris BSM, SNMP and any flat file log. In addition to log monitoring, agent-supported systems monitor CPU, memory, and disk utilization metrics; processes exceeding threshold; failing services; and network connections. When monitoring flat files, EventTracker matches text by using regular expressions and maintains a bookmark to the file so that it scans only new log information. Prism Microsystems includes knowledge modules to assist in monitoring flat file logs that IIS, SQL Server, and a few proprietary applications produce. EventTracker 6.0 will add support for Vista and for Checkpoint firewall logs.
Hands On
I installed EventTracker on a Windows 2003 SP1 system configured with IIS. The installation process required that I install three components, followed by some post-installation configuration. First, I installed EventTracker core components, followed by the EventTracker Correlation engine. During installation of the EventTracker components, I was able to specify where to place the database files that EventTracker installs. Next, I installed EventLogCentral 2.0, the Web-based management interface. A readme file that displayed at the completion of the latter step had me configure IIS, the .NET Framework, and an EventTracker report directory. Console access is governed by membership in two AD user groups. All users must belong to an EventTracker group, and administrative use is restricted to those who are also members of an EventTracker Admin group.
When I started preparations for this review, one of the first things I noticed was the 968-page User’s Guide, including the 280-page chapter on reporting. Although that may sound daunting, the manual isn’t as onerous as it might be: It makes liberal use of screen images to illustrate the points it makes.
EventTracker has three primary user interfaces. A GUI interface runs on the EventTracker server and is used to manage monitoring, analysis, and reporting. When you are working on the console, an EventTracker Control Panel provides shortcuts to many of the control and analysis functions within the GUI console.
I started in the System Manager console, where you create groups to organize monitored computers. You can choose to have EventTracker assign systems to a group based on IP subnet membership or server/workstation OS classification, and you can create a group for simple manual assignment of systems. When you want more information about a particular event, EventTracker provides it with a link to Prism Microsystems' kb.eventlogmanager.com Web site. Alerts actions include running a script executed on the console server, as will as notifications.
EventLogCentral is the Web-based interface used for reporting and user management. EventTracker makes use of a Crystal Reports–based reporting facility and supplies more than 500 report templates, including sets of compliance reports for the Health Insurance Portability and Accountability Act (HIPAA), the Sarbanes-Oxley (SOX) Act, the Federal Information Security Management Act (FISMA), the Gramm-Leach-Bliley (GLB) Act, and PCI Security Standards.
Within the console, administrators can restrict user rights at a granular level by creating and assigning EventTracker Roles to individual users. Role granularity includes 45 separate viewing options, with fewer add, modify, delete, and report options. Further, you can restrict a user’s access to specific groups of computers.
Using Event Log Central to view recent events, I found it easy to home in on specific types of events on specific systems. EventTracker offers a wide variety of successive views to narrow the scope of event display and lets you sort events by clicking on a column header. I experienced good response time when using this part of Event Log Central.
The screens you use to select and configure one of the predefined reports are easy to complete, and you can save reports in either .pdf or .doc file format. However, when I attempted to run a report, it started cranking away and I lost patience waiting for it.
Summary
EventTracker has a lot of power and flexibility. For example, it supports role-based user access with permissions to specific server information. At the same time, I found the user interfaces less intuitive to navigate than other systems. The 21 shortcuts into the EventTracker GUI console found on the Event Tracker Control Panel illustrate my point. For example, if you want to add new monitored computers or groups, you must use the System Manager applet, when access to the function from a right-click menu in the navigation pane would have been more convenient. I created new system groups, yet they didn’t show up in the auto refresh–designated navigation pane unit I selected Refresh from the view menu—selecting Refresh from the high-level All Computers container didn’t do it. In terms of response time, the console didn’t feel very fast. I found myself waiting not only for event filters to take effect but even when closing management applets. Overall, although EventTracker boasts an impressive list of capabilities, I found the organization and responsiveness of the user interfaces lacking.
|
Prism Microsystems EventTracker Pros: Designed with a broad scope of capabilities; supports both agented and agentless monitoring; includes a Solaris agent; monitors some server health–related metrics; provides very flexible role-based access to the reporting and viewing console Cons: Management UIs were a bit cumbersome, and the response time wasn’t always good Rating: 3.5 stars Price: Starts at $9,000 for 20 Windows servers and 50 workstations. Contact vendor for more information. Recommendation: This product’s definable role-based authentication and Web console are attractive for Help desk use. If you need some of its unique features, I recommend that you install it for evaluation and see how it works for you. Contact: Prism Microsystems ? http://www.prismmicrosys.com ? 443-539-3766 |
RippleTech LogCaster
RippleTech’s LogCaster monitors, reports on, and alerts to activity in Windows event logs, device syslog output, and text-file-based event logs. It stores logged events, which are configurable, in a SQL Server database and makes use of SQL Server 2005 Reporting Services (SSRS) to create and save reports in a variety of formats, including PDF, HTML, or CSV file format. LogCaster’s monitoring extends beyond event log–style data to include an ability to monitor Windows performance counters, to run Windows services, and to run network-based IP services such as mail and Web servers throughout your network. In addition to Windows event log data, LogCaster will monitor and report on syslog data from Linux/UNIX systems and network devices, and from IBM mainframe Resource Access Control Facility (RACF) data.
Architecture
LogCaster installs on Windows 2003, XP, and Win2K systems and requires a SQL Server 2005 or SQL Server 2000 system. It also supports MSDE, and SQL Server 2005 is the preferred database platform, due to its associated SSRS features.
The LogCaster service running on the LogCaster server communicates with agents to collect Windows event logs, manages the database, receives syslog data, and monitors performance counters and IP-based system health monitors. The LogCaster agent on monitored Windows systems receives event log filters from the server that have been configured for the system, communicates with the event log service on the monitored system, processes and filters event log entries, and forwards selected events to the LogCaster server. The agent also monitors any text files configured for Text File Watcher, and manages native event log file backups. The LogCaster console GUI, which you may install on workstations for remote access, is the tool you use to configure all aspects of LogCaster and to view events and generate reports.
On monitored Windows systems, the agent continually monitors the system for new events. New events are evaluated against event rules; when there is no match, no further processing occurs. When matches occur, the agent writes the event to a data cache on the local system (which it never allows to exceed 20MB in size) and sends it to the LogCaster server. The server writes the event to the SQL Server database and performs any notification processing that has been configured for the event.
Hands On
I tested LogCaster 5.5 and installed it during a scheduled Web conferencing session with a RippleTech technician, a service RippleTech offers to all customers. Before the call, I had prepared two Windows Server 2003 SP1 systems, one of which was configured with IIS, SQL Server 2005, and SSRS. We started by installing LogCaster on its server, followed by installing Log Caster Reporting and Risk Assessment reporting modules on the SQL Server.
Administrators use the LogCaster console GUI to configure all aspects of LogCaster’s data collection, to remotely install the LogCaster Agent to Windows systems, and to display priority events. The GUI has three main areas of activity: Setup, Configuration, and Dashboards.
I started by using Setup to deploy the LogCaster agent to several system-created folders (called Business Groups within LogCaster) that are used to organize and group monitored systems. LogCaster displayed discovered domains and systems, allowing me to drag them to the desired folder, which initiates remote installation of the agent. Administrators also use Setup to create and configure user IDs for console access and to manage scripts they might want to execute on monitored systems in response to certain events.
Configuration screens are used to configure the "watchers": Event, Service, Performance, TCP/IP, Text file, Syslog, and Plugin. As an example, within Event Watcher Configuration you configure Event Watcher rules to designate how the LogCaster agent running on a monitored system will respond to specific events: forward it to the LogCaster server or not, run a script, require that the event be acknowledged by a console operator, and configure notification via email or dial-up paging, display on a LogCaster console at an assigned priority level, and/or send an SNMP trap. Event Watcher rules are evaluated in priority order and evaluation stops at the first rule the event matches. Rules assigned to the
Syslog monitoring is supported in two ways. First, you can write all syslog information from a source to a text file. You can also configure LogCaster to write syslog events to a Windows event log on the LogCaster server, where they can be processed by rules as any other Windows event. This structure occurs to me as less than ideal. I would prefer direct processing of event log data without the extra write to a Windows event log.
Dashboards display current information forwarded from the watchers. A dashboard displays events in the order received. You can choose which columns to display and sort the display at the column heading. Doing so makes it easy to locate events of interest and display the full event information.
LogCaster uses SSRS and its Web-based interface for reporting. RippleTech provides a large set of customizable reports, as Figure 5 indicates. The Executive Dashboard is a particularly interesting report. It analyzes the information collected from all monitored systems and displays its assessment of system log policies that affect the integrity of Windows event log data. The Log Management chart displays a red segment for Windows managed systems and a green segment for LogCaster-managed systems, in which LogCaster backs up and consolidates event logs. The Log Collection report displays red to represent managed systems with agents that are not reporting to the LogCaster server. The Security Risk Assessment report displays red for systems that allow events in Windows event logs to be overwritten, potentially compromising the completeness of event collection. Other charts portray security alerts and log backup and archive status. All charts are active: You can click on a segment to display the names of the systems the segment represents, then click on a system name to see the relevant system configuration settings. LogCaster has a scheduling option, but the facility is pretty generic—it wasn’t clear how to schedule reports, and I found no examples in either the user manual or in the Help information.
For reporting on the performance data you use LogCaster to collect, RippleTech provides an Excel-based reporting tool, the Performance Reporting and Analysis Suite. You modify a copy of the provided macro-driven Excel spreadsheet to create a performance data report.
Summary
For the most part, LogCaster was easy to use, and it certainly has a good set of facilities. The set of predefined reports is impressive, and because they are built around SSRS, they are relatively easy to modify. LogCaster supports many types of watches, monitoring much more than event logs. Rules are relatively easy to configure, although it seems to me that the priority-based system might be a little hard to troubleshoot, since nothing tells you which rule processed the event. Performance counter reporting isn’t integrated with event reporting and is accomplished with an Excel spreadsheet–based system. All said, LogCaster has a nice set of features, but the ease of use suffers somewhat due to LogCaster’s way of implementing them.
|
RippleTech LogCaster Pros: Monitors services, performance counters, and IP-based ports in addition to events; supports remote console installation; supports distributed critical event management with the ability to send events to different consoles based on any event attribute; well-developed SSRS-based reporting suite Cons: The ordered application of rules and lack of named rule sets can make administration and troubleshooting more complicated; LogCaster must write syslog output to a Windows event log if you want syslog events to be processed by rules and eligible for notification actions. Rating: 4.0 stars Price: Starts at $550 for five licenses Recommendation: Some aspects of the implementation seem to be needlessly complicated, which is balanced by a well-developed reporting suite. Contact: RippleTech ? http://www.rippletech.com ? sales@rippletech.com ? 610-862-4000 |
TNT Software ELM Log Manager 4.0
ELM Log Manager is part of TNT Software’s ELM product line. The other products include ELM Event Log Monitor, an agentless Windows event log collection and alerting application, and ELM Enterprise Manager, which adds a variety of application and IP port– monitoring options to Log Manager’s feature set. Log Manager collects user-selected events from Windows event logs and file-based logs. Log Manager also receives syslog output directed to it from other systems and devices, and receives SNMP traps. Events are written to a SQL Server database for archiving and reporting.
Architecture
The Log Manager Server receives events from monitored systems and supports three styles of monitoring. Windows systems have the option to run a Service Agent, which provides the greatest functional level. Virtual Agents monitor Windows-based systems without installing agent software on the system through the use of RPC connections to the monitored system. IP Virtual Agents monitor non-Windows systems for syslog output and SNMP traps. Monitor Items define what Log Manager will look for in the stream of events generated on monitored systems. Log Manager will send Monitor Items to systems running Service Agents. The agent will evaluate events against the criteria set in the Monitor Item, sending only selected events back to the Log Manager Server, and, when configured to do so, executing a program or script on the monitored system.
Log Manager Server uses three SQL Server databases. The Primary database, often on a dedicated SQL Server system, is the repository for event information. The Failover database, typically on the Log Manager Server, queues event information should the Primary database be temporarily unavailable. To keep the Primary database to a manageable size, Log Manager allows you to configure periodic movement of older events to an Archive database.
Administrators use the Log Manager Console, a Microsoft Management Console (MMC) GUI installable on other workstations, for remote management. To manage Log Manager's monitoring activities, administrators create Agent Categories, assign monitored systems to one or more Agent Categories, and create and assign Monitor Items to the categories. Because a monitored system can belong to several Agent Categories, administrators can create Agent Categories for each application or server function and assign Monitor Items to the Agent Category appropriate to the application. If a Monitor Item doesn’t apply to a system assigned to the category, the agent will ignore it with no extra processing. The ability to create a category with rules to collect all events from one or more event logs can help ensure the completeness of your event collection.
Log Manager supports five types of Monitor Items:
Server Monitors allow the assigned agents to monitor the ELM Server’s status and attempt to restart the ELM Server service if the server’s Windows registry indicates that it did not shut down normally.
Agent Monitors monitor the health of the agent running on monitored systems and might attempt to restart the service or perform notification when they detect failure or poor performance.
Event Collector Monitor Items evaluate all events occurring on assigned systems and deliver matching events to the Log Manager Server, where they are stored in the database.
Event Alarm Monitor Items watch for specific events or the lack of a specific event within a certain time period and trigger an action or notification in addition to writing the event to the database. Possible alarm actions are posting the event as an alert on consoles, issuing a Net Send message, creating a new application event log entry, and executing a program or script.
File Monitor Items monitor text files for word and strings, using bookmarks to avoid re-reading portions of the file previously processed.
Although you can enable a few kinds of notification actions when you create an Event Alarm Monitor item, an extensive set of notification alternatives is available to administrators through the Notification facility. Log Manager supports fifteen distinct notification methods, including marquee display, text-to-speech (using the Microsoft Voice engine), and posting a Web page. One of the options lets you post events to Log Manager Advisor consoles (specific consoles or all consoles), which are installable system tray–resident clients that notify the workstation user when new events post. Administrators define notification Rules, which make use of event Filters to describe which events the notification rule will apply to and also define named notification methods to define where notifications are sent. (Yes, TNT uses the same term to describe both the 15 kinds of notification you can employ and the named notification methods that you create to make use of TNT's supported notification methods).
Hands On
I installed Log Manager without incident on a Windows 2003 system with SQL Server 2005 Express Advanced Edition installed. Log Manager's basic requirements are .NET Framework 1.1 and IIS 5.0 (or later) with ASP.NET configured. I created a few new agent categories, deployed Service Agents to a couple of systems and Virtual Agents (for agentless monitoring) to two more. I created several types of Monitor Items and discovered that context menus are available when viewing alerts and events, Figure 6 shows. This made it easy to create an event filter to use elsewhere. Events Views, Personal Views (which are Events Views that show up only for your logon), and Notification Rules all make use of the same set of event filters. Notification Rules also turned out to be easy to configure.
Reporting is an area that TNT would do well to enhance in Log Manager, but because the data is in SQL Server, you can create your own reports using SSRS if you like. Selecting Reporting from the console quickly takes you to Log Manager's Web-based reporting interface, which lets you schedule and run predefined reports for the systems and date ranges you specify. There are only a few reports: I counted six security-related reports, plus an Alert Summary and an Event Summary. One of the reporting features is unique: When you first request a report, Log Manager asks you which systems you’d like to report on and creates the Event Collector Monitor Items needed to collect the necessary data.
I also configured the database pruning features. With pruning, I was able to specify retention periods for alerts and for events very flexibly by event filters.
The Web interface proved useful as well. It acts as a central repository for reports and also allows authorized people to search events and view alerts.
Summary
I’d like to see a few enhancements in Log Manager. When you click on a Category, it displays all the systems that are in the category but doesn’t show whether they use Service Agents or Virtual Agents. Sometimes it would be useful to have default event views for each category. For example, if I created a “SQL Server” category, it could be useful to see only the events captured by rules assigned to that category. You can create them in Event Views, but it seems like a natural default view. That you create alerting and notifications in two different areas seems a needless bit of complexity, and large installations may well end up creating a large number of event filters—a folder system to categorize and organize them would be better than having to scroll down a long alphabetized list, which is the current process.
I think most administrators will need to spend some time configuring Log Manager to their specific needs. The default collectors are pretty generic. Log Manager has some nice features, such as automating the collections configuration necessary for specific reports, and the large variety of notification methods. I liked the ability to configure multiple monitoring categories with assigned rule sets, and also the ability to assign systems to multiple categories. Overall, I found Log Manager's capabilities—aside from the reporting component—reasonably complete. Log Manager is one of the better products I tested.
|
TNT Software ELM Log Manager version 4.0 Pros: Flexible event collection and alert definition; more supported notification methods than any other product; local failover database provides fault tolerance if SQL Server is temporarily unavailable Cons: Few reports and no ability within ELM Log Manager to create new reports Rating: 4.0 stars Price: Starts at $325 for 1–399 servers, $215 for 400 plus servers Recommendation: ELM Log Manager was one of the better products I reviewed. Queuing events to the local failover database when the primary database is unavailable will help ensure the completeness of event collection, but you’ll need to spend some time customizing the configuration and creating additional reports. Contact: TNT Software ? http://www.tntsoftware.com ? 877-546-0878 |
My Bottom Line
As with any comparative review, I found that the six products I reviewed here all have their benefits and drawbacks, as well as feature sets that will draw some of you to each of them. In the end I was most impressed with GFI’s EventsManager 7.1, and I've designated it my Editor’s Choice.
