Live data from Hacker News

Tracing: Structured logging, but better

andydote.co.uk

1–10 of 130 posts

Re: Tracing: Structured logging, but better

#2
What's most incredible to me is how close tracing feels in spirit to me to event-sourcing.

Here's this log of every frame of compute going on, plus data or metadata about the frame.... but afaik we have yet to start using the same stream of computation for business processes as we do for it's excellent observability.

Re: Tracing: Structured logging, but better

#3
I really enjoyed the content- it's a great article.

Note to author: all but the last code block have a very odd mixture of rather large font sizes (at least on mobile) which vary line to line that make them pretty difficult to read.

Also the link to "Observability Driven Development." was a blank slide deck AFAICT

Re: Tracing: Structured logging, but better

#4
There are logging libraries that include syntactically scoped timers, such as mulog (https://github.com/BrunoBonacci/mulog). While a great library, we preferred timbre (https://github.com/taoensso/timbre) and rolled our own logging timer macro that interoperates with it. More convenient to have such niceties in a Lisp of course. Since we also have OpenTelemetry available, it would also be easy to wrap traces around code form boundaries as well. Thanks OP for the idea!

Re: Tracing: Structured logging, but better

#6
This is a great article because everyone should understand the similarity between logging and tracing. One thing worth pondering though is the differences in cost. If I am not planning to centrally collect and index informational logs, free-form text logging is extremely cheap. Even a complex log line with formatted strings and numbers can be emitted in Off-the-shelf tracing libraries on the other hand are pretty expensive. You have one additional mandatory read of the system clock, to establish the span duration, plus you are still paying for a clock read on every span event, if you use span events. Every span has a PRNG call, too. Distributed tracing is worthless if you don't send the spans somewhere, so you have to budget for encoding your span into json, msgpack, protobuf, or whatever. It's a completely different ball game in terms of efficiency.

Re: Tracing: Structured logging, but better

#8
Tracing is much more actionnable but barely usable without a platform. Which makes local programming dependent on third party. Also it requires passing context or have a way to get back the context in every function that requires it, which can be daunting.

On my side I have opted to mixed structured/text, a generic message that can be easily understood while glancing over logs, and a data object attached for more details.

Re: Tracing: Structured logging, but better

#9
post #8

Tracing is much more actionnable but barely usable without a platform. Which makes local programming dependent on third party. Also it requires passing context or have a way to get back the context in every function that requires it, which can be daunting. On my side I have opted to mixed structured/text, a generic message that can be easily understood while glancing over logs, and a data object attached for more det…

You can add Jaeger to your local dev containers and run it in memory, it's really lightweight and easy to use.

Re: Tracing: Structured logging, but better

#10
post #5

Logging is essential for security. I think tracing is wonderful and so are metrics. I see these as more of a triad for observability.

Indeed, the three legs (metrics, logs, traces) of OpenTelemetry's telescope. https://opentelemetry.io

Something missing from OTel IMO is a standard way of linking all three together. It seems like an exercise left to the reader, but I feel like there should be standard metadata for showing a relationship between traces, metrics, and logs. Right now each of these functions is on an island (same with the tooling and storage of the data, but that's another rant).
Post reply on HN