OpenTelemetry on Azure

Bronto ingests OpenTelemetry logs, metrics, and traces over OTLP/HTTP. On Azure, the recommended path is a self-managed OpenTelemetry Collector, which sends data straight to Bronto with full control over routing and processing.

Exponential histograms are not supported, and the Metric Explorer does not currently provide a Rate function.

Choosing an Approach

Approach	Best for	Notes
Self-managed OTel Collector (recommended)	AKS, VMs, Container Instances, Container Apps	Sends logs, metrics, and traces directly to Bronto with full control over processing, routing, and fan-out.
OpenTelemetry SDK	Any runtime (App Service, Functions, etc.)	The vendor-neutral OpenTelemetry SDK and auto-instrumentation, exporting OTLP directly to Bronto.
Azure Monitor OpenTelemetry Distro	Teams already using Application Insights	Microsoft’s SDK distro — a convenient option if you already run Application Insights and want to forward the same data to Bronto. See the dedicated page.

Bronto Ingestion Endpoints

Signal	EU Region	US Region
Logs	`https://ingestion.eu.bronto.io/v1/logs`	`https://ingestion.us.bronto.io/v1/logs`
Metrics	`https://ingestion.eu.bronto.io/v1/metrics`	`https://ingestion.us.bronto.io/v1/metrics`
Traces	`https://ingestion.eu.bronto.io/v1/traces`	`https://ingestion.us.bronto.io/v1/traces`

The /v1/logs, /v1/metrics, and /v1/traces endpoints accept OTLP protobuf over HTTP only. Exponential histograms are not supported.

All requests require the header:

x-bronto-api-key: <YOUR_API_KEY>

See API Keys for how to generate a key.

Self-Managed OpenTelemetry Collector

Running your own OpenTelemetry Collector is the recommended approach: it sends logs, metrics, and traces straight to Bronto, without routing your data through any other vendor, and gives you:

Full configuration control — custom processors, attribute transformation, or sampling rules
Fan-out — forwarding the same telemetry to multiple backends simultaneously
Existing OTel infrastructure — you already operate a collector fleet and want to add Bronto as an exporter
Advanced routing — sending different log types or services to different Bronto datasets or collections

Application logs, metrics, and traces can be sent directly to Bronto’s ingestion endpoints, but routing through a Collector is strongly recommended. The Collector handles retries, batching, and compression.

Supported sources

A self-managed Collector can run anywhere you control compute, and supports any source that has an OpenTelemetry receiver:

Service / Source	Data types
Azure Virtual Machines / VM Scale Sets	Application logs, metrics, and traces
Azure Kubernetes Service (AKS)	Application logs, metrics, and traces (DaemonSet or Deployment)
Azure Container Apps	Application logs, metrics, and traces (Collector container)
Azure Container Instances (ACI)	Application logs, metrics, and traces (sidecar container)
Any Azure workload reachable from the Collector	Logs, metrics, and traces via OTLP and other OTel receivers

The Collector forwards only what it receives — deploying it does not automatically collect your logs. If you aren’t seeing all the logs you expect:

Application logs, metrics, and traces require instrumenting your app with the OpenTelemetry SDK, or tailing its log files with the filelog receiver.
Azure platform and diagnostic logs (resource logs, activity logs) are not collected by the Collector — they are exported through Azure Monitor diagnostic settings via the Event Hub Forwarder.

See Ingesting Azure Data into Bronto for the full per-service source-to-method mapping, and the per-service pages — AKS, Container Apps, Container Instances, App Service, Functions, Virtual Machines — for what each service emits and how.

Collector configuration

The core Bronto exporter configuration is the same regardless of how you deploy the collector on Azure. For full installation instructions and parameter reference, see the OpenTelemetry Collector guide. The minimal configuration exports logs, metrics, and traces to Bronto:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  otlphttp/bronto:
    logs_endpoint: "https://ingestion.<REGION>.bronto.io/v1/logs"
    metrics_endpoint: "https://ingestion.<REGION>.bronto.io/v1/metrics"
    traces_endpoint: "https://ingestion.<REGION>.bronto.io/v1/traces"
    compression: gzip
    headers:
      x-bronto-api-key: <YOUR_API_KEY>

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/bronto]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/bronto]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/bronto]

Replace <REGION> with eu or us and <YOUR_API_KEY> with your Bronto API key.

Deployment options on Azure

Azure Kubernetes Service (AKS)

Deploy as a DaemonSet (one collector per node) for node-level log collection, or as a Deployment behind a ClusterIP service for centralised collection. The simplest path is the OpenTelemetry Helm chart:

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install otel-collector open-telemetry/opentelemetry-collector \
  --values values.yaml

Add the k8sattributes processor to enrich logs, metrics, and traces with pod, namespace, and node metadata. See the OpenTelemetry Collector guide for a complete values.yaml example.

Azure Virtual Machines / VM Scale Sets

Install the OpenTelemetry Collector directly on your VMs following the official installation guide. Place your config at /etc/otel/config.yaml and run the collector as a systemd service. For VM Scale Sets, bake the collector into your image or install it via a custom-script extension or cloud-init so every instance starts the collector on boot.

Azure Container Apps

Run the OpenTelemetry Collector as its own container app and have your other apps export OTLP to it; the Collector forwards logs, metrics, and traces to Bronto over OTLP/HTTP. Alternatively, instrument each app with the OpenTelemetry SDK to export to Bronto directly.

The Container Apps environment’s built-in managed OpenTelemetry agent exports only over OTLP/gRPC, which Bronto’s ingestion endpoint does not accept — so it can’t deliver to Bronto directly. Use a Collector container or direct SDK export instead.

Azure Container Instances (ACI)

Run the collector as a sidecar container within the same container group as your application. Both containers share the group’s network namespace, so the usual defaults are localhost:4317 for OTLP/gRPC and localhost:4318 for OTLP/HTTP. Replace them when your receiver uses different port, protocol, or TLS settings. Use the standard otel/opentelemetry-collector-contrib image and provide your config via a mounted Azure Files share or a secret volume.

Collecting from Windows hosts

Windows workloads are common on Azure — VMs and VM Scale Sets, App Service on Windows plans, and Windows node pools on AKS. Windows hosts produce two distinct kinds of logs: Windows Event Log entries (collected with the windowseventlog receiver) and file-based logs such as IIS and SQL Server (collected with the filelog receiver). The same Collector you run for Linux workloads — including as an AKS DaemonSet on Windows nodes — can collect both. See Collecting Windows OS Logs for the receiver configuration, the channels worth collecting, XPath filtering for noisy channels, Windows filelog gotchas (encoding, multi-line stack traces), and installing the Collector as a Windows service.

Azure Monitor OpenTelemetry Distro

If you already use Microsoft’s Azure Monitor OpenTelemetry Distro with Application Insights, you can also forward the same logs, metrics, and traces to Bronto by adding an OTLP exporter. See the dedicated page for details.

Data Organization

Bronto maps service.name to a Dataset and service.namespace to a Collection — see Data Organization for how datasets, collections, and tags work. Set these as resource attributes in your SDK or collector config:

processors:
  resource:
    attributes:
      - key: service.name
        value: <YOUR_DATASET_NAME>
        action: upsert
      - key: service.namespace
        value: <YOUR_COLLECTION_NAME>
        action: upsert

You can also override routing per-exporter using HTTP headers, which is useful when one collector ships to multiple datasets:

Header	Description
`x-bronto-dataset`	Overrides `service.name`
`x-bronto-collection`	Overrides `service.namespace`
`x-bronto-tags`	Comma-separated tags to attach to events

exporters:
  otlphttp/bronto:
    logs_endpoint: https://ingestion.<REGION>.bronto.io/v1/logs
    headers:
      x-bronto-api-key: <YOUR_API_KEY>
      x-bronto-dataset: <YOUR_DATASET_NAME>
      x-bronto-collection: <YOUR_COLLECTION_NAME>
      x-bronto-tags: env=prod,team=platform

For Kubernetes, set x-bronto-collection to your cluster name (e.g. cluster1-prod-eu-west-1) to identify the source cluster in Bronto.

For assistance or questions, contact support@bronto.io.

Overview

Ingest with agents

Ingest from AWS

Ingest from Azure

Ingest from CDN and edge

Ingest from apps and platforms

Ingest from infrastructure and databases

Ingest OpenTelemetry data

OpenTelemetry on Azure

Choosing an Approach

Bronto Ingestion Endpoints

Self-Managed OpenTelemetry Collector

Supported sources

Collector configuration

Deployment options on Azure

Azure Kubernetes Service (AKS)

Azure Virtual Machines / VM Scale Sets

Azure Container Apps

Azure Container Instances (ACI)

Collecting from Windows hosts

Azure Monitor OpenTelemetry Distro

Data Organization

​Choosing an Approach

​Bronto Ingestion Endpoints

​Self-Managed OpenTelemetry Collector

​Supported sources

​Collector configuration

​Deployment options on Azure

​Azure Kubernetes Service (AKS)

​Azure Virtual Machines / VM Scale Sets

​Azure Container Apps

​Azure Container Instances (ACI)

​Collecting from Windows hosts

​Azure Monitor OpenTelemetry Distro

​Data Organization

Choosing an Approach

Bronto Ingestion Endpoints

Self-Managed OpenTelemetry Collector

Supported sources

Collector configuration

Deployment options on Azure

Azure Kubernetes Service (AKS)

Azure Virtual Machines / VM Scale Sets

Azure Container Apps

Azure Container Instances (ACI)

Collecting from Windows hosts

Azure Monitor OpenTelemetry Distro

Data Organization