Starting with Windows Vista, the Windows event logs appear to be inundated with thousands of messages, some pure clutter, informing the user about every little detail an application does. Amongst these useless messages, an error may be easily missed even by a watchful eye. Even when the errors are noticed, in many cases they are rather cryptic, undocumented, and very often mislead about the actual source of the problem. In their effort to provide as much information as possible about how the application is performing, Microsoft and other leading developers have rendered the event logs almost useless. Gone are the XP days, when quite often, a single event clarified the issue.
In the same time, with the hardware becoming a commodity, more and more servers are thrown at the (already) overworked administrators, with the expectation to be monitored rigorously. Various monitoring solutions are available on the market, some quite complex, but many are trying to do too much or are reporting the wrong things. The cost of such solution may also become an issue even for smaller companies and add yet another burden to the administrators' shoulders.
With EvLog 3.0 we are trying to eliminate the clutter, allow the user to quickly look for troubleshooting information and provide a more graphical view of the events being recorded on a particular server.
Here are the main points about the philosophy behind EvLog:
1. In most cases, you only care about the events in the last 24 hours
2. The administrator should receive a daily report on what happened, event-wise, on each server.
3. It should be easy to look up troubleshooting information about a particular event
4. It should be easy to filter the type of events reported and ignore those deemed to be irrelevant
5. Anomalies should be detected and reported accordingly
6. Backup of event logs should be kept for future references, especially for security-related events such as logins and logouts.
So, how can EvLog assist with the issues mentioned above? Here it is how, point by point:
1. Time interval. By default, EvLog will create reports for the last 24 hours. You can set the time interval to whatever fits you, even 5 minutes and that can be used for a more "real-time" approach to reporting. In fact, the command-line version of the analyzer can be used exactly for that. See the Help file for more details about it.
2. Reports. With just a few clicks of the mouse, EvLog can be set to email a report at the desired time, with the events for the last 24 hours. For example, it can be set to run at 7:00 am so when the administrator gets to work, the reports are waiting in the Inbox for review.
3. Troubleshooting. Each event in the report provides a hyperlink to the www.eventid.net database of Windows events, with thousands of real-world comments from users. A small subscription provides even more information, such as an "English" translation of the event description and quick, customized searches through Google and other search engines.
4. Filtering. Select event type (we would ignore Information and Success Audit), keywords, certain event id/description combinations, and even let the EvLog Artificial Intelligence module, called Evvy, to decide what events to report. The last feature would require some training. Here is a screenshot from one of the Evvy training sessions:
5. Anomalies. With the Evvy AI enabled, EvLog can highlight events that never been recorded before and comment on those encountered before and required special attention. A future release will allow access to a Master Knowlege module that will merge the training of the Evvy AI on various locations. As it can be seen below, with the hourly distribution of events one can see at a glance that something happened around 12:00 pm. Given the large number of informational event, most likely a system restart.
6. Backups. Windows event logs in their native format are terrible backup material. The events themselves do not hold the event description template, they are slow to access and waste a lot of space. EvLog can be configured to create a text-based backup of the log and then clear the Windows log. This way the logs stay trim and the information is still available to be accessed with any text editor. Even more, the syslog client can send the reported logs to a central location where they can be processed with 3rd party solutions. Here are some syslog entries from the EvLog syslog client:
2015-01-18 13:11:13 System3.Warning 127.0.0.1 Jan 18 13:11:13 AGWIN7 1/18/2015 6:24 AM,1014,Warning,Microsoft-Windows-DNS-Client,System,Name resolution for the name 2015.ausopen.com timed out after none of the configured DNS servers responded.
2015-01-18 13:11:13 System3.Error 127.0.0.1 Jan 18 13:11:13 AGWIN7 1/17/2015 10:23 PM,36888,Error,Schannel,System,The following fatal alert was generated: 10. The internal error state is 10.
The text-based backups, being they EvLog backups or syslog logs are highly compressible and easy to store in a central location and kept according to the log retention policy.