Thank you for your kind words! 
I’m also confident that Phoenix will integrate
:telemetryfor HTTP/Websocket instrumentation in a near future.
That’s the plan! You can check out my fork here GitHub - arkgil/phoenix at telemetry · GitHub. I try to keep it up-to-date with the most recent Telemetry version, although there are barely any changes comparing to stock Phoenix: Comparing master..telemetry · arkgil/phoenix · GitHub (I haven’t instrumented the channels, though). Also note that it’s not up-to-date with Phoenix master, basically I use it for experimenting with new Telemetry versions 
Also, most metric tracking services I’ve used so far use something like a “transaction” in order to group different metrics together.
This kind of tracing is something I keep in the back of my mind. As you said, a lot of APM solutions offer such features, and there are even a couple standards for it, like OpenTracing and OpenCensus. For this to work, we would need to somehow correlate events and decide when to open and close a span (one “level” in the trace). This is not hard to achieve in the context of a single process (e.g. see tracelog) but becomes more tricky with multiple processes, since you need to pass a value which correlates the events between them. Still, having it even for a single process would be awesome, and would work well for a number of Phoenix+Ecto apps. As with metrics, I don’t think it belongs in the Telemetry library itself, but it would be a great addition to the ecosystem!
