Skip to main content
The Azure Monitor OpenTelemetry Distro is Microsoft’s distribution of the OpenTelemetry SDK for .NET, Java, Node.js, and Python. It bundles auto-instrumentation and is a convenient way to instrument applications on Azure compute platforms such as App Service, Functions, AKS, and VMs. The Distro is built around the Azure Monitor exporter, so it always sends telemetry to Azure Monitor / Application Insights. Because it is built on the standard OpenTelemetry SDK, you can add an OTLP exporter to forward the same logs and traces to Bronto as well.
This is a good fit if you already use Application Insights and want the same data in Bronto. If you only need data in Bronto, a self-managed OpenTelemetry Collector or the vendor-neutral OpenTelemetry SDK sends directly to Bronto without also routing through Azure Monitor.

​
How it compares to standard OpenTelemetry

The Distro is not a separate agent — it is the upstream OpenTelemetry SDK plus Microsoft defaults: bundled auto-instrumentation, automatic Azure resource attributes, an Application Insights-aware sampler, and an always-on Azure Monitor exporter. Everything it emits is standard OpenTelemetry data, so anything you can capture with the Distro you can also capture with the plain SDK or a Collector. Two things matter when forwarding to Bronto:
  • The Azure Monitor leg can’t be removed. The Distro is built around the Azure Monitor exporter, so it always ships to Application Insights; adding an OTLP exporter sends the same telemetry to Bronto as well, so you pay on both sides. If you only want Bronto, use a Collector or the plain SDK.
  • Some features are Azure-only. Live Metrics, Statsbeat, and the Profiler are proprietary to Azure Monitor and have no OTLP equivalent, so they are not forwarded to Bronto. Logs and traces are — in standard OTLP form rather than the Application Insights schema.

​
Adding Bronto as a destination

Add an OTLP exporter pointing at Bronto. The simplest approach is the standard OpenTelemetry environment variables, which the Distro respects for its OTLP exporter: 
OTEL_EXPORTER_OTLP_ENDPOINT=https://ingestion.<REGION>.bronto.io
OTEL_EXPORTER_OTLP_HEADERS=x-bronto-api-key=<YOUR_API_KEY>
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
Replace <REGION> with eu or us and <YOUR_API_KEY> with your Bronto API key. Configure only logs and traces — Bronto does not ingest metrics. See the Bronto ingestion endpoints for the full endpoint list. You can also add the OTLP exporter in code (for example, an additional span processor in Node.js or AddOtlpExporter() in .NET); see Microsoft’s OpenTelemetry configuration guide for per-language examples.
Microsoft does not officially support the OTLP exporter or third-party backends downstream of the Azure Monitor Distro.

​
Sending to both Azure Monitor and Bronto with a Collector

If your goal is to land data in both Application Insights and Bronto, a standard OpenTelemetry Collector can fan out to both without the Distro — and it stays fully supported upstream. Point your applications’ OTLP export at the Collector and configure two exporters: the contrib azuremonitor exporter for Application Insights and otlphttp for Bronto. 
receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
  resourcedetection/azure:
    detectors: [env, azure]   # use [env, aks] on AKS; adds Azure resource attributes

exporters:
  azuremonitor:
    connection_string: "${APPLICATIONINSIGHTS_CONNECTION_STRING}"
  otlphttp/bronto:
    logs_endpoint: "https://ingestion.<REGION>.bronto.io/v1/logs"
    traces_endpoint: "https://ingestion.<REGION>.bronto.io/v1/traces"
    compression: gzip
    headers:
      x-bronto-api-key: <YOUR_API_KEY>

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [resourcedetection/azure, batch]
      exporters: [azuremonitor, otlphttp/bronto]
    logs:
      receivers: [otlp]
      processors: [resourcedetection/azure, batch]
      exporters: [azuremonitor, otlphttp/bronto]
This keeps your applications on vendor-neutral OTLP and moves the dual-destination routing into the Collector, which also adds batching, compression, and retries. The resourcedetection processor adds the same Azure resource attributes (VM, App Service, or AKS metadata) that the Distro would populate automatically.

​
Routing in Bronto

Set the service.name and service.namespace resource attributes so Bronto routes telemetry to the correct dataset and collection — see Data Organization. These are the same attributes the Distro already uses for Application Insights, so no Bronto-specific changes are needed beyond the OTLP exporter.
For assistance or questions, contact support@bronto.io.