Forum Discussion
Pure standards based instrumenting
After spending a little time researching, I have a concern that there's some implicit goal to create lock-in scenarios by insisting that people add Azure-specific SDKs to their projects. Despite the fact that there are already numerous cloud agnostic wire protocols to choose from.
Is there any plan to provide a way to forward standard (opentelemetry, opencensus, opentracing, zipkin, jaeger) tracing formats directly to Monitor? Specifically without having to install an Azure SDK to my project as I already am producing standard traces. My hope was that there would be a forwarder I could run per-host, even better would be to just add Monitor support to https://github.com/open-telemetry/opentelemetry-collector...
This also ensures that no matter what language I have to instrument, I don't have to rely on Microsoft to offer support for it.
atrauzzi :
Love the enthusiasm. As Microsoft, we are contributing heavily to open Telemetry; as you had pointed out our aim moving forward is to allow customers to use OTLP exporter (https://github.com/open-telemetry/opentelemetry-collector/blob/master/exporter/otlpexporter/README.md) to send in data to Azure Monitor as well. This allows customers to be vendor agnostic while welcoming the most community driven contributions.The most up to date roadmap for OTLP is available here(https://github.com/open-telemetry/opentelemetry-collector/blob/master/docs/roadmap.md); most SDK's and exporters are supposed to GA by end of this year.
As this is an opensource project feel free to join in community meetings to contribute or to provide us with any valuable feedback that you may have.
5 Replies
atrauzzi :
Love the enthusiasm. As Microsoft, we are contributing heavily to open Telemetry; as you had pointed out our aim moving forward is to allow customers to use OTLP exporter (https://github.com/open-telemetry/opentelemetry-collector/blob/master/exporter/otlpexporter/README.md) to send in data to Azure Monitor as well. This allows customers to be vendor agnostic while welcoming the most community driven contributions.The most up to date roadmap for OTLP is available here(https://github.com/open-telemetry/opentelemetry-collector/blob/master/docs/roadmap.md); most SDK's and exporters are supposed to GA by end of this year.
As this is an opensource project feel free to join in community meetings to contribute or to provide us with any valuable feedback that you may have.- Thanks Ankit!
Is there anywhere I could see a timeline for the Azure Monitor exporter specifically? How will/can I send data to Azure Monitor? Are endpoints documented anywhere? Will there be some kind of endpoint per-datacentre where all the VMs I'm running within it will pass data to?
SoubhagyaDashMicrosoft
atrauzzi We couldn't agree more, and our objective is for customers to be successful on Azure regardless of their choice of instrumentation or monitoring consumption tools. We are in fact, contributing to the OpenTelemetry effort, and Azure SDKs (including Application Insights SDKs) will be OpenTelemetry based. Stay tuned for updates in this space.
Any chance you can offer a timeline or any detail on what's coming? My apologies, I feel like it would be better to know early as I've been disappointed in the past over "stay tuned" and it ends up being a less than optimal solution. And then I'm stuck trying to convince Azure PMs and support channels that what was implemented wasn't actually helpful...
- SoubhagyaDash
atrauzzi We are on the OT GitHub repos, so what we are implementing/contributing to is public information. Please weigh in on the right repos like https://github.com/microsoft/opentelemetry-azure-monitor-python. From what I gather, you have concerns regarding supporting OT exporter based collection as opposed to the Collectors?
