Does anybody have an idea how efficient the windows event log is?
I have a scenario where many events could be logged every minute.
Is the windows event log well optimized to handle large number of events?
Would it be comparable to SQL Server for example in terms of performance.
And lastly is it possible to make the logs go to a database?
The windows event log is robust enough to handle many events per second, so depending on how many events you are talking about (100 compared to 100000) per minute and what exactly you need to do with the data would depend on if I would use event log or not. If I just need to use it for troubleshooting the event log is pretty good for that but if I need to analyze the data I always end up putting it in a database or pulling it out of the event log and parsing. There are some tools for this but it is an unneeded step if you can go directly to a database.
I am not sure on the exact specifications but for lighter record insertion the event log should consume less resources than running a local SQL server. In terms of performance I would say the SQL server would be a much better bet than event log. I believe the event log is also stored in memory.
Keep in mind that the event log is also limited in size. If you need to retain a lot of logs you are going to need to run automated scripts to export this and ensure you have the event log settings correct so you dont lose information. If the event log is at its maximum size, no logs will be retained until it is cleared.
Event logs can be logged to a database or syslog, but honestly I wouldn't recommend that.
I would recommend you weigh your options but if you are talking about heavy transactions consider a database.
A number of years ago (Windows 2000 Server was current) I was told by a Microsoft consultant that the event log system was good for a few events per second, but logging hundreds would be a bad idea (but it would probably cope). For high logging volumes Event Tracing for Windows (ETW) was a better choice (but hard to get actionable information on: either developer or administrator).
However in Vista/2008 the event system was completely re-worked (supports many more logs, doesn't map the whole of every log into kernel memory) so good practice might have changed.
Also ETW support is now in .NET and the event logging subsystem so the learning curve there is significantly lower.
If you are logging to an external host (like a database) consider how you will log errors connecting to that server (ie. a database cannot be the only route for logging).
You also need to consider the consumer of the events. If there is no effect way for someone checking the status or diagnosing a problem to extract the information they need then the whole logging effort loses its value.
Rather than make event logs go to a database, you can import them after the fact. If you need efficient querying of your data, this might be the way to go.
For querying and retrieving the event data based on criteria, it absolutely is not comparable to SQL, and it is not designed to be.
There are many applications available that will forward event data to a centralized server. One of those is Snare: http://www.intersectalliance.com/projects/SnareWindows/index.html
Windows 2008/7/Vista have an integrated capability to forward events to a centralized "collector", but this isn't actually a database. Following is an example of how to configure this:
Windows Event Collector
http://msdn.microsoft.com/en-us/library/bb427443%28v=vs.85%29.aspx
Windows Event Collector Setting up a Source Initiated Subscription.
http://msdn.microsoft.com/en-us/library/bb870973(v=vs.85).aspx
