9 ms·
OpenTelemetry
- polskibus 6y agoSo 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.
- thayne 6y agoI think OpenCensus and OpenTracing are being combined into OpenTelemetry. I'm not sure about OpenMetrics.
- ahachete 6y agoThat's correct. And OpenMetrics is a standardization effort on metrics (basically, standardize and improve Prometheus format).
- polskibus 6y agoIt would be great if they could all come under common OpenMonitoring umbrella, as ApplicationInsights does it.
- harpratap 6y agoNot sure what OpenMonitoring is but OpenTelemetry = Tracing + Metrics + Logging. So we don't really need any more Open-X standards in the observability space IMO
- polskibus 6y agoYou are right, acc. https://opentelemetry.io/about/ https://opentelemetry.io/about/ Logging support is incubating.
- binarylogic 6y agoYeah, we're trying to solve for this over at https://vector.dev https://vector.dev. We intend to decouple the pipeline from the method. As demonstrated by OT, this stuff changes, and you shouldn't have to rip out your plumbing every time it does. We're aiming to support all data (logs, metrics, and traces) as well as popular standards.
- polskibus 6y agoHow does it differ from ApplicationInsights in Azure?
- candiddevmike 6y agoHere 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.
- jrockway 6y agoI 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.
- candiddevmike 6y agoWhich Jaeger go library are you using? https://github.com/jaegertracing/jaeger-client-go 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.
- jrockway 6y agoI use the official ones for both, but haven't even considered looking for others. Jaeger is a little annoying in that what configuration the library accepts depends on the language. For example, you have to modify your code to emit B3 (zipkin-compatible) traces, which is annoying. Leads to PRs like this: https://github.com/grafana/grafana/pull/17009 https://github.com/grafana/grafana/pull/17009
- tignaj 6y ago
- setheron 6y agoThe 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.
- ahachete 6y agoI'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.
- brown9-2 6y agoThe lack of documentation is a problem, and I’m not sure that moving fast is a great excuse. OpenCensus has the same problem - some pages have said “coming soon” for years https://opencensus.io/advanced-concepts/context-propagation/ https://opencensus.io/advanced-concepts/context-propagation/
- jkwatson 6y agoOne of the maintainers of the java implementation here. If you have issues with the configuration story for the java SDK, please let us know! We're trying hard to make it very configurable and extensible, and user feedback would be very valuable to have. Thanks!
- aryc19 6y agoI'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.
- austinlparker 6y agodisclaimer: i'm an otel maintainer (specifically on community/web stuff!) to echo some points from comments, I'm painfully aware of the state of the official documentation. I'm actually in the process of revamping the site to provide a framework for docs in each language to try and alleviate this. I expect it to be ready by 1.0.
- aphexairlines 6y agoThe java implementation seems to lean on trying to pass context objects around implicitly as a ThreadLocal. This will cause pain and suffering in the presence of async, multithreaded code: your trace context will be present in the thread where your request handler began, but won't be present in threads running callbacks from non-blocking IO libraries (netty, akka-http, async-http-client, redisson, etc).
- svcrunch 6y agoFor Java, what's the advantage of using this library, versus directly using JMX? Are the abstractions better? I took a look at the documentation and it wasn't clear to me.
- jkwatson 6y agoMaintainer of the java implementation here. OpenTelemetry is really orthogonal to JMX. We're trying to provide a standard way to capture spans (traces) and metrics and send them to observability systems, both open source and vendor-provided. Those metrics might originate from JMX, or any other source of metrics you might have. Our APIs do provide a way to directly capture metrics, but also to hook into existing metric providers (like JMX or JFR).
- jkwatson 6y agoJava implementation maintainer here. Our context propagation story is still evolving and under active development. We are hyper-aware of the issues with managing propagation with asynchronous contexts, and are working on building a solution that instrumentation authors can use to manage the propagation of context both synchronous and asychronous. If you have expertise in this area, we would love help and feedback on what we're building!
- aphexairlines 6y agoWhen we integrated async jvm (scala) services with another tracing provider, we took two approaches. One was to pass the trace context down from the request handler through anything that would declare a span or need to send trace headers down to another service. The other was to instantiate service clients per request, and pass the trace context into the service client constructor.
- bitbckt 6y agoI don't use any of their libraries, but follow the spec closely. At the very least, it's forcing some standardization among APM vendors (DataDog 64b trace_id, I'm looking at you). Also, related: https://www.w3.org/TR/trace-context/ https://www.w3.org/TR/trace-context/
- jeffbee 6y agoEven 32 bytes is completely over the top for trace ID. Even the 16 bytes in this spec is pretty much just wasted space.
- sa46 6y agoI think Datadog's trace_id is 64 bits which I thought was a good balance between efficiency and uniqueness. Pretty sure Dapper used 64 bits as well. I also don't understand the purpose of the 16 bytes for the trace_id in the spec. That's a huge range of numbers. Anyone know the rationale?
- tignaj 6y agoDisclaimer: I work on OpenTelemetry spec. Many tracing solutions settled on 128bits/16 bytes trace ids. Here is Jaeger's rationale: https://github.com/jaegertracing/jaeger/issues/858 https://github.com/jaegertracing/jaeger/issues/858 It is also recommended by W3C: https://www.w3.org/TR/trace-context/#trace-id https://www.w3.org/TR/trace-context/#trace-id
- jeffbee 6y agoNeither Jaeger nor W3C seem to present any justification for 16 byte trace identifiers, just FUD.
- bitbckt 6y agoBigBrotherBird (now OpenZipkin... thanks legal, sigh) used 128b trace_ids when we first built it at Twitter. I don’t recall the reasoning, but that’s the first system I know of which chose that size. Dapper used 64b IDs for span and trace, but being locked inside the Googleplex probably limited its influence on compatibility issues. My point is that 128b is the common standard now, and that’s all that I really care about - that the standard exists and APM systems conform to it. To that end, I am very pro-otel. Thanks for your work.
- otherview 6y agoThe tracing package is pretty solid. The metrics, is still changing. I 100% support this I think theres great work behind it. Eager to see how they tackle logs.
- tignaj 6y agoHere is the draft plan for logs: https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/logs/overview.md https://github.com/open-telemetry/opentelemetry-specificatio... Logs are not going to be part of OpenTelemetry 1.0 release (only traces and metrics will). Logs are coming later (no specific timeline yet). Disclaimer: I work on OpenTelemetry spec and wrote most of the linked doc. Comments/issues/PRs welcome in the repo.
- lucb1e 6y agoI don't quite get it, what does this do? The readme says absolutely nothing (e.g. "The OpenTelemetry specification describes the cross-language requirements and expectations for all OpenTelemetry implementations." and goes on to describe how to submit changes or on which proprietary platform meeting minutes can be found) and the Overview document goes into depths about terminology (what a trace is, what a span within a trace is, how to link spans, etc.). Nowhere does it say if this is supposed to, for example, replace proprietary crash reporting in apps so that we can know what is being reported back to the mothership, or if this is something completely different.
- harpratap 6y agoYou can check the first link that states the overview - https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/overview.md https://github.com/open-telemetry/opentelemetry-specificatio... It's a distributed request tracing specification & set of libraries implementing the said spec
- austinlparker 6y agowe also explain it a bit on our website, https://opentelemetry.io https://opentelemetry.io
- systemvoltage 6y agoThe fact that this is the top comment and most people are confused about what Open Telemetry is about should indicate that it is not clear. This is too often a mistake - not knowingly. It's like proof reading, I always think my writing is correct until someone else points out mistakes.
- austinlparker 6y agoThanks for the feedback, I just opened a PR to add a link from the spec readme to our website to hopefully guide people to better information.
- austinlparker 6y agodisclaimer: otel maintainer, etc. one thing I want to point out is that, eventually, we'd like for a lot of the complaints people have to be... well, things that you don't have to complain about, because it's not important. three or four years from now, it'd be nice to see a world where most people don't actually have to interact with otel at all because it's either built-in to the libraries/frameworks they're using, or because they're using some kind of wrapper that helps with best practices. you can see an example of this with something we're doing at lightstep - we're introducing launchers that wrap upstream otel and standardize config format/defaults between multiple languages (https://github.com/lightstep/?q=launcher https://github.com/lightstep/?q=launcher), and trying to provide "missing link" documentation (https://otel.lightstep.com https://otel.lightstep.com). i suspect that eventually the question of "how do i use opentelemetry" becomes a moot point because it's already there.
- giulianob 6y agoI've been using the opentelemetry package for C# to push tracing data to Honeycomb and it's really good. It takes a bit of learning but it's extremely powerful. Once you're over the hump it's very easy to quickly add new telemetry and its night and day difference to typical logs/metrics.
- maurys 6y agoJust a quick summary. Trace - One unique id for an "action", say customer purchasing an item. A set of spans exist under a trace. Span - An interval with a start time and duration. Can add tags for querying. Can add logs for richer information but not indexed. Each span belongs to exactly one trace. Baggage - key value pairs you can pass between services. They aren't tagged as part of the span or trace, but the receiving service can use these values to make decisions or add them to its local spans as logs or spans. Under the hood, it's just a set of HTTP headers passed between services. The first span creates a trace id and passes that to all downstream services as a header. Each service independently pushes it's span data into a centralised collector which indexes the data and exposes it over an UI/API. OpenTelemetry provides a specification and some reference implementation across languages. At least, this is my understanding of it. I've dabbled with Jaegar but I'm not affiliated with any of these.
- boggsi 6y agoTo all the OpenTelemetry people reading this page - please include the above description somewhere in your project. I actually googled the definition of telemetry because I had no idea what you were talking about, I thought it had something to do with space observations given all the telescopes? My second guess was that it had something to do with the way data from accelerometers was handled? Standardising tooling for sensors? This comment was the first thing to explain that it's better logging. That's actually something I'd be interested in, running several different datascience services/analyses, logging was something I implemented then gave up on because it sucks so much. You're losing a lot of potential players because you have given 0 effort to explaining in simple terms what you are. A "From logging to telemetry" primer would probably garner you a lot more interest.
- privacyonsec 6y agoit's probably not on the front page but they actually explain what is telemetry and observability here: https://opentelemetry.io/about/ https://opentelemetry.io/about/ But I agree this is a better explanation :)
- cnr 6y ago
- csunbird 6y agoFirst thing that came to my mind when I saw the project title was the opentracing.io project. Glad to see that this is actually opentracing and opencensus merging their approaches.