> ## 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.

# Connect OpenTelemetry Collector to Bronto

> Deploy the OpenTelemetry Collector with OTLP exporters to receive, process, and forward application logs and distributed traces to Bronto over HTTP or gRPC.

The OpenTelemetry Collector forwards logs and traces to Bronto via OTLP/HTTP. This page covers Collector configuration only.

For installation instructions, see the [OpenTelemetry Collector documentation](https://opentelemetry.io/docs/collector/installation/). For SDK-based instrumentation, see Bronto's [language-specific OpenTelemetry guides](/opentelemetry/overview).

## Getting your data into the Collector

The Collector only forwards the telemetry it **receives** — deploying it does not automatically discover your logs. If you've configured the Collector but aren't seeing all the logs you expect, the source usually hasn't been wired up to send data to it yet. There are two categories of source:

* **Application logs and traces** — instrument your application with the OpenTelemetry SDK so it exports OTLP to the Collector (or directly to Bronto). See [Ingest OpenTelemetry data](/opentelemetry/overview) for per-language setup. Alternatively, point the `filelog` receiver at the log files your application already writes.
* **Infrastructure and service logs** — each source has its own setup. See [Ingesting Infrastructure and Database Logs](/integrations/infrastructure-overview) for the full list (Kubernetes, Docker, NGINX, databases, message brokers, and more), and [Collecting Windows OS Logs](/integrations/azure-windows-logs) for Windows Event Log and IIS.

The receiver examples on this page show the Collector-side plumbing; the source guides above show what each source emits and where it writes its logs.

## Endpoints

Use the endpoints for your Bronto region:

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

The OTel Collector routes logs and traces to the correct dataset and collection automatically using the `service.name` and `service.namespace` resource attributes. Only the API key header is required; the rest are optional overrides:

| Header                | Required | Description                                                                                              |
| --------------------- | -------- | -------------------------------------------------------------------------------------------------------- |
| `x-bronto-api-key`    | Required | Your [Bronto API key](/Account-Management/API-Keys#create-a-new-api-key).                                |
| `x-bronto-dataset`    | Optional | Overrides `service.name` as the dataset.                                                                 |
| `x-bronto-collection` | Optional | Overrides `service.namespace` as the collection.                                                         |
| `x-bronto-tags`       | Optional | Key-value tag pairs (e.g. `env=prod,team=platform`). See [Partitions](/Search-and-Visualize/Partitions). |

## Logs and traces

Run both pipelines through a single Collector. Tail log files via the `filelog` receiver, accept OTLP traces from your applications via the `otlp` receiver, and ship each signal to its own Bronto exporter.

```yaml /etc/otel/config.yaml theme={"dark"}
receivers:
  filelog/app:
    include:
      - /path/to/your/logs
    resource:
      service.name: <YOUR_DATASET_NAME>
      service.namespace: <YOUR_COLLECTION_NAME>
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

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

service:
  pipelines:
    logs:
      receivers: [filelog/app]
      processors: [batch]
      exporters: [otlphttp/brontologs]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/brontotraces]
```

The `service.name` and `service.namespace` resource attributes are used by Bronto to route logs to the correct dataset and collection. You can override them with the `x-bronto-dataset` and `x-bronto-collection` headers.

For more on tracing — including SDK-based export — see [Send Traces to Bronto](/tracing/send-traces).

## Logs only

If you only need to forward logs, drop the OTLP receiver and traces pipeline.

```yaml /etc/otel/config.yaml theme={"dark"}
receivers:
  filelog/<DATASET_NAME>:
    include:
      - /path/to/your/logs
    resource:
      service.name: <YOUR_DATASET_NAME>
      service.namespace: <YOUR_COLLECTION_NAME>

processors:
  batch:

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

service:
  pipelines:
    logs:
      receivers: [filelog/<DATASET_NAME>]
      processors: [batch]
      exporters: [otlphttp/brontologs]
```

## Windows hosts

On Windows, the `filelog` receiver picks up file-based logs (IIS, SQL Server, application files), but most platform and service diagnostics are written to the **Windows Event Log** and need the Windows-only `windowseventlog` receiver instead. See [Collecting Windows OS Logs](/integrations/azure-windows-logs) for the receiver configuration, the event channels worth collecting, XPath filtering for noisy channels, Windows `filelog` gotchas (UTF-16 encoding, multi-line stack traces), and running the Collector as a Windows service.

## Parsing unstructured logs

Rather than building parser operators in the Collector for unstructured text, ship raw log lines to Bronto and use the [Bronto Custom Parser](/core-features/custom-parser) to extract structured fields server-side. The Custom Parser uses LLMs to generate parsers automatically and ships with built-in support for Apache, IIS, HAProxy, Syslog, key-value, and custom formats — no regex maintenance required.

## Kubernetes

For Kubernetes deployments, install the Collector using 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
```

Use the `x-bronto-collection` header to identify the cluster (e.g. `cluster1-prod-us-east-1`). Bronto infers dataset/service names from log attributes and span resources, so per-service routing is handled automatically.

```yaml values.yaml theme={"dark"}
mode: daemonset

config:
  receivers:
    filelog:
      include:
        - /var/log/pods/*/*/*.log
    otlp:
      protocols:
        grpc:
          endpoint: 0.0.0.0:4317
        http:
          endpoint: 0.0.0.0:4318

  processors:
    batch:
    k8sattributes:

  exporters:
    otlphttp/brontologs:
      logs_endpoint: "https://ingestion.<REGION>.bronto.io/v1/logs"
      compression: gzip
      headers:
        x-bronto-api-key: <YOUR_API_KEY>
        x-bronto-collection: <CLUSTER_NAME>-<ENVIRONMENT>-<REGION>
    otlphttp/brontotraces:
      traces_endpoint: "https://ingestion.<REGION>.bronto.io/v1/traces"
      compression: gzip
      headers:
        x-bronto-api-key: <YOUR_API_KEY>
        x-bronto-collection: <CLUSTER_NAME>-<ENVIRONMENT>-<REGION>

  service:
    pipelines:
      logs:
        receivers: [filelog]
        processors: [k8sattributes, batch]
        exporters: [otlphttp/brontologs]
      traces:
        receivers: [otlp]
        processors: [k8sattributes, batch]
        exporters: [otlphttp/brontotraces]
```

The `k8sattributes` processor enriches logs and traces with pod, namespace, and node metadata. See the [OpenTelemetry Demo Kubernetes deployment guide](https://opentelemetry.io/docs/demo/kubernetes-deployment/#bring-your-own-backend) for further context on backend configuration.

## Verify delivery

Once your configuration is applied and the Collector is restarted:

* Logs appear in [Search](https://app.bronto.io/search).
* Traces appear in [Explore Traces](/tracing/explore-traces).

## Further reading

* [OpenTelemetry Collector configuration](https://opentelemetry.io/docs/collector/configuration/) — full receiver/processor/exporter reference
* [OpenTelemetry Helm chart](https://github.com/open-telemetry/opentelemetry-helm-charts/tree/main/charts/opentelemetry-collector) — for Kubernetes
* [Send Traces to Bronto](/tracing/send-traces) — including direct SDK export
* [Bronto OpenTelemetry SDK guides](/opentelemetry/overview) — language-specific instrumentation
* [Bronto Custom Parser](/core-features/custom-parser) — extract structured fields from unstructured logs