Open MattMofDoom opened 2 years ago
MattMofDoom
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago @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
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago Updated to current dependencies.
https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.0.3
yooakim
commented
2 years ago 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
commented
2 years ago @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
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago Updated dependencies, no code changes - https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.0.6
MattMofDoom
commented
1 year ago Updated dev build at https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.2.1
MattMofDoom
commented
1 year ago Updated dev build (again!) at https://github.com/MattMofDoom/Seq.Client.EventLog/releases/tag/v3.2.2
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;
Appreciate this is a lot to parse, and a picture paints a thousand words, so below a sample of the resulting output:
Cheers,
Matt