> ## 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, metrics, and traces from Azure to Bronto using a self-managed OpenTelemetry Collector or the OpenTelemetry SDK.

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.

<Info>
  Exponential histograms are not supported, and the Metric Explorer does not currently provide a Rate function.
</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, metrics, 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`    |
| 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`  |

<Note>
  The `/v1/logs`, `/v1/metrics`, and `/v1/traces` endpoints accept **OTLP protobuf over HTTP only**. Exponential histograms are not supported.
</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, 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

<Info>
  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.
</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, 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](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, metrics, 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 exports logs, metrics, 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"
    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](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, metrics, and traces with pod, namespace, and node metadata. 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, metrics, 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 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](./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, metrics, 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).