Skip to main content

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.

Receivers are the entry point for telemetry data into the Collector pipeline. They define how the Collector accepts data: which protocols it listens on, which ports it binds to, and which formats it understands. Every Collector pipeline requires at least one receiver.

​
OTLP receiver

The OTLP receiver is the standard receiver for applications instrumented with OpenTelemetry SDKs. It accepts telemetry over both gRPC and HTTP, covering all three signal types — traces, metrics, and logs — without additional configuration.

​
Supported signals

The OTLP receiver supports traces, metrics, and logs.

​
Basic configuration

Configure the OTLP receiver to listen on the standard ports for gRPC and HTTP. Include it in every pipeline that receives application telemetry: 
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp_http]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp_http]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp_http]

​
Browser telemetry

Browser applications cannot send telemetry directly to the Collector without CORS configuration. The allowed_origins property tells the Collector which browser origins to accept requests from, allowing your web application to send traces to the Collector without being blocked by the browser’s same-origin policy. The Collector also needs to be accessible by the browser — Honeycomb recommends placing a load balancer in front of the Collector and configuring it to accept requests from your browser origin. 
receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318
        cors:
          allowed_origins:
            - "http://*.<yourdomain>.com"
            - "https://*.<yourdomain>.com"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp_http]
For more configuration options, visit the Collector GitHub repository. For full browser instrumentation setup, visit Browser JavaScript.

​
Legacy receivers

If your application is already instrumented with a legacy observability framework, the Collector can receive that telemetry and convert it to OTLP before forwarding to Honeycomb. This lets you send data to Honeycomb without re-instrumenting your application.

​
Jaeger receiver

The Jaeger receiver accepts trace data in Jaeger’s Thrift HTTP format on port 14268. Use it when your application is instrumented with the Jaeger client library: 
receivers:
  jaeger:
    protocols:
      thrift_http:
        endpoint: "0.0.0.0:14268"

service:
  pipelines:
    traces:
      receivers: [jaeger]
      processors: [batch]
      exporters: [otlp_http]

​
Zipkin receiver

The Zipkin receiver accepts trace data in Zipkin’s JSON or Thrift formats. Use it when your application is instrumented with the Zipkin client library. Visit the Zipkin receiver documentation for configuration options.

​
Infrastructure receivers

Receivers for infrastructure sources — including host metrics, Kubernetes cluster metrics, file logs, and Prometheus scraping — are covered in Instrument Infrastructure. Those receivers are typically deployed in Agent or Gateway mode alongside your infrastructure rather than your application code. For the full list of available receivers, visit the OpenTelemetry Collector receiver documentation.

​
Receivers

Add receivers for OTLP trace output from applications instrumented with OpenTelemetry: 
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  otlp_http:
    endpoint: "https://api.honeycomb.io:443" # US instance
    #endpoint: "https://api.eu1.honeycomb.io:443" # EU instance
    headers:
      "x-honeycomb-team": "YOUR_API_KEY"
  otlp_http/metrics:
    endpoint: "https://api.honeycomb.io:443" # US instance
    #endpoint: "https://api.eu1.honeycomb.io:443" # EU instance
    headers:
      "x-honeycomb-team": "YOUR_API_KEY"
      "x-honeycomb-dataset": "YOUR_METRICS_DATASET"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp_http]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp_http/metrics]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp_http]

​
Using gRPC Instead of HTTP/protobuf

The otlp_http exporter uses the HTTP/protobuf protocol to send telemetry data. To use gRPC instead of HTTP/protobuf, use the otlp_grpc exporter, update the endpoint, and update the pipeline: 
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

exporters:
  otlp_grpc:
    endpoint: "api.honeycomb.io:443" # US instance
    #endpoint: "api.eu1.honeycomb.io:443" # EU instance
    headers:
      "x-honeycomb-team": "YOUR_API_KEY"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: []
      exporters: [otlp_grpc]

​
Choosing between gRPC and HTTP

Most OpenTelemetry SDKs have an option to export telemetry as OTLP either over gRPC or HTTP/protobuf, with some also offering HTTP/JSON. If you are trying to choose between gRPC and HTTP, keep in mind:
  • Some SDKs default to using gRPC, and it may be easiest to start with the default option.
  • Some firewall policies are not set up to handle gRPC and require using HTTP.
  • gRPC may improve performance, but its long-lived connections may cause problems with load balancing, especially when using Refinery.
gRPC default export uses port 4317, whereas HTTP default export uses port 4318.