Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenTelemetry

github.com

Post reply on HN
Print view View original

51–60 of 66 posts

Re: OpenTelemetry

#51

Post by aphexairlines »

jeffbee wrote: post #36
aphexairlines wrote: post #11

The 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).

Async style is not incompatible with storing the trace context in thread-local storage. You just capture the trace context when you create the callback. That's how Dapper works, in C++ and Java. See section 2.2 of the Dapper paper. https://storage.googleapis.com/pub-tools-public-publication-...

From that section: "most Google developers use a common control flow library to construct callbacks"

OpenTelemetry can't guarantee that their users will use a specific library to create callbacks and can't then ensure that this library wraps callbacks with the appropriate threadlocal setup.

Users would by default run into problems unless they take a number of precautionary steps.

Re: OpenTelemetry

#52

Post by aphexairlines »

jkwatson wrote: post #28
aphexairlines wrote: post #11

The 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).

Java 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…

When 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.

Re: OpenTelemetry

#53

Post by privacyonsec »

boggsi wrote: post #50
maurys wrote: post #49

Just 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 recei…

To 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 fo…

it's probably not on the front page but they actually explain what is telemetry and observability here:

https://opentelemetry.io/about/

But I agree this is a better explanation :)

Re: OpenTelemetry

#54

Post by csunbird »

First 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.

Re: OpenTelemetry

#55

Post by polskibus »

ahachete wrote: post #7
thayne wrote: post #3

Earlier quoted context omitted.

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).

It would be great if they could all come under common OpenMonitoring umbrella, as ApplicationInsights does it.

Re: OpenTelemetry

#56

Post by polskibus »

binarylogic wrote: post #12
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.

Yeah, we're trying to solve for this over at 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.

How does it differ from ApplicationInsights in Azure?

Re: OpenTelemetry

#57

Post by faichai »

m12k wrote: post #47
austinlparker wrote: post #35

Earlier quoted context omitted.

Thanks 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.

With so many people finding things via GitHub, I'd highly recommend also including a single paragraph at the top of the repo readme to explain what it is, rather than expect people to be curious enough to go digging for more info. E.g. you could use the explanation from the website: "OpenTelemetry provides a single set of APIs, libraries, agents, and collector services to capture distributed traces and metrics from y…

Yeah, particularly for a developer oriented product. GitHub readme is essentially a landing page and should be treated the same way, not assuming any foreknowledge for the reader.

Re: OpenTelemetry

#58

Post by harpratap »

polskibus wrote: post #55
ahachete wrote: post #7

Earlier quoted context omitted.

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

It would be great if they could all come under common OpenMonitoring umbrella, as ApplicationInsights does it.

Not 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

Re: OpenTelemetry

#59

Post by cnr »

boggsi wrote: post #50
maurys wrote: post #49

Just 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 recei…

To 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 fo…

My first thought was "TV viewership metrics", but in this context adjective "open" seemed a little contradictory.

Re: OpenTelemetry

#60

Post by brown9-2 »

jkwatson wrote: post #28
aphexairlines wrote: post #11

The 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).

Java 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…

> building a solution that instrumentation authors can use to manage the propagation of context both synchronous and asychronous

The bigger problem I’ve had - with OpenCensus - is managing the context within my application using async code, where I want to add interior spans and also call libraries which are creating spans themselves.

Do your plans include these scenarios? Am I an “instrumentation author” here?

There is really no way to make anything related to ThreadLocals work with “async” code, and the simplest most reliable solution we have found is to treat the Context as a method parameter. Looking at https://github.com/open-telemetry/opentelemetry-java/issues/... I worry that more layers of indirection will be added, not less.

Post reply on HN