Every time I see another one implementation of event logging I ask myself why not to use standard Windows EventLog. I've added enhanced support of EventLog to SvCom and here is the example how to use it.
Every time I see another one implementation of event logging I ask myself why not to use standard Windows EventLog. I've added enhanced support of EventLog to SvCom and here is the example how to use it.
http://aldyn-software.com/examples/014-EventLog/index.html
http://aldyn-software.com/examples/014-EventLog/index.html
The lack of a decent viewer for the Windows event log might be the reason. But I must admit that I haven't really looked very hard.
ReplyDeleteIMHO nothing beats a text file, with the proper viewing tool. KISS design. Huge performance. End-user friendly. Cross-platform.
ReplyDeleteCross-platform does make sense: today, I do not like to be tied to a Windows-only solution - unless there is a real bonus on the platform, e.g. for http.sys.
EventLog never convinced me. Performance was low before Vista - but even if now it has been reported to be faster (but still slower than text files), it is still a "black box"..
Where are events actually stored? (it depends on the OS version)
How much resources are used? (difficult to guess)
How to access the storage without a tool? (not possible: you need to have administrator rights to access the .evt file)
How do you customize your logging layout?
What is the timing resolution?
The fact that you have some part of the API to extract the events as log file just smells...
Even under .NET, where there is a built-in API, I would not use EventLog, since I would not like to be tied to Windows.
Just imagine that you are a sysadmin in a medium or large company. You have dozens applications and almost all of them write logs. What would you prefer, one common logs channel that allows to collect logs over network, filter, sort and analyze it in the same manner or you would wish to study inventions of every software developer who writes their logs into text files, db-tables, using their own rules and formats?
ReplyDeleteMy personal experience is that every time we supply our solutions for companies the support of Windows EventLog is a "must have" feature.
On the other hand, you are right, it not a cross-platform solution. And, of course, Win EventLog should not be considered as a debug or trace tool. It is an instrument to build company-scale KPI based health, performance and alerts monitoring system.
Alexey Dynnikov
ReplyDeleteYou are right: EventLogs are perfectly integrated in the Windows world...
But you can easily create some cross-platform administration and monitoring feature. This is what we are currently finishing in mORMot, using simple no configuration REST admin service, you can do remote monitoring, see timing (of every service method, of every prepared SQL statement, of every REST access, also per user account), subscribe to some log events, persist them on a DB, see or modify the settings, and even run SQL administration queries on the local DB, from a single administration (AJAX) app. It works with Windows and Linux servers.. main advantage in a "cloud" world...
And there are Open Source cross-platform solutions for SysAdmins, like Shinken or Nagios.
The main point is that EventLogs should not be seen as a debug or trace tool. It is worth logging the main events: start, stop, resource monitoring, error, exceptions...
Your post opened my eyes, and I will eventually use the Event API for a set of events. Thanks for pointing this out!
Event logs are for events (errors, status message that have long term relevance, etc.). For runtime tracing, I used to use the OutputDebugString() API function, but have switched over to using CodeSite, which is brilliant and has been amazingly useful troubleshooting and profiling in live environments.
ReplyDelete