Playing nicely with others in the Seq ecosystem

You would realise by now that I'm quite a fan of Seq. It's hard not to be, when you can download a free single user license and get started with a trial, a POC, or designing your monitoring and infrastructure. The growth in open source apps for Seq over the years that I've played with it helps, too. Here is a reasonably inexpensive structured logging server with a fairly low bar to get started, with a growing community that believes in giving back by creating and open sourcing their own apps to extend Seq's capabilities.

I would class the current Seq app landscape as largely fitting into three main categories; this isn't an exhaustive list and of  course my own apps show up .. you can readily see more examples over at Nuget.

And then of course there are 'freak' apps like Seq.App.OpsGenieHeartbeat which don't really fit the above, because it's an app that is predominantly concerned with external interaction ... it does produce some logs, but it's mostly leveraging Seq's existence to implement an OpsGenie feature - it's not really receiving, processing, or reacting to anything.

There are other apps which could loosely fit into the above - for example, Seq.Client.WindowsLogins might arguably fit as an "input" app, and Seq.Client.Reporter could fit as a "processing" or "output" app - but they are external to Seq itself, and are simply implementations of Serilog (via Lurgle.Logging) and the Seq API so my impulse is not to categorise these in the same way.

Seq is quite free-form and "rules free" about how apps interact (or don't) and it affords a lot of flexibility in implementation. An input app may or may not be used (since you might be ingesting directly to Seq), you may or may not do some processing of the logs, and you can implement alerting in any number of ways, and modify that with signals and dashboard alert rules. It's actually quite ripe for a monitoring and alerting infrastructure that is based around applications. 

But what if the apps worked together more closely?

I'd run Seq for years in a POC single user implementation, but when I started seriously building out the monitoring and alerting infrastructure, I noted that I was accepting some inherent limitations. For example, Seq.App.Opsgenie did not allow for defining priority and responders, and I needed a new instance if I wanted to pass different tags. Seq.App.Atlassian.Jira didn't allow for defining priority and settings assignees, and again, needed different instances to pass different labels.

There's no criticism in that - they were limitations based on the current versions of those apps, and there was opportunity to enhance them, especially after I started creating my own apps to meet our needs. My first serious app, Event Timeout, had a feature - initially quite useless - to set a property containing tags with each timeout. There was nothing to consume them.

So I started to enhance Seq.App.OpsGenie, and indeed the first enhancement was to allow the OpsGenie app to read a property from log events to set tags dynamically - while still allowing a list of static tags that could be combined. Nick Blumhardt was really receptive and collaborative with this, and I followed up with adding my ideas to map Priority and Responder values to event properties (or setting static values if desired). 

Adding these features made a massive difference to my implementation. Suddenly, with some tweaks to Event Timeout, we were setting the appropriate priority for a given timeout and directing them to the right team - that's no small deal.

Recently, I worked with Ali Özgür to extend Seq.App.Atlassian.Jira, and again - really receptive and enthusiastic. It's a pleasure to encounter people from all over the world like this, who see the value in an idea and embrace it - so cool. With Ali's input, we added the ability to pass Priority and Assignee - essentially the same as OpsGenie's Responder - along with Tags. Cool, right?

But it then turned out that Ali also had an existing enhancement request to dynamically pass the Project Key from log properties, and it was only logical that this framework could fit that requirement too ... and then we also added time tracking (Initial/Estimated Time and Remaining Time) and Due Date to the same framework! 

While we were at it, we added the Handlebars functionality from Seq.App.OpsGenie to the Jira app, because that template feature just made sense (and with the latest release, I have some really well formatted Jira isues being created ... some info blanked out in the below screenshot).

So we now have alert/output apps that allow for input and processing apps to pass properties that will be used to direct alerts or issues to the right team or person, with the right priority, with meaningful tags or labels, and even with the right properties to allow creation (since some Jira projects require time tracking) and set due dates.

We also have enhancements coming to Seq itself to allow dashboard alerts to leverage these properties as well, and I've been busy extending my own input and processing apps to pass the properties and populate them in a meaningful way.

This stuff is awesome, and it's all powered by a core strength of Seq - structured logging. Simply making more and better properties available in the logs driving these apps makes it possible for the results to be so much more accurate and targeted, and we can even start using those extra properties for other purposes - what about a Seq Reporter report of all logs that were alerted to a given team? Easy!

I've recently worked on an extension to Seq.Input.MSSQL that would allow drawing all these properties from database views and queries, which (if or when merged) will make a great app even better for my purposes, and I hope for others too. Again, there's an existing enhancement request for the MSSQL Input to draw values from properties - in this case, event levels. Quite easy if you're already doing it for other properties.

I already make a lot of use of a forked version of the MSSQL app, that has a couple of bug fixes, to drive a bunch of alerts around critical SLAs ... simply put, it gives me the ability to turn database rows into meaningful logs that can be actioned. If the data doesn't quite fit that format, if it needs some transformative effort- a database view is quite viable and incredibly powerful. One of our biggest game changers was to turn the SQL Agent job logs into Seq logs that could tell us when a processing job failed, simply by creating a view that fit the bill.  Extending this further to fit the interoperability picture, dynamically directing alerts in the way they need to be handled, is absolute gravy on top of an already great app.

I look at this as a big opportunity for Seq to foster a collaborative platform of apps that interoperate well, and I hope to help push that bar even further. Obviously my focus is initially on "what I know" and "what we need", so Jira and OpsGenie and SQL come into the picture - but this picture doesn't have to be constrained there. Structured logging has an incredible level of power and capability, and Seq as a platform has an exciting future and direction - if it's supported by an app ecosystem with extensive interoperability, so much the better! 

I suppose this little interaction with Datalust really says it all 😊