> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bronto.io/llms.txt
> Use this file to discover all available pages before exploring further.

# OpenTelemetry on Azure

> Send application logs and distributed traces from Azure to Bronto using a self-managed OpenTelemetry Collector or the OpenTelemetry SDK.

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.

<Info>
  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.
</Info>

## Choosing an Approach

| Approach                                                                               | Best for                                      | Notes                                                                                                                                                                                    |
| -------------------------------------------------------------------------------------- | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Self-managed OTel Collector](#self-managed-opentelemetry-collector) **(recommended)** | AKS, VMs, Container Instances, Container Apps | Sends logs and traces directly to Bronto with full control over processing, routing, and fan-out.                                                                                        |
| [OpenTelemetry SDK](/opentelemetry/overview)                                           | Any runtime (App Service, Functions, etc.)    | The vendor-neutral OpenTelemetry SDK and auto-instrumentation, exporting OTLP directly to Bronto.                                                                                        |
| [Azure Monitor OpenTelemetry Distro](./azure-monitor-otel-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](./azure-monitor-otel-distro). |

***

## Bronto Ingestion Endpoints

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

<Note>
  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.
</Note>

All requests require the header:

```
x-bronto-api-key: <YOUR_API_KEY>
```

See [API Keys](/Account-Management/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

<Info>
  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.
</Info>

### 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 and traces                                                                                                                                      |
| Azure Kubernetes Service (AKS)                  | Application logs and traces (DaemonSet or Deployment)                                                                                                            |
| Azure Container Apps                            | Application logs and traces (Collector container)                                                                                                                |
| Azure Container Instances (ACI)                 | Application logs and traces (sidecar container)                                                                                                                  |
| Any Azure workload reachable from the Collector | Logs / traces via OTLP, file, Kafka, Event Hub, and other [OTel receivers](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver) |

<Note>
  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](/opentelemetry/overview), 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](./azure-client).

  See [Ingesting Azure Data into Bronto](./azure-overview) for the full per-service source-to-method mapping, and the per-service pages — [AKS](./azure-aks), [Container Apps](./azure-container-apps), [Container Instances](./azure-aci), [App Service](./azure-app-service), [Functions](./azure-functions), [Virtual Machines](./azure-vms) — for what each service emits and how.
</Note>

### 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](/agent-setup/open-telemetry).

The minimal configuration to export both logs and traces to Bronto:

```yaml theme={"dark"}
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](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-collector):

```bash theme={"dark"}
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](/agent-setup/open-telemetry#kubernetes) 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](https://opentelemetry.io/docs/collector/installation/). 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](/opentelemetry/overview) to export to Bronto directly.

<Note>
  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.
</Note>

#### 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](./azure-windows-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](./azure-monitor-otel-distro) with Application Insights, you can also forward the same logs and traces to Bronto by adding an OTLP exporter. See the [dedicated page](./azure-monitor-otel-distro) for details.

***

## Data Organization

Bronto maps `service.name` to a **Dataset** and `service.namespace` to a **Collection** — see [Data Organization](/Search-and-Visualize/Partitions) for how datasets, collections, and tags work.

Set these as resource attributes in your SDK or collector config:

```yaml theme={"dark"}
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 |

```yaml theme={"dark"}
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](mailto:support@bronto.io).