I think there's an alternate universe out there where: - we collectively realized that logs, events, traces, metrics, and errors are actually all just logs - we agreed on a single format that encapsulated all that information in a structured manner - we built firehose/stream processing tooling to provide modern o11y creature comforts I can't tell if that universe is better than this one, or worse.
Tracing: Structured logging, but better
61–70 of 130 posts
Re: Tracing: Structured logging, but better
#62I think there's an alternate universe out there where: - we collectively realized that logs, events, traces, metrics, and errors are actually all just logs - we agreed on a single format that encapsulated all that information in a structured manner - we built firehose/stream processing tooling to provide modern o11y creature comforts I can't tell if that universe is better than this one, or worse.
Re: Tracing: Structured logging, but better
#63I think there's an alternate universe out there where: - we collectively realized that logs, events, traces, metrics, and errors are actually all just logs - we agreed on a single format that encapsulated all that information in a structured manner - we built firehose/stream processing tooling to provide modern o11y creature comforts I can't tell if that universe is better than this one, or worse.
Honestly it sounds like you're pitching opentelemetry/otlp but where you only trace and leave all the other bits for later inside your opentelemetry collector, which can turn traces into metrics or traces into logs.
Re: Tracing: Structured logging, but better
#64> The second problem with writing logs to stdout Who on Earth does that? Logs are almost always written to stderr... In part to prevent other problems author is talking about (eg. mixing with the output generated by the application). I don't understand why this has to be either or... If you store the trace output somewhere you get a log... (let's call it "un-annotated" log, since trace won't have the human-readable m…
Re: Tracing: Structured logging, but better
#65> If you’re writing log statements, you’re doing it wrong. I too use this bait statement. Then I follow it up with (the short version): 1) Rewrite your log statements so that they're machine readable 2) Prove they're machine-readable by having the down-stream services read them instead of the REST call you would have otherwise sent. 3) Switch out log4j for Kafka, which will handle the persistence & multiplexing for y…
> 3) Switch out log4j for Kafka, which will handle the persistence & multiplexing for you. I don't think this is a reasonable statement. There are already a few logging agents that support structured logging without dragging in heavyweight dependencies such as Kafka. Bringing up Kafka sounds like a case of a solution looking for a problem.
What are they? Because admittedly I've lost a little love for the operational side of Kafka, and I wish the client-side were a little "dumber", so I could match it better to my uses cases.
Re: Tracing: Structured logging, but better
#66> If you’re writing log statements, you’re doing it wrong. I too use this bait statement. Then I follow it up with (the short version): 1) Rewrite your log statements so that they're machine readable 2) Prove they're machine-readable by having the down-stream services read them instead of the REST call you would have otherwise sent. 3) Switch out log4j for Kafka, which will handle the persistence & multiplexing for y…
How to get me to leave your company 101
That said, I've had conflicts with a previous team-mate about this. He couldn't wrap his head around Kafka being a source of truth. But when I asked him whether he'd trust our Kafka or our Postgres if they disagreed, he conceded that he'd believe Kafka's side of things.
Re: Tracing: Structured logging, but better
#67Context: the last thing I wrote used Deno and Deno Deploy.
Re: Tracing: Structured logging, but better
#681. application logs, emitted multiple times per request and serve as breadcrumbs
2. request logs emitted once per request and include latencies, counters and metadata about the request and response
The application logs were useless to me except during development. However the request logs I could run aggregations on which made them far more useful for answering questions. What the author explains very well is that the problem with application logs is they aren't very human-readable which is where visualizing a request with tracing shines. If you don't have tracing, creating request logs will get you most of the way there, it's certainly better than application logs. https://speedrun.nobackspacecrew.com/blog/2023/09/08/logging...
Re: Tracing: Structured logging, but better
#69How would a hobbyist programmer get started with tracing for a simple web app? Where do the traces end up and how do I query it? Can tracing be used in a development environment? Context: the last thing I wrote used Deno and Deno Deploy.
opentelemetry has a service you can run that will collect the telemetry data and you can export it to something like prometheus which can store it and let you query it. Example here https://github.com/open-telemetry/opentelemetry-collector-co...
Typically in dev environments trace spans are just emitted to stdout just like logs. I sometimes turn that off too though because it gets noisy.
Re: Tracing: Structured logging, but better
#70And while my historical gripes are largely still the status quo: stack traces in multi-threaded, evented/async code that actually show real line numbers? Span-based tracing that makes concurrent introspection possible by default?
I’m in. I apologize for everything bad I ever said and don’t care whatever other annoying thing.
That’s the whole show. Unless it deletes my hard drive I don’t really care about anything else by comparison.