Difference between Event Logging and Tracing in Observability

I have been noticing that a lot of folks are often confused between event logging and tracing. In terms of building out a generic SD for devs to report on observability data, should Event APIs be distinct from Trace APIs? Is an Event just a single Trace Span ?

If you look at Honeycomb’s implementation, an Event seems to be equivalent to a single span trace. The middleware wrapper creates a Honeycomb event in the request context as a span in the overall trace. A trace span is an event, but an event isn’t necessarily a trace span because an event might not have an associated trace ID which would allow you to link it to other spans/events.

The main thing is the connectivity between events that marks them as part of a larger workflow which affects things like sampling logic pretty heavily. Something like Events could be sampled almost randomly, but taking that approach with Trace Spans would be pretty detrimental to their usefulness. There are other parts of a span that don’t necessarily present themselves in events. i.e. a deployment event doesn’t need a duration, but every span does. Spans also commonly contain logs as annotations of events so you end up with an inception-like situation if you’re too exclusive in your definitions. A tracing span is a very specifically shaped event.

Having lived in the world of “events” for quite some time, the way I would explain it to folks is, an asynchronous event, has a source, but a trace will have both a source and a destination (or sink for the network folks). That conveniently allows us to accomodate both in graph theory(Source and Sink are nodes, and a trace is an edge).

Looking for an end-to-end incident alerting, on-call scheduling and response orchestration platform?

Sign up for a 14-day free trial of Zenduty. No CC required. Implement modern incident response and SRE best practices within your production operations and provide industry-leading SLAs to your customers