[vmarchaud]

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

[polskibus]

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

[mmclean]

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.

[polskibus]

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.