Using Curl with OTLP over HTTP to test the Cribl OpenTelemetry Source

This article explains how to send OTLP data over HTTP to the Cribl OpenTelemetry Source using curl, how this differs from OpenTelemetry exporters, and how to troubleshoot common errors. It focuses on logs, but the same patterns apply to metrics and traces.
 

OTLP HTTP vs gRPC: Endpoints and Ports

The OpenTelemetry protocol defines different conventions for HTTP and gRPC transports:

• HTTP OTLP
  • Default OTLP HTTP port: 4318.
  • You must POST to per-signal endpoints:
    • /v1/logs
    • /v1/metrics
    • /v1/traces
  • Example base URL, port, and path:
    • http://<cribl_host>:4318/v1/logs
• gRPC OTLP
  • Default OTLP gRPC port: 4317.
  • No URL path is used (routing happens via the gRPC service/method).
     
• Please Note: On Cribl-managed Worker Groups in Cribl.Cloud, the default OTLP HTTP port 4318 is not available. Instead, choose an available Cribl.Cloud Port in the documented 20000–20010 range to configure your OTel Source.

Content-Type and Payload Encoding

The Cribl OpenTelemetry Source over HTTP expects Binary Protobuf payloads and a specific Content-Type header:

• Required header (HTTP OTLP):
  • Content-Type: application/x-protobuf
• Supported encoding:
  • Binary Protobuf-encoded OTLP messages (for example, an ExportLogsServiceRequest serialized to a .pb file so you can see data come in).
• Not currently supported:
  • JSON Protobuf (Content-Type: application/json)  
    • In an OTelCol this setting looks like encoding: json

See Supported and Unsupported Input Data in our OpenTelemetry Source documentation for the latest details.
 

How OTel Exporters Behave vs Using curl Manually for Testing

When you use OpenTelemetry SDKs or the OpenTelemetry Collector (OTelCol), most OTLP HTTP exporters handle paths and endpoints differently than a raw curl call:

• Base endpoint behavior
  • If you configure a base endpoint such as http://host:4318, most OTLP HTTP exporters will automatically append the correct per‑signal path:
    • Logs sends to → http://host:4318/v1/logs
    • Metrics sends to → http://host:4318/v1/metrics
    • Traces sends to → http://host:4318/v1/traces
• Per-signal endpoints
  • If you explicitly configure per-signal endpoints (for example, logs_endpoint or the environment variable OTEL_EXPORTER_OTLP_LOGS_ENDPOINT), that URL is used verbatim.
  • In that case, you are responsible for including /v1/logs (or /v1/metrics, /v1/traces) in the configuration URL yourself.

Using curl to test connectivity directly

• With curl, there is no OTLP HTTP Exporter to append paths for you. You must include the appropriate /v1/* path in the request URL:
  • Example: http://<cribl_host>:4318/v1/logs

Example: Sending OTLP Logs over HTTP with curl

Below is a minimal curl example for sending logs over OTLP HTTP into a Cribl OpenTelemetry Source:

curl -X POST \
'http://<cribl-host>:4318/v1/logs' \
 --header 'Content-Type: application/x-protobuf' \
 --data-binary @logs.pb

Where:

• <cribl_host> is the hostname
  • plus, the port where your Cribl OpenTelemetry Source is listening and a signal specific path
• logs.pb is a Binary Protobuf file containing an ExportLogsServiceRequest payload serialized with the OpenTelemetry Protobuf definitions.
  • if you need a logs.pb I’ve posted a python generator for one here: https://github.com/emilyashley/goat-tlp. see: curl-logs-pb

Adding HTTPS and Authorization

In production environments you will typically:

• Use HTTPS to your Cribl endpoint.
• Include an Authorization header such as:
  • Authorization: Bearer <TOKEN>

curl -X POST \
'https://<cribl_host>:4318/v1/logs' \
--header 'Content-Type: application/x-protobuf' \
--header 'Authorization: Bearer <TOKEN>' \
--data-binary @logs.pb

Configure TLS, auth, and routing to match your deployment’s requirements.

Troubleshooting Common HTTP OTLP Issues

501 errors: Unsupported Content-Type

If you see HTTP 501 responses from the OpenTelemetry Source when sending OTLP over HTTP, a common cause is an unsupported Content-Type header:

• The Source expects Content-Type: application/x-protobuf for OTLP over HTTP.
• If another content-type (for example, application/json) is sent, the Source may return HTTP 501 and log a message similar to: "dropping request because of unsupported Content-Type".

Fix: Ensure your HTTP client or exporter is configured to send Binary Protobuf with Content-Type: application/x-protobuf
 

400 errors: OTLP version and path mismatch

If you see HTTP 400 responses, especially when sending directly to a /v1/logs endpoint, check the OTLP version configured on the Cribl OpenTelemetry Source:

• If the Source is configured for 0.10.0 but receives traffic directed at the logs endpoint ( /v1/logs), it may return HTTP 400 and log a message similar to: "Dropping request because of unallowed path"
• Why? 0.10.0 is an OTLP version prior to when the logs spec was marked stable.

To successfully receive and (optionally) extract logs sent to /v1/logs:

• Configure the OpenTelemetry Source to use 1.3.1 for logs.
• Then re-send your OTLP HTTP traffic to /v1/logs with the appropriate binary Protobuf payload and Content-Type: application/x-protobufheader.

See Configure an OTel Source for details on the OTLP version setting.

TLDR; Quick Checklist

Use this checklist when testing or debugging OTLP over HTTP into the Cribl OpenTelemetry Source:

• Using HTTP directly (e.g., curl to test connectivity?)
  • Use port 4318  - unless you have configured another port or are on a Cribl-managed Worker Group in Cribl.Cloud using ports in the documented range.
  • POST to the correct per‑signal path:
    • /v1/logs, /v1/metrics, or /v1/traces.
  • Set Content-Type: application/x-protobuf.
  • Send a binary Protobuf OTLP payload (e.g., an ExportLogsServiceRequest ).
• Using the OTel Collector / SDKs
  • HTTP:
    • Configure a base endpoint (for example, http://host:4318) and let the exporter do the work appending /v1/logs, /v1/metrics, /v1/traces for you or:
    • If your configuration declares per-signal endpoints  (logs, metrics, traces), ensure each URL includes the correct /v1/* path.
  • gRPC:
    • Connect to port 4317.
    • Do not include an HTTP signal specific path; gRPC routing is handled by the service/method.
• Still seeing issues?
  • Check the OTLP version configured on the OpenTelemetry Source (for example, adjust to 1.3.1 when sending to logs endpoint).
  • Review debug logs for messages related to unsupported Content-Type or unallowed path to pinpoint misconfigurations.

This reference should give you a fast, repeatable way to validate OTLP over HTTP traffic into your Cribl OpenTelemetry Source, whether you're testing with curl or wiring up full OpenTelemetry pipelines.