Why Seq?

Not that long ago, even releasing software was stressful. Great tools to automate builds, testing and deployment have largely fixed that: if a project is set up carefully, “pressing the button” on a new release can even be fun.

Tools for application monitoring and diagnostics – very sophisticated ones – have been around for a long time. Why is it that when the heat is on, most of us still end up buried in Notepad.exe and Remote Desktop? Can we do the same for production debugging as TeamCity and Octopus Deploy have done for the release process?

Asking these questions set me on the road to building Seq.

Quality instrumentation can't be bolted on

The first realization I came to is that, just like good unit tests, good instrumentation needs to be baked into apps from “day 1” of a project. To be successful, the feedback loop that shapes and improves the instrumentation needs to start then, too.

Peppering code with logging statements, and switching on a log collector in production or close to it, doesn’t deliver quality results.

For apps to be easily managed, we need to see and get value from instrumentation before the code even leaves our workstations. The software to enable this has to be installed and usable on a development machine in minutes – taking hours or days to install, configure and learn a monitoring tool isn’t practical for most of us.

From this angle, it's easy to see why operationally-focused tools haven't found their way into our toolbox, and why when they're provided towards the end of a development cycle the results are mixed.

Seq was designed to be part of the dev experience, making excellent production instrumentation a by-product of better visibility during development and testing.

Better logs lead to simpler tools

The second thing holding us back from better monitoring and diagnostics is a mismatch between our “standard” logging tools and the complexity of today’s apps.

The goal of logging was once to record a timeline of events that could effectively be read from beginning to end. Now, with practically all non-trivial software being distributed between multiple machines interacting asynchronously, the focus of logging needs to be connecting events into many interlocking timelines.

SLAB was the project that opened my eyes to the potential of structured logging to deliver not just incremental improvements on older tools like log4net, but to truly revolutionize the meaning and utility of log events. In search of a smoother migration path from existing infrastructure, and a “feel” closer to traditional text logging tools, I built Serilog, which is on its way to becoming the logger of choice for new .NET projects.

Most loggers can output simple information like thread IDs into log messages, and log parsers can pull that information out again, but this limited ability to slice-and-dice logs is an awkward workaround – an afterthought that adds complexity and effort to deal with a fundamentally unfit model.

Existing tools put a lot of effort into dealing with this poor-quality data. Regex-splitting events to create a chart on a dashboard is nice on occasion, but when push comes to shove, complex log parsing is so painfully slow and error-prone that searching log files in Notepad.exe is often a more direct path to a solution, and that’s why in practise it remains surprisingly popular.

For tooling to deliver at crunch time, events need to be in a usable form and “ready to go” immediately when problems arise; when debugging I want to focus on the problem I’m trying to solve, rather than the intricacies of extracting useful information from masses of unstructured text.

Armed with better instrumentation, it became obvious that we could aim for much clearer, cleaner, simpler tools for consuming it.

Seq has a simple interface built on smart concepts, so you can be productive with it in minutes.

For instance, note the highlighted parts of the text messages shown in the screenshot above. Those aren't the result of log parsing: because Seq is built on structured data, it can show you automatically the tokens within log messages that can be extracted and used in queries.

Why else?

When we started building Seq, it was to put the fun into .NET application monitoring and diagnostics. I think we’ve delivered that in spades.... but we're also just getting started!

Many hundreds of .NET developers are already using Seq and every day helping us learn a little more about just what the possibilities are. We hope you'll love Seq too, and share your ideas and feedback with us.