4 ms·
I don't think time is a particularly strong keying methodology for distributed tracing. You want to be able to quickly select all spans that have a certain tra
by jrockway 6y ago
I don't think time is a particularly strong keying methodology for distributed tracing. You want to be able to quickly select all spans that have a certain trace ID. The time that the span was ingested is relatively unimportant to the querying mechanics, and you don't do any operations like "combine samples into a 1h average after 5d".
- jeffbee 6y agoWhen I was at Dropbox I did do this ... we only retained traces for a very short time, so I did daily aggregations of traces into summary data structures that could attribute service time to various span types at different depths of the request etc. Don't ignore the value of aggregating and summarizing trace data. Of course, a TSDB is also useless for this, I agree there.
- jrockway 6y agoYeah, using the trace data to get RPC latency and success/error charts is useful, but that's just another branch off the data-stream. Your metrics system needs to inspect every trace, so your database only needs the ability to send you a list. (Jaeger seems to have Kafka support so you can do this in real time. Haven't tried it.)