Hacker News Reader

Comment by tlarkworthy | Hacker News Reader

Tracing is a cross functional concern, and therefore does not belong in application binaries but in a sidecar or reverse proxy intermediates, where it can be written once and applied to everything. If you do not have the need for these complex deployments then don't bother with tracing either.

View on HN

I disagree. There are internal parts of the application that benefit from tracing, and if you are using the OpenTracing standard, tagging your traces with metadata can allow correlations in the data to stand out (something LightStep is good at). Tracing at only your edges wont help you discover that requests get slower for customers with some subset of features enabled with given settings, for example.

While I 100% agree that having doing most of the tracing at the sidecar level is the right call, you'll still need "some" application-level awareness of tracing (e.g. passing along b3 headers: https://github.com/openzipkin/b3-propagation ), or you won't be able to match various spans to a common trace and lose a _lot_ of value from your distributed tracing.

Good point you need to pass the correlation key, but the sidecar is the one talking to the tracing infra

I don't see how this advice can work in practical applications. It's not unusual for a single user request in a large system to invoke thousands of internal requests and the depth of the call graph can be tens of edges. If each of those requests has to traverse a proxy 4 times, you'll wreck your service latency. And, as another comment noted, you'll lose the ability to represent the internal structure of calls as trace spans, or to log to them, or to tag them.

Reply on news.ycombinator.com