Skip to main content
Bronto ingests OpenTelemetry logs and traces over OTLP/HTTP. On Azure, the recommended way to get this telemetry into Bronto is a self-managed OpenTelemetry Collector, which sends data straight to Bronto with full control over routing and processing. You can also instrument applications with the OpenTelemetry SDK to export directly to Bronto.
Bronto currently supports OpenTelemetry logs and traces over OTLP/HTTP. Metrics ingestion is not yet available — configure only the logs and traces signals when setting up the options below.

​
Choosing an Approach

ApproachBest forNotes
Self-managed OTel Collector (recommended)AKS, VMs, Container Instances, Container AppsSends logs and traces directly to Bronto with full control over processing, routing, and fan-out.
OpenTelemetry SDKAny runtime (App Service, Functions, etc.)The vendor-neutral OpenTelemetry SDK and auto-instrumentation, exporting OTLP directly to Bronto.
Azure Monitor OpenTelemetry DistroTeams already using Application InsightsMicrosoft’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

SignalEU RegionUS Region
Logshttps://ingestion.eu.bronto.io/v1/logshttps://ingestion.us.bronto.io/v1/logs
Traceshttps://ingestion.eu.bronto.io/v1/traceshttps://ingestion.us.bronto.io/v1/traces
The /v1/logs and /v1/traces endpoints accept OTLP protobuf over HTTP only (not OTLP/gRPC). Bronto does not yet accept OpenTelemetry metrics. OpenTelemetry SDKs and collectors handle protobuf serialisation automatically — do not send plain JSON or HTTP requests directly to these paths.
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 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 and traces can be sent directly to Bronto’s ingestion endpoints, but routing through a collector is strongly recommended. The collector handles retries on failure and batches and compresses payloads, improving reliability and reducing cost.

​
Supported sources

A self-managed Collector can run anywhere you control compute, and supports any source that has an OpenTelemetry receiver:
Service / SourceData types
Azure Virtual Machines / VM Scale SetsApplication logs and traces
Azure Kubernetes Service (AKS)Application logs and traces (DaemonSet or Deployment)
Azure Container AppsApplication logs and traces (Collector container)
Azure Container Instances (ACI)Application logs and traces (sidecar container)
Any Azure workload reachable from the CollectorLogs / traces via OTLP, file, Kafka, Event Hub, 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 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 to export both logs 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"
    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]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/bronto]
Replace <REGION> with eu or us and <YOUR_API_KEY> with your Bronto API key. Bronto does not ingest metrics, so the configuration defines only logs and traces pipelines.

​
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 and traces with pod, namespace, and node metadata, and set x-bronto-collection to the cluster name to identify the source cluster in Bronto. 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 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 app exports OTLP to localhost:4317 (gRPC) or localhost:4318 (HTTP). 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 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:
HeaderDescription
x-bronto-datasetOverrides service.name
x-bronto-collectionOverrides service.namespace
x-bronto-tagsComma-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.