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
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:
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
filelogreceiver. - 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
The
/v1/logs, /v1/metrics, and /v1/traces endpoints accept OTLP protobuf only.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:<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 standardotel/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.Data Organization
Bronto mapsservice.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:
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.

