OpenTelemetry

#1

Post by privacyonsec » Wed, Sep 23, 2020, 8:59 PM UTC

Re: OpenTelemetry

#2

Post by polskibus » Wed, Sep 23, 2020, 9:47 PM UTC

So how does this differ from open census, openmetrics, opentracing? It would be great if one open-something combined metrics and other observability tools in one spec/toolset like application insights does. Otherwise, developers waste a lot of time evaluating various open-whatevers, and having to use more than one.

Re: OpenTelemetry

#3

Post by thayne » Wed, Sep 23, 2020, 9:51 PM UTC

polskibus wrote: post #2

So how does this differ from open census, openmetrics, opentracing? It would be great if one open-something combined metrics and other observability tools in one spec/toolset like application insights does. Otherwise, developers waste a lot of time evaluating various open-whatevers, and having to use more than one.

I think OpenCensus and OpenTracing are being combined into OpenTelemetry. I'm not sure about OpenMetrics.

Re: OpenTelemetry

#4

Post by candiddevmike » Wed, Sep 23, 2020, 10:02 PM UTC

Here be dragons. I really want to use this project, but the spec and libraries keep changing. I would not adopt this yet, too much is in flux.

As an aside, I think this project is suffering from analysis paralysis. Ship a stable 1.0, iterate towards a 2.0 eventually based on user feedback. You aren't going to release a perfect 1.0.

Re: OpenTelemetry

#5

Post by setheron » Wed, Sep 23, 2020, 10:08 PM UTC

The reference Java implementation uses too much hard-coded static variables. Look sexy for demonstration, but is it configuration nightmare.

I had a lot more success and ease of use using open zipkin, highly recommend.

Re: OpenTelemetry

#6

Post by ahachete » Wed, Sep 23, 2020, 10:20 PM UTC

setheron wrote: post #5

The reference Java implementation uses too much hard-coded static variables. Look sexy for demonstration, but is it configuration nightmare. I had a lot more success and ease of use using open zipkin, highly recommend.

I'm not affiliated with otel, but I'd say it is just otel is still moving forward quickly and there's no good (almost not) documentation on how to use it.

I did some small setup with otel, Java and Quarkus, and I will publish a blog post soon on how I did it.

Re: OpenTelemetry

#7

Post by ahachete » Wed, Sep 23, 2020, 10:21 PM UTC

thayne wrote: post #3

polskibus wrote: post #2

So how does this differ from open census, openmetrics, opentracing? It would be great if one open-something combined metrics and other observability tools in one spec/toolset like application insights does. Otherwise, developers waste a lot of time evaluating various open-whatevers, and having to use more than one.

I think OpenCensus and OpenTracing are being combined into OpenTelemetry. I'm not sure about OpenMetrics.

That's correct. And OpenMetrics is a standardization effort on metrics (basically, standardize and improve Prometheus format).

Re: OpenTelemetry

#8

Post by jrockway » Wed, Sep 23, 2020, 10:27 PM UTC

candiddevmike wrote: post #4

Here be dragons. I really want to use this project, but the spec and libraries keep changing. I would not adopt this yet, too much is in flux. As an aside, I think this project is suffering from analysis paralysis. Ship a stable 1.0, iterate towards a 2.0 eventually based on user feedback. You aren't going to release a perfect 1.0.

I agree. They were very quick to update their website to say "we're making a new thing", but the new thing isn't ready.

I used the metric implementation in Go (as someone with extensive Prometheus experience), and was shocked at how they managed to write so much code to do so little. You will be amazed at how many levels of indirection there are, with a little assumption hard-coded at every single point of indirection. (The net result being, in my case, that I couldn't actually create a gauge in Prometheus.)

I just use Jaeger and Prometheus together and they've never treated me wrong. I'm watching otel closely, but I wouldn't suggest that you use it quite yet, at least not for Go.

Re: OpenTelemetry

#9

Post by aryc19 » Wed, Sep 23, 2020, 10:48 PM UTC

I'm really looking forward to using this project when it's stable. I briefly experimented with their Python SDK to try and record metrics but their documentation seemed either out of date or non-existent for some features. I'll wait for them to reach 1.0 in the hope that the documentation gets better and existing issues are resolved.

Re: OpenTelemetry

#10

Post by candiddevmike » Wed, Sep 23, 2020, 10:50 PM UTC

jrockway wrote: post #8

candiddevmike wrote: post #4

Here be dragons. I really want to use this project, but the spec and libraries keep changing. I would not adopt this yet, too much is in flux. As an aside, I think this project is suffering from analysis paralysis. Ship a stable 1.0, iterate towards a 2.0 eventually based on user feedback. You aren't going to release a perfect 1.0.

I agree. They were very quick to update their website to say "we're making a new thing", but the new thing isn't ready. I used the metric implementation in Go (as someone with extensive Prometheus experience), and was shocked at how they managed to write so much code to do so little. You will be amazed at how many levels of indirection there are, with a little assumption hard-coded at every single point of indirectio…

Which Jaeger go library are you using? https://github.com/jaegertracing/jaeger-client-go?

For prometheus, I was using the official Go client, but I found the victoria metrics one to be a lot simpler and lighter. My go.mod was a lot smaller after swapping.