Author of the post here. Thanks for reading the post and your detailed questions. > I don’t understand this part. At Klarrio, we are using Jaeger to trace a m

Author of the post here. Thanks for reading the post and your detailed questions. > I don’t understand this part. At Klarrio, we are using Jaeger to trace a multi-tenant microservice system. We ingest data over mqtt and forward to kafka. Contexts are created on ingest and forwarded via kafka to further services. Each service adds its own spans to the trace. A message can be sent from one tenant to another, we don’t know when the trace is completed as the tenant can add spans at any time in the future. There isn’t clear end to the process. Traces can span over days. We use it to report latencies in a real time environment to a governmental body. If your trace data is perfect, everything works. The issue comes when your traces are imperfect. It is my experience that the existing tracing tools break in subtle ways when the parent span doesn't enclose the complete time for the child span (the UI and the trace analysis tools). Things may have improved a bit since I last looked though. When we treat traces as raw data, we side step these issues since we leave the real interpretation of the data in the causal graph to the reader instead of forcing a specific view of the data. > I’d like to know more how a custom solution solves this problem. At the end of the day, the trace id and parent span id still has to be somehow forwarded to the next service. When you use a tracer in application frameworks today, it comes with built in trace context propagation. However, in some contexts this may be not be ideal since your application or framework already has implicit context or some other mechanism built in. In those cases, having a lower level API just to produce spans directly is more useful. It also allows for gradual addition of tracing to your application instead of adding tracing all at once. For example, if you use a jenkins_job_id as your trace_id, you don't have to explicitly propagate any context across all those tasks in that job. OpenTracing is a higher level API in these cases and adding these lower level APIs may not be ideal. > one is not limited to a single tracer per application Yes, you can have multiple tracers per application. But, you are limited to one tracer per request execution in the current libs. > Consumption, how? In the UI? Yes, they are visible. Through an API? They’re in tags and logs fields. They’re definitely not hidden. You are right, none of the data we put on the span is hidden from the user. In the existing systems, a user is exposed to an abstraction of a span. They are not exposed to raw spans. It is in this sense, that the true spans are hidden from the user. > Jaeger has pluggable storage back ends. One of them is kafka. With kafka, it’s one step to such a solution. Either store them in a database allowing for such query (presto, druid... hello?) or write a kafka app managing alerts. Why reinvent the wheel completely? Yes, we already put this data in Presto and query that data using SQL. We tried doing it with zipkin data in the past. However, such efforts have failed because beyond a few power users regular users had a hard time querying the raw span data. Further, the current span formats are not database friendly since they have nested structure. In practice, the simplest system we found is one where the user produces the data in a specific format and then consumes the data in the same format. SpanEvent was created to provide the same view during span creation and span consumption. The short answer to why a new system is it's simpler.