I have divided (and partly uninformed) views on OpenTelemetry

8 points by valyala

davetron5000

I put OTel into Brut as a standard way to get observability in any app. There are two things that are hard about it:

  1. there is not a lot of documentation about it that is useful. There is definitely a lot of text that could be construed as documentation, but the system is highly flexible, somewhat convoluted, and lacking clear examples. I had to use a lot of ChatGPT—which was usually wrong in what it told me, but wrong in a way that helped me figure it out—to make any progress.

  2. You have to somewhat plan ahead for what you want to find and how. You can’t just assume you can grep it out of whatever, like you can with logs. TBH, grepping out of whatever is extremely useful, but you are the mercy of your OTel vendor to be able to search

That all said, there’s no reason to have vendor-specific metrics/loging/etc/ formats. OTel appears to work well, it’s just not well-socialized.

quad

@cks, the OpenTelemetry (Otel) ecosystem is complicated. A few key points:

  1. Otel Metrics has a design goal of full support for Prometheus. This might be embrace-extend-extinguish in action; but, that’s the current state of play.
  2. Otel Metrics SDK has few different metrics exporters. The OTLP and Prometheus are two that matter for production use. The OTLP exporter pushes metrics to a collector in its (complex) format, where the Prometheus exporter’s metrics can be pulled by anything that supports the (simple) format.

In short, if Prometheus works for you, stick with it, because “Prometheus support” is sufficient to “OpenTelemetry support!”