Reporting all the things Seq Reporter is the command-line client that can be used to schedule reporting from your Seq structured logs. It drives a number of daily and monthly reports for us and overall, it works well. We just set our query config and time range, schedule it, and...
Grr ... Bugses. We hates them precious. There's nothing worse than code that doesn't quite work as intended. Well, that's not quite true. If you have 3 products with common code that doesn't work as intended, that's probably worse. Anyway, I noticed that Event Schedule fired prematurely on the last...
After the last update to Seq.Client.WindowsLogins, in which I cursed the very existence of EventLog().EntryWritten, the Seq Client for Windows Logins has proven to be extremely reliable, and we've been really happy with it. It does exactly what it's supposed to do - it logs events to Seq when an...
Update After the original post, I tackled another item I'd been meaning to look at - being able to configure proxy settings for the Serilog Seq sink. Lurgle.Logging v1.2.3 now includes additional optional configurations for the Seq sink's proxy. This is particularly useful for console apps like Seq Reporter, to...
Uhh ... You want what? So, you have all your apps logging to Seq, perhaps you have monitoring and alerting using apps like the Seq OpsGenie client, and maybe you're even using Event Timeout to detect events that didn't happen in time. Things are going great, except ... Well, management...
Lurgle Update Time! I've released an update to Lurgle.Alerting, the premier Lurgle Alerting library for Lurgling your Alerts! This release is about updating some of the older code that was brought into the library: FluentEmail largely suppresses exceptions when there are send failures. Lurgle was simply returning the FluentEmail.Core.Models.SendResponse.Successful bool...
I've released a small update to Lurgle.Alerting which adds automatic determination of the attachment content type using the MimeMapping library. I've raised the version to v1.2.0 to align with Lurgle.Logging's current releases. This specifically addresses an issue when sending attachments with MailKit as the SMTP sender. The FluentEmail implementation was...
Lurgle approach compared to Serilog Following on from the v1.2.0 multi-threaded correlation release, I thought about whether we could further improve how we interface with Lurgle.Logging. The general approach was to maintain a static interface to logging that would allow us to capture key properties for logging, that would provide nicely...
Multi-threaded correlation ids were not a thing Following on from my work on Seq.Client.WindowsLogins and the subsequent realisation that EventLog's EntryWritten event handler is bad and should feel bad, I contemplated whether I could apply some of my efforts to solve another issue that had been bugging me. Lurgle.Logging was...
The Journey Begins ... This was a journey that began with an existing, and really useful, Seq application. I've had some mileage in the past from the Seq.Client.EventLog service. I've used it to monitor the Windows Application event log for new logs from a specific source, send them to Seq,...
I've just pushed out an update to Lurgle.Alerting on Nuget. This release adds a Handlebars template option, based on the implementation by Matthew Turner at FluentEmail.Handlebars (github.com). When I came across the FluentEmail.Handlebars package, I was keen to use it, but it was only compiled against .NET Standard 2.1, and...
I've pushed out updates to Lurgle.Logging and Lurgle.Alerting today. The Lurgle.Logging update is minor - I noticed that Log.Add wasn't correctly passing the calling method, source file, and line number. Lurgle.Alerting has received a more substantial update: This helps to make Lurgle.Alerting even more useful and reliable! You can get...