Seq.App.EventTimeout v1.4.5 Released

I've released a new update to Event Timeout for Seq, which improves the handling of 24 hour windows (eg. Start 00:00, End 00:00) and how repeat timeouts operate.

Ordinarily, Event Timeout is forward looking - it always calculates the next start time if the configured start time would fall in the past. That means that when you configure your event timeout at 2pm on Monday with a start time of 1pm, Event Timeout will determine that the next "showtime" (the interval between the start and end times where events are monitored) will be 1pm on Tuesday. 

For a timeout that is 24 hour, we need to handle this a little differently. We should always enter "showtime" even though the start time is in the past, because that is the expected behaviour - a showtime that is always active.

This is most likely to be used  with a repeating timeout, and in fact is the reason for this update. I have a requirement to monitor for a "heartbeat" - a repeating log event - and alert if the event is logged. This is the perfect use case for the "Enable Repeat Timeout" setting - if we set Start time and End time to 00:00, and enable repeating timeouts, we can detect any time the heartbeat stops and cause an OpsGenie alert to be raised.

The config for this type of scenario is shown below. You can see that I have a couple of properties that I'm matching - the @Message property must contain "heartbeat" (it's case insensitive), and the MachineName property must contain "myserver". 

Property 1 is a "special" property which defaults to @Message if a name is not specified, so "Property 1 name" is left blank in this instance.

 

A repeating timeout

I noticed that this wasn't quite working how I expected, due to a logic change at some point, so I have corrected that case. For a 24 hour window, we can now enter showtime immediately as expected.

I also noticed that the repeating interval code had been set to use the existing "suppression interval" to limit when it logs a match. That proved limiting - I wanted to stop alerts being raised for 15 minutes, but the heartbeat was occurring 10 minutes, and I always wanted to see when a positive match was made against a log event.

I've therefore added a "Repeat timeout suppression" configuration, which allows you to configure how long positive matches are suppressed. This is separate from "suppression interval" which controls how often error logs can be output.

The below screenshot has had some details blanked out, but allow you to see the net effect - positive matches against my 10 minute heartbeat are logged, which is useful for diagnostic and monitoring purposes.

Heartbeat repeating timeout with positive match

I've also added a minimum value to each of the intervals:

  • Timeout interval has a minimum of 1 second
  • Suppression interval has a minimum of 0 seconds
  • Repeat timeout suppression interval has a minimum of 0 seconds

And finally, I've set up a number of unit tests in the project which in particular makes it easier to ensure that time calculations are behaving as expected. I've tied that in to a fancy CI/CD setup using Appveyor, so that testing and deployment of new releases to Nuget is automated!

As usual, you can install Event Timeout for Seq using Seq.App.EventTimeout as the package id in Seq's "Install from Nuget" page. 

You can update existing instances by going to Event Timeout's Manage button in the Seq Apps screen, and clicking Update.

 

Comments

You may also like:

Event Timeout for Seq v1.4.2 released

A new release of Seq.App.EventTimeout is out. This was a little earlier than I planned to release v1.4.x, but there was a bug in the AbstractAPI deserialization as a result of some code refactoring which I'd missed. As usual, you can install Event Timeout for Seq using Seq.App.EventTimeout as the...

Lurgle.Alerting v1.1.10 and Lurgle.Logging v1.1.15 Released

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...

Lurgle.Alerting v1.2.0 released - Consistent attachment content types!

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...