New Blog Post: Transforming Traces into Metrics with OpenTelemetry about opentelemetry.io HOT 4 OPEN

thanks @reese-lee , @set808 happy to have this blog post. A few points:

• We will not be able to publish this very soon, with KubeCon in front of us, so after you raised the PR it might happen that we will not review it swiftly
• Double check if any of the content from your blog post should also be part of the official documentation. Having a section on the span metrics processor in our docs would be great.
• And yes, all reference to New Relic needs to be removed.

from opentelemetry.io.

from opentelemetry.io.

@set808 🥳 Can you include a link to the original NR post?

Note to Comms SIG: This a repost from the above and will include it as a canonical URL, but any content that is specific to New Relic will be removed for the OTel blog.

from opentelemetry.io.

I have a couple of concerns I'd like to see addressed.

First, spanmetrics is lossy; You're trading wire size for a reduction in cardinality/event detail. This isn't mentioned in your post, and would possibly surprise a user who blindly followed it only to discover that they were throwing away all details outside of span name, duration, http method, and status code. Since not everyone using OpenTelemetry is in a resource-metered environment, it would be good to have a more thorough discussion of these tradeoffs.

Second, I don't know if the blog is the best place for this kind of content. Given the tradeoffs I mentioned, I think it would possibly be more valuable to have this as a documentation page that went more in depth on the configuration and usage of spanmetrics, along with a more thorough discussion of configuring the connector.

from opentelemetry.io.