back
29 comments
I do everything to keep stuff out of the Windows event log because it's slow, impossible to query large swathes of data, noisy and difficult to get things to talk to it due to NT permissions and sources being stateful. Not only that you have to pay piles of cash for anything even slightly reliable for forwarding of logs (built in service for this is terrible) and the tooling is foul.

Now to the original problem, what about a MAC framework for NT (other than the heap of crap known as MIC). Lets just log shit that the MAC framework didn't allow then.

SELinux, trusted solaris, OSX Mach, FreeBSD POSIX MAC for example.

Nope stuck in the dark ages because of win32...

(Yes i know NT can do this on its own but NT is just the runtime environment for win32 these days rather than the technical achievement it was).

No only is the Windows Event Log impossible to query, it's also pretty rare to see a software actually log anything useful on Windows. I'm not trying to bash Microsoft, it just seems more common for software developed for Windows to have bad/missing/useless logging.

I think this might be a culture thing, because it's not actually impossible to do, it's just really rare to see. On Unix-like systems we're all use to be able to find text files with logging information for pretty much any system we deploy, on Windows we're accustomed to may programs and systems to be black boxes. If you as a Windows developer hasn't been exposed to having easily parsed text files with logging information, then changes are you don't know how to do good logging.

Also XML is pretty crappy for logging, either you have a million documents, or you have one large document that won't easily fit into Logstash, Splunk and similar tools.

> it's also pretty rare to see a software actually log anything useful on Windows.

Indeed there is a whole huge market doing that (logging and correlating useful information) APM (Application Performance Monitoring). You can take a look at: Compuware, Riverbed, and New Relic.

Currently this market is fragmenting in analytics products such as Splunk + agents distributed by different vendors.

How does New Relic make IIS log useful things?
New Relic and other monitoring tools can intercept .NET and look at issues there beyond the ones appearing on the event log. There is plenty of information about this on their sites.
LogParser[1] is not that bad for querying event log (and other types of log), even though I've never used to to be really quick querying the system. I was using it in the past on a scheduled basis to process event files and save relevant info in a SQL Server database.

Recently I found this agent: http://nxlog-ce.sourceforge.net/ but I haven't yet the occasion to try it. Probably a good approach would be using this kind of agent plus something like Logstash.

On the other hand sometimes it happened to me to find servers with event log corrupted, so log was lost (and it was not possible to log other info before doing a reset of the log). That's not nice..

[1] http://www.microsoft.com/en-us/download/details.aspx?id=2465...

Windows Event Log system is far from slow with the not so recent improvements since Windows Vista. Noisy? Perhaps you should complain about the specific application that is logging the events.

I didn't understand how the MAC framework relates to this discussion but in any case, check this: http://msdn.microsoft.com/en-us/library/bb625964.aspx

> Yes i know NT can do this on its own but NT is just the runtime environment for win32 these days rather than the technical achievement it was

Uh?

MAC because this sort of logging is the responsibility of MAC frsmeworks.

Integrity control is not MAC. It appeases a few problems but misses the point.

It is very slow. Two orders of magnitude slower than syslogng. When there is forwarding back pressure it just shits itself. It's awfully designed from end to end.

Last comment: NT has proper ACLs (object manager) but a lot of the power is lost via the win32 subsystem.

It's been awhile, but I know I was logging custom events to the Event Log over 10 years ago, and I'm pretty sure MMC (or whatever its successor might be called) allowed custom filters so that a person could select a particular slice of the log pie.
It does but have you tried it in an aggregated store from 30 machines? It took 46 minutes to extract a single named (last 8 digits of a guid) error ID as it has to scan the entire log.

Syslog on a Linux box and some front end indexing using a python script and sqlite: 0.04s.

I could probably have built that for windows but it wouldn't be 55 lines of code including the error query page Python CGI and taken me about 40 minutes end to end...

(And I'm naff at python)

Could you describe what you mean by "front end indexing" and how that is specified in your solution?

My guess is that you're comparing an Enhanced Apple with a Vanilla Orange.

Query by event ID. We report the event ID to clients so they can help us correlate a failure condition to the actual error and diagnostic dump.
The event log yes, is not great for querying, but the underlying ETW mechanism that actually does the logging is great and extremely fast, despite that post a few days ago that thought it was the worst API ever.
Yes also, unless previously changed, I always reached the limit of 10,000 records in normal computer usage.
The `<Data Name="key">value</data>` in there makes me sad. It's better than the `<field name="key" value="value"/>` one of our partners uses at work but still...

If there's a good reason for it, it's just as much of a good reason XML isn't suitable for what you're trying to do.

It's not a deal-breaker, but <key>value</key> would indeed be nicer.
For a human to read maybe, but for some generic parsing where there are many diferent keys, I would say <data Name="key">value</data> is indeed better, also makes an XSD easier to create, if needed.
That definitely goes towards the "good reason not to use XML" part of what I said, imo ;)
This is a limitation of the way ETW does structured logging, rather than a design decision in sysmon itself.
I can understand why they wouldn't have wanted to create an XSD covering all of the possible keys.
Free-form tag names invariably leads to conflicts with previously defined tags that are used for other purposes. I don't see how not wanting an unbounded number of different tags would be antithetical to use of XML.
Couldn't that be solved with xmlns?
definitely :)
I am confused. Is this in fact new or has there been a new release. Sysmon has been around for a while, no?
This is the first release of Sysmon. Perhaps you're thinking of Process Monitor?
I guess so. Strange sense of deja vu, but I will take your word for it.
Same here, they have a lot of tools called x-monitor, or xmon for short. I think we are subconsciously substituting the generic names like: file, process, disk.
before Process Monitor (procmon), those features where split between File Monitor and Registry Monitor (filemon and regmon). And they also have tcpmon for network connections, so maybe that why you think that it was already around before. I'll also add that I am a big fan of Russinovich and his tools (including of course Process Explorer, Autoruns and Pstools like psexec pslist pskill etc..) so if he releases something new, it should be interesting for sure!
I'm quite sure something else called Sysmon has been around for ages.

Your comment reminds me of when I tried to come up with an original and descriptive name for a little utility for logging SNMP traps. Everything that came to mind was taken, in some cases by several different projects...