Updating Seq.Client.EventLog for dynamic properties and more!

I have had a fair bit of mileage from Seq.Client.EventLog. It's a great little service that was quite reliable for the simple usages that I initially had. When it came to monitoring for user logins, my first port of call was here - I wound up needing to fork the code into what became Seq.Client.WindowsLogins, which in turn exposed some shortcomings in the way that EventLog.EntryWritten works (we hates it). The net effect was that I wound up with an extremely robust service that consistently and reliably detected new interactive logins, although I wound up decoupling the Seq Client for Windows Logins from a fork of the EventLog client, simply because it had diverged so far.

I don't like taking without giving back if I can possibly help it though, and there were some interesting technical questions in my head. Exposing all the properties of a login event led me to contemplating whether I could realistically and dynamically expose the properties of any Windows event.

One weekend, some musing out loud on Twitter became the basis for a code bash ... first post below, but it was quite a lengthy thread as I expressed my ideas out loud while coding😊

Seq.Client.WindowsLogins has diverged a really long way from Seq.Client.EventLog. I've changed it from a fork to its own repository, while still acknowledging its DNA heritage. https://t.co/mmuRgbF2Gr

— MattM (of Doom) (@MattMOfDoom) October 8, 2021

And what eventuated was a fresh fork of Seq.Client.EventLog that took all the existing functionality, updated the code with the reliable EventLogWatcher.EventRecordWritten,  and ported core functionality from Seq.Client.WindowsLogin. Then I innovated by using the Seq.Client.EventLog design to add new features.

Here's a summary from the pull request to merge this to the original codebase:

• Dynamically parsing event XML data to structured properties
• Added a heartbeat function that allows detecting service down, and providing stats to Seq (dashboards and alerrting)
• 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

And here's the sample screenshot that I provided:

What you're looking at above is an extremely well structured event that is dynamically built from the Windows event log properties, along with the native properties applied by Lurgle.Logging such as MethodName, LineNumber, etc. The entire message is templatable, and you can configure multiple listeners (even against the same log).

For a final flourish - I explicitly added the Seq.Client.WindowsLogins functionality into Seq.Client.EventLog, so that one service can really fit all! I will probably retire the Seq Client for Windows Logins once this pull request is merged into the parent codebase

This is really powerful, and services like this start lifting Seq into more SIEM-like functionality. I think it's really exciting, and an excellent way to expose more applications and functions to a powerful application logging server.

While this PR is pending merge, I have made dev builds available, with the latest linked below. The original is, of course, still available for download from Connor O'Shea's repo!

Seq.Client.EventLog (Dev build)