Move to OpenTelemetry?

[andrejpk]

Azure Monitoring is moving to OpenTelemetry as the future of instrumentation

Azure SDK tooling is also moving that way .NET SDKs: Experimental Java SDKs: Beta

One of the benefits of OpenTelemetry is separating instrumentation of libraries/frameworks from the monitoring tools that collect, ingest and analyze that data. This is done through standard APIs to write and read and write telemetry and metrics. See what is OpenTelemetry

One possible path forward for this project is to move from the App Insights enrichment libraries to the OpenTelemetry ones.

• Continues to enrich the App Insights telemetry objects with Kubernetes values
• Makes this same data available to any OpenTelemetry collector

Is it a good time to consider this, possibly as a fork? (Does that exist? I couldn't find one)

[xiaomi7732]

Hey @andrejpk thanks for filing the issue and sorry for the late reply.

Ever since the release of the beta package of Azure.Monitor.OpenTelemetry.Exporter , there hasn't been too much progress. I am concerned about the adoption rate.

Java SDK seems have more beta releases but the usage on the maven repo is also not high: https://mvnrepository.com/artifact/com.azure/azure-core-tracing-opentelemetry

At this moment, we can't justify the resources to support OpenTelemetry. Feel free to fork the repo and do experiments.

[hcoona]

Want OpenTelemetry corresponding as well.

[xiaomi7732]

Hey @andrejpk, @hcoona, thanks for the feedback. Things definitely have been changing rapidly for open telemetries. One interesting thing, by design of OpenTelemetry, Kubernetes is natively supported by the collector: https://opentelemetry.io/docs/kubernetes/collector/components/#kubernetes-attributes-processor

Is there any reason you still want to have a library to attach those properties for you?

[hcoona]

@xiaomi7732 My scenario is a bit different. We can modify our code and instrument it directly. We want to send all 3 aspects (metrics/logs/traces) to a standalone Azure Monitor because AKS Prometheus cannot support traces. Thus, we want a Resource Detector to collect necessary information in Kubernetes environment. In our scenario, we didn't use a collector.

[xiaomi7732]

Let me open this issue since things have been changed. Please help me understand, how many of you are planning on using OpenTelemetry with this package or similar package? Please comment below.

[hcoona]

I still want it but not urgent.

I write myself a poor-man version to read node name from environment variable which can be injected in k8s YAML file via metadata, pod name from hostname and pod namespace from /var/run/secrets/kubernetes.io/serviceaccount/namespace