TL;DR: Seq 2023.2 is out! It adds a native ingestion endpoint for OpenTelemetry Logs, which makes it easier getting structured logs into Seq from a wider range of sources.
Last year was all about building foundations; this year is all about shipping features at a faster cadence. We've just dropped binaries for Seq 2023.2 to datalust.co/download and to Docker Hub in datalust/seq
.
In this release:
- Log ingestion via the OpenTelemetry protocol #1679, including the new
@Resource
namespace,@TraceId
, and@SpanId
built-ins - Inlay hints for irregular event property names #1855
- Allow read-only users to change their own preferences and passwords #1817
More bug fixes and improvements are listed in the release milestone.
Ingestion with OpenTelemetry
The majority of changes in this release support the addition of a new ingestion endpoint for the OpenTelemetry procotol (OTLP). Because there are quite a few moving parts involved, we'll follow up shortly with another post showing how to get data into Seq from various OTLP sources.
If you're eager and want to jump in right now, the Ingestion with OpenTelemetry and Ingestion from the .NET OpenTelemetry SDK documentation pages have everything you need to get going.
Why we care about OpenTelemetry Logs
OpenTelemetry is a set of libraries, tools, and protocols built around a common model for diagnostic data including structured application logs. The great thing about OpenTelemetry, for us, is that many more logging libraries, applications, and systems will now have native-quality integration with Seq via OTLP.
OpenTelemetry splits diagnostic data into logs, metrics, and traces. Seq 2023.2 supports only the logs specification, but through first-class handling of important correlation identifiers in @TraceId
, @SpanId
, and the @Resource
namespace, we're setting Seq up to work nicely alongside dedicated metrics or tracing systems if you use one.
Of course, because Seq has strongly-typed, fully-structured event properties, built-in aggregations like min()
, max()
, count()
, and percentile()
, and flexible features for correlating events across any dimension, you might find structured logs with Seq are all you need for many, many scenarios.
Should you switch your applications to use Seq's OTLP endpoint?
Right now, if you're happy with the logging libraries and tools you already use to send data to Seq, there isn't any significant benefit from switching over to OTLP.
In the future, as Seq's support for OTLP matures and the protocol evolves, we intend that OTLP will be on an equal footing to the HTTP/JSON ingestion endpoint used by Seq to date.
Feedback, suggestions, bug reports
We'd love to hear your questions, feedback, and suggestions for improving the new features in Seq 2023.2. You can reach us here, via support@datalust.co
, and via the Seq discussion forum. Enjoy! 👋