Self-Managed OpenTelemetry Collector on AWS

When to Use a Self-Managed Collector

A self-managed OpenTelemetry Collector is a good fit when you need:

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

If you want a simpler, AWS-managed setup without manual configuration, consider ADOT instead.

Application logs, metrics, and traces can be sent directly to Bronto, but routing through a Collector is strongly recommended for retries, batching, and compression.

Supported AWS Services

A self-managed Collector can run anywhere you control compute, and supports any source that has an OpenTelemetry receiver:

Service / Source	Data types
Amazon EC2	Application logs, traces, metrics, and host metrics
Amazon ECS / Fargate	Application logs, metrics, and traces (sidecar or dedicated task)
Amazon EKS	Application logs, metrics, and traces (DaemonSet or Deployment)
Any AWS workload reachable from the Collector	Logs / traces via OTLP, file, Kafka, Kinesis, Pub/Sub, and other OTel receivers

Use this method when ADOT or the Bronto-managed forwarders don’t cover your scenario. For Lambda traces specifically, the ADOT Lambda Layer is simpler.

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, or tailing its log files with the filelog receiver.
Infrastructure and database logs (web servers, proxies, databases, message brokers) each have their own Collector setup — see Ingesting Infrastructure and Database Logs.
AWS platform and service logs (CloudTrail, VPC Flow Logs, RDS, and other managed services) are exported through AWS-native forwarders, not the Collector — see Ingesting AWS Data into Bronto for the per-service source-to-method mapping.

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`

The /v1/logs, /v1/metrics, and /v1/traces endpoints accept OTLP protobuf only. Metrics ingestion is in public beta.

All requests require the header:

x-bronto-api-key: <YOUR_API_KEY>

See API Keys for how to generate a key.

Collector Configuration

The core Bronto exporter configuration is the same regardless of how you deploy the collector on AWS. For full installation instructions, platform-specific configuration, and parameter reference, see the OpenTelemetry Collector guide. The minimal configuration exports logs, metrics, 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"
    metrics_endpoint: "https://ingestion.<REGION>.bronto.io/v1/metrics"
    traces_endpoint: "https://ingestion.<REGION>.bronto.io/v1/traces"
    compression: none
    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 AWS

EC2

Install the OpenTelemetry Collector directly on your EC2 instances following the official installation guide. Place your config at /etc/otel/config.yaml and run the collector as a systemd service.

ECS (Sidecar or Daemon)

Run the collector as a sidecar container alongside each application task, or as a daemon service on each ECS instance. Use the standard otel/opentelemetry-collector-contrib image and mount your config via S3 or SSM Parameter Store.

EKS (DaemonSet or Deployment)

Deploy as a DaemonSet (one collector per node) for node-level log collection, or as a Deployment behind a ClusterIP service for centralised collection. Store your config in a ConfigMap and reference it as a volume mount.

apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-config
  namespace: monitoring
data:
  config.yaml: |
    # paste your collector config here

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:

Header	Description
`x-bronto-dataset`	Overrides `service.name`
`x-bronto-collection`	Overrides `service.namespace`
`x-bronto-tags`	Comma-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.

Overview

Ingest with agents

Ingest from AWS

Ingest from Azure

Ingest from CDN and edge

Ingest from apps and platforms

Ingest from infrastructure and databases

Ingest OpenTelemetry data

Self-Managed OpenTelemetry Collector on AWS

When to Use a Self-Managed Collector

Supported AWS Services

Bronto Ingestion Endpoints

Collector Configuration

Deployment Options on AWS

EC2

ECS (Sidecar or Daemon)

EKS (DaemonSet or Deployment)

Data Organization

​When to Use a Self-Managed Collector

​Supported AWS Services

​Bronto Ingestion Endpoints

​Collector Configuration

​Deployment Options on AWS

​EC2

​ECS (Sidecar or Daemon)

​EKS (DaemonSet or Deployment)

​Data Organization

When to Use a Self-Managed Collector

Supported AWS Services

Bronto Ingestion Endpoints

Collector Configuration

Deployment Options on AWS

EC2

ECS (Sidecar or Daemon)

EKS (DaemonSet or Deployment)

Data Organization