Connect OpenTelemetry Collector to Bronto

The OpenTelemetry Collector forwards logs, metrics, and traces to Bronto via OTLP/HTTP. This page covers Collector configuration only. For installation instructions, see the OpenTelemetry Collector documentation. For SDK-based instrumentation, see Bronto’s language-specific OpenTelemetry guides.

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, metrics, and traces — instrument your application with the OpenTelemetry SDK so it exports OTLP to the Collector (or directly to Bronto). See Ingest OpenTelemetry data 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 for the full list (Kubernetes, Docker, NGINX, databases, message brokers, and more), and Collecting Windows OS Logs and Metrics for Windows Event Log, IIS, and Windows performance-counter metrics.

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	Metrics endpoint	Traces endpoint
EU	`https://ingestion.eu.bronto.io/v1/logs`	`https://ingestion.eu.bronto.io/v1/metrics`	`https://ingestion.eu.bronto.io/v1/traces`
US	`https://ingestion.us.bronto.io/v1/logs`	`https://ingestion.us.bronto.io/v1/metrics`	`https://ingestion.us.bronto.io/v1/traces`

The OTel Collector uses service.name and service.namespace as shared resource identity across all three signals. For logs, Bronto also uses them to select the dataset and collection. Only the API key header is required; the rest are optional log-routing overrides:

Datasets and collections apply only to logs. Metrics appear in the Metric Explorer, and traces appear in Explore Traces. Neither signal creates a dataset or collection, and the log-routing headers below do not organize them.

Header	Required	Scope	Description
`x-bronto-api-key`	Required	All signals	Your Bronto API key.
`x-bronto-dataset`	Optional	Logs only	Overrides `service.name` as the log dataset.
`x-bronto-collection`	Optional	Logs only	Overrides `service.namespace` as the log collection.
`x-bronto-tags`	Optional	Logs only	Key-value dataset tags (e.g. `env=prod,team=platform`). See Partitions.

Logs, metrics, and traces

Run all three pipelines through a single Collector. Tail log files via the filelog receiver, accept OTLP metrics and traces from your applications via the otlp receiver, and ship each signal to its Bronto endpoint.

The example uses the standard OTLP receiver ports: 4317 for gRPC and 4318 for HTTP. Applications on the same host commonly use localhost; containers, Kubernetes workloads, remote Collectors, and TLS-enabled deployments require an address and scheme appropriate to that environment. Keep the SDK exporter and Collector receiver settings aligned.

/etc/otel/config.yaml

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:
  cumulativetodelta:
    initial_value: drop

exporters:
  otlphttp/brontologs:
    logs_endpoint: "https://ingestion.<REGION>.bronto.io/v1/logs"
    compression: gzip
    headers:
      x-bronto-api-key: <YOUR_API_KEY>
  otlphttp/brontometrics:
    metrics_endpoint: "https://ingestion.<REGION>.bronto.io/v1/metrics"
    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]
    metrics:
      receivers: [otlp]
      processors: [cumulativetodelta, batch]
      exporters: [otlphttp/brontometrics]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/brontotraces]

The service.name and service.namespace resource attributes are shared across all three signals. Bronto uses them to route logs to the correct dataset and collection; the log exporter can override them with the x-bronto-dataset and x-bronto-collection headers. For metrics and traces, the attributes remain source identity and filters, without creating datasets or collections.

Bronto supports sums, gauges, summaries, and explicit histograms. Sum and histogram metrics can be ingested as delta or cumulative, but delta is strongly recommended to get the best value from the current set of supported functions. Exponential histograms are not supported. For Sum, Summary, and Histogram metrics, the Metric Explorer provides per-second rate functions.

For signal-specific details, see Send Metrics to Bronto and Send Traces to Bronto.

Send only the signals you need

Collector pipelines are independent. To send only one signal or a subset, remove the unused signal pipelines and exporters. You do not need a separate Collector.

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 and Metrics 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 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.

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 on the logs exporter to identify the cluster (e.g. cluster1-prod-us-east-1). Bronto infers log dataset names from log resource attributes, so per-service log routing is handled automatically. Metrics and traces retain Kubernetes and service resource attributes for filtering in their respective explorers.

values.yaml

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:
    cumulativetodelta:
      initial_value: drop
    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/brontometrics:
      metrics_endpoint: "https://ingestion.<REGION>.bronto.io/v1/metrics"
      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]
        processors: [k8sattributes, batch]
        exporters: [otlphttp/brontologs]
      metrics:
        receivers: [otlp]
        processors: [k8sattributes, cumulativetodelta, batch]
        exporters: [otlphttp/brontometrics]
      traces:
        receivers: [otlp]
        processors: [k8sattributes, batch]
        exporters: [otlphttp/brontotraces]

The k8sattributes processor enriches logs, metrics, and traces with pod, namespace, and node metadata. See the OpenTelemetry Demo Kubernetes deployment guide for further context on backend configuration.

Verify delivery

Once your configuration is applied and the Collector is restarted:

Logs appear in Search.
Metrics appear in the Metric Explorer.
Traces appear in Explore Traces.

Overview

Ingest with agents

Ingest from AWS

Ingest from Azure

Ingest from CDN and edge

Ingest from apps and platforms

Ingest from Vercel

Ingest from infrastructure and databases

Ingest OpenTelemetry data

Connect OpenTelemetry Collector to Bronto

Getting your data into the Collector

Endpoints

Logs, metrics, and traces

Send only the signals you need

Windows hosts

Parsing unstructured logs

Kubernetes

Verify delivery

Further reading

​Getting your data into the Collector

​Endpoints

​Logs, metrics, and traces

​Send only the signals you need

​Windows hosts

​Parsing unstructured logs

​Kubernetes

​Verify delivery

​Further reading

Getting your data into the Collector

Endpoints

Logs, metrics, and traces

Send only the signals you need

Windows hosts

Parsing unstructured logs

Kubernetes

Verify delivery

Further reading