Enhanced event log processing

[MattMofDoom]

Hi @c0shea,

This is quite a large PR, and is based on extensive work I did with Seq.Client.WindowsLogins which was originally forked from the Seq.Client.EventLog codebase.

One key thing that I found is that the EventLog.EntryWritten handler can be unreliable ... I covered quite a bit of this in my blog post https://mattmofdoom.com/eventlogentrywritten-is-bad-and-should-feel-bad-the-v112-update-for-seq-client-for-windows-logins/ ... I also note that you have issue #3 which seems to reflect the unreliability of EntryWritten, so it's likely this PR would close that issue.

After reworking the Seq.Client.WindowsLogin codebase to use EventLogWatcher.EventRecordWritten, I was able to show that the service was reliably and consistently sending logs to Seq without fail. Seq.Client.WindowsLogin also moved to using a consistent method of logging to Seq so that the service would send its own logs to Seq, in addition to the logs produced from the Windows event log.

The biggest enhancement brought by Seq.Client.WindowsLogin was that it explicitly pulled the EventRecord properties out of the event log and presented them a Seq structured logging properties. That means that I could readily examine the LogonType to detect genuine interactive logins, but it also put the whole property set up for grabs, to be used in any way I want - Seq signals, dashboards, alerts, etc. It's massively powerful.

In the background, I've also been working to foster some application interoperability in the Seq ecosystem, by introducing properties that can be passed into the event stream (like Priority, Responders, ProjectKey, etc) that can then be used by output apps to target alerts. Windows Logins for Seq was one of my own apps that received this treatment.

Circling back, though, I do use Seq.Client.EventLog for other purposes, and while Seq.Client.WindowsLogin moved a long way from the current release - I wanted both to feed enhancements back to your app, and to genuinely enhance what your app brings to the table.

Hence - this work effort, which was fed by some "musing out loud" on Twitter 😂

Enhancements;

• Dynamically parsing event XML data to structured properties - I feel like this is the really big one 😊
• Added a heartbeat function that allows detecting service down, and providing stats to Seq (think dashboards etc)
• Added "per-Windows event log" app interoperability properties - Priority, Responder, Tags, ProjectKey, Responders, InitialTimeEstimate, RemainingTimeEstimate, DueDate
• Add per-log message templating to allow maximum configurability - any exposed property can be part of the template
• Enhance ProcessRetroactiveEntries to allow saving the current bookmark between service stop/start
• Add option for StoreLastEntry which can be used to save current bookmark between service stop/start, when ProcessRetroactiveEntries is not desirable
• Allow optionally disabling file logging
• Migrated from packages.config to PackageReference
• Updated to .NET SDK type project
• Update dependencies
• Consolidate logging to Lurgle.Logging for a consistent Serilog-based approach to both service logging and processing Event Logs

Appreciate this is a lot to parse, and a picture paints a thousand words, so below a sample of the resulting output:

Cheers,

Matt

[MattMofDoom]

Hey @c0shea,

I've put up my build of this enhanced version at https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.0.0 ... I did some tests against prod with it and it went amazingly well! I may yet do a blog post on this while waiting on your review/merge of the PR, I'm really excited by the results! 😁

Ping @nblumhardt in case you're interested!

Cheers,

Matt

[MattMofDoom]

I've now included Seq.Client.WindowsLogins functionality as an optional mode that can co-exist with other log monitors, including Security logs.

I was also reminded in testing that "-" and "." are not valid event properties, and so parsed event log data will now separate node names and properties as node_property, which means that parsed event properties can be used in message templates.

[c0shea]

@MattMofDoom Thanks for taking the time to submit this PR. 😄 Seems like there's some good stuff in it based on your summary. Unfortunately I haven't had the time lately to spend on open source projects, so I'm not sure when I'll get a chance to review and merge this.

[MattMofDoom]

Thanks @c0shea 😊

If it helps, I've made dev builds available with the latest at https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.0.1

It looks pretty amazing when you hook it up to Seq and start sending logs with structured properties from the event XML!

Cheers,

matt

[MattMofDoom]

I've added a new dev build at https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.0.2

A couple of bug fixes arising from running this in production, and also enhancement to periodically save the latest bookmark on heartbeat.

[MattMofDoom]

Updated to current dependencies.

https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.0.3

[yooakim]

Thanks for fixing this @MattMofDoom, we had some issues with the original and I really appreciate that you did this PR. :-)

Maybe it would be worth in the readme of master branch to note this PR even if it hasn't been ioncluded yet...? It can save some trouble for others. @c0shea

[MattMofDoom]

@yooakim Most welcome! I really wanted to give something back, this is a great contribution and I saw opportunities to make it even cooler ... Thank you for the feedback!

[MattMofDoom]

There is an edge case that I just found where it is still possible for the listener to stop getting new log entries. The changes from this PR make this easy to detect and handle, by stopping and starting the listeners.

A new config item was added for the purpose to allow this to be handled in a way that suits everyone's environment.

Release is at https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.0.4

[MattMofDoom]

Added a bug fix for the idle event listener detection.

The behaviour of Seq.Client.EventLog when idle event listener was detected has been observed to operate exactly as intended (stops and starts the listener automatically), but it wasn't correctly counting all events and therefore was triggering unnecessarily.

This has now been tested in a production setting.

Release is att https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.0.5

[MattMofDoom]

Updated dependencies, no code changes - https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.0.6

[MattMofDoom]

Updated dev build at https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.2.1

[MattMofDoom]

Updated dev build (again!) at https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.2.2