Once you have a Collector configuration file, you can run the Collector locally with Docker to test your instrumentation and verify that data is reaching Honeycomb.Documentation Index
Fetch the complete documentation index at: https://docs.honeycomb.io/llms.txt
Use this file to discover all available pages before exploring further.
Setting up and running the Collector
Follow these steps to get your Collector running and confirm data is flowing before you tune it for production.Choose your Collector image
The OpenTelemetry project publishes two Collector images.
Choose the one that matches your use case:
opentelemetry-collector-contrib: Includes a broad set of receivers, processors, and exporters from the community, including Jaeger, Prometheus, and many vendor-specific components. Use this image if you need components beyond the core set.opentelemetry-collector: The core image with a limited set of components maintained by the OpenTelemetry project. Use this image if you only need OTLP receivers and exporters and want a smaller footprint.
contrib image.Run the Collector with Docker
If your configuration file is called If you don’t need Jaeger support, you can omit
otel_collector_config.yaml in the current working directory, the following command pulls the image automatically on first run and starts the Collector with open ports for receiving OTLP data over gRPC (port 4317), HTTP (port 4318), and Jaeger Thrift HTTP (port 14268):- opentelemetry-collector-contrib image
- opentelemetry-collector core image
Run the following command to start the contrib Collector:
-p 14268:14268 from the command.For additional deployment options, including Kubernetes and binary installs, visit the OpenTelemetry Collector documentation.Verify data is reaching Honeycomb
After starting the Collector, send a test trace from your application and confirm it appears in Honeycomb.
If data does not appear within a few minutes:
- Check the Collector logs for errors.
Docker will output these to
stdout. - Confirm your API key is correct in the exporter configuration.
- Confirm your application is exporting to the correct Collector port (
4317for gRPC,4318for HTTP). - Visit Common Issues with Sending Data in Honeycomb for additional troubleshooting tips.
Handling large requests
Honeycomb enforces a 15MB request size limit. Requests that exceed this limit return an error. To keep requests within this limit, set a batch size limit and enable compression when exporting to Honeycomb.Configure maximum batch size
A Batch Processor has configuration options forsend_batch_size and send_batch_max_size.
Both options specify the number of spans, metric data points, or log records to include in each batch, but they behave differently:
send_batch_size: A soft target. The processor sends a batch when it reaches this size, but will not split data to enforce it. If a batch naturally exceeds the target, it sends as-is.send_batch_max_size: A hard cap. The processor will split data if necessary to enforce it, guaranteeing no batch exceeds this size.
send_batch_max_size.
Note that these options count data points, not bytes.
If your individual spans or metrics are large, you may need to set a lower limit than you expect.
To enforce a hard maximum batch size with no delay:
Enable compression
Collector exporters support compression for both gRPC and HTTP, which reduces request sizes and helps keep requests under the 15MB limit. Supported compression types aregzip, snappy, and zstd.
To add compression to your exporter configuration:
- HTTP exporters
- gRPC exporters