3 ms·
Does this naive approach work for anyone to allow a log to be read like a trace: 1. At the start of a request, generate a globally unique traceId 2. Pass this
by koliber 3y ago
Does this naive approach work for anyone to allow a log to be read like a trace:
1. At the start of a request, generate a globally unique traceId
2. Pass this traceId through the whole call stack.
3. Whenever logging, log the traceId as a parameter
Now you have a log with many of the plusses of a trace. The only additional cost to the log is the storage of the traceId on every message.
If you want to read a trace, search through your logs for "traceId: xyz123". If you use plain text storage you can grep. If you use some indexed storage, search for the key-value pair.
This way, you can retrieve something that looks like a trace from a log.
This does not solve all the issues named in the article. However, it is a decent tradeoff that I've used successfully in the past. Call it "poor man's tracing".
- pondidum 3y agoYes, but going to this effort, why not move to tracing instead? A migration path I could see might be: - replace current logging lib with otel logging (sending to same output) - setup tracing - replace logging with tracing over time (I prefer moving the most painful areas of code first)
- koliber 3y agoOne benefit is that you only need to send one string value (traceId) through the whole call stack, instead of passing around a trace object that gets built up. It seems lighter and simpler to add to an existing codebase.