Hacker News Reader

Comment by polskibus | Hacker News Reader

This stack sees a lot of changes. I can see opentelemetry mentioned as next step. Is the overaching goal to produce a spec and reference implementation that could replace ApplicationInsights from Microsoft? Can someone with more knowledge about one or the other chime in with their insights?

View on HN

I'm working on the OpenTelemetry JS project and i previously worked a bit on OpenCensus NodeJS.

The aim with both projects (OpenCensus/OpenTelemetry) is the same: having a open source implementation where you can change the exporter (to GCP,AWS,Zipkin,Jeager or anything you want) whenever you like. So Microsoft (or someone else having the API to report data to Azure) could totally implement an exporter for ApplicationInsights. Both projects have a specs [0][1] that are implemented in multiples languages.

Note: OpenTelemetry is just the project that resulted from the merging of OpenTracing and OpenCensus.

[0] https://github.com/census-instrumentation/opencensus-specs [1] https://github.com/open-telemetry/opentelemetry-specificatio...

Is there a plan to enrich opentelemetry with error information, see sentry.io for an example?

Right now we're focused on the first release of OpenTelemetry, which will include distributed traces and metrics. Many users and contributors have asked for logging support, and this was already a big discussion topic in the pre-merger OpenCensus and OpenTracing communities - I'd expect us to start focusing on this after the release later this year. There have also been some early conversations around support for an error first-class signal type (there was a recent GitHub issue, though now I can't find it), however to my knowledge we haven't yet started any error-related specs or design discussions.

You can certainly add error-related annotations to traces, however these will typically be sampled.

Error information is a bit different than general logging - stacktraces, annotation of exceptions with case-specific information, matching that data with debug symbols, etc. It would be interesting to see the ability to enrich standard logging with custom-shaped data, without sampling, in a standardized way.

Yes, mature OpenTelemetry could replace vendor specific SDKs like AppInsights SDKs though we are not there yet today. As mentioned vmarchaud and manigandham, Microsoft could implement an exporter and has implemented an exporter for OpenCensus Python SDK. Microsoft is on path to implement the similar exporter for Python and other languages. Not only has Microsoft implemented exporter, it has joined force with other community members like Google, Dynatrace etc. to actively contribute to the OpenTelemetry project. E.g. it has been playing leading role in creating Python OpenTelemetry SDKs while in the process to contribute to .NET heavily.” Meanwhile the existing C#/Java/Node.js ApplicationInsights SDKs are still under active development and production support.

Yes, OpenTracing (+ OpenMetrics) are API specs. OpenCensus is a competing project with API specs and libraries. They're merging into a single project called OpenTelemetry with API specs + libraries for tracing + metrics now and logs later.

These APIs/libraries are just the collection part in your app and the actual data can be sent to various backends, like Zipkin, Jaeger, Stackdriver and even ApplicationInsights. Microsoft is also working on making the existing (asp).net APM hooks more extensible to work better with these standards.

Reply on news.ycombinator.com