Can open telemetry collector export data to a custom, non-OTLP HTTP(S) endpoint

[ajayparmar311]

Hello OpenTelemetry Community,

I am evaluating the OpenTelemetry Collector for a use case where I need to export telemetry data (primarily metrics, logs and traces) to a custom HTTP/S endpoint that does not speak the OTLP protocol.

My Goal:
I need to send data to a proprietary internal API endpoint (e.g., https://our-internal-api.corp.com/ingest/telemetry) which expects a specific JSON schema that does not match the OTLP format.

Is there a generic http exporter that can be configured with custom headers and body templates? (I couldn't find one in the contrib repository).

[adilburaksen]

There's no single "generic HTTP template" exporter in the standard OTel Collector distribution, but there are a few practical paths depending on how custom your schema needs to be:

Option 1: Use transformprocessor + a compatible exporter

If your target API can accept JSON that's close to an existing format, use transformprocessor to reshape the data, then send via otlphttpexporter in JSON mode. Long shot, but worth checking if your API could accept OTLP JSON format at the ingestion side.

Option 2: webhookexporter (opentelemetry-collector-contrib)

The contrib distribution has a webhookexporter (and similar) that POSTs data as JSON to an HTTP endpoint. Check: https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/webhookexporter

Option 3: Build a custom exporter with ocb (OTel Collector Builder)

For a fully custom JSON body, the recommended path is building a custom collector distribution with your own exporter using ocb:

# builder-config.yaml
exporters:
  - gomod: "go.opentelemetry.io/collector/exporter/otlpexporter v0.x.x"
  - gomod: "github.com/your-org/your-custom-exporter v0.1.0"

The OTel Go SDK exporter SDK makes this fairly straightforward — you implement Capabilities(), Start(), Shutdown(), and your specific Export*() method that does the HTTP POST with your custom JSON marshaling.

Option 4: Sidecar/proxy approach

Run a small service alongside the collector that accepts OTLP (gRPC or HTTP JSON) and transforms + forwards to your internal API. Effectively a translation layer. More ops overhead but avoids modifying the collector itself.

For a truly proprietary schema, option 3 (custom exporter via ocb) is the cleanest long-term solution. Option 2 is worth checking first if the payload format is close to what it supports.