Point the OpenTelemetry Collector at Sluicio

Sluicio receives telemetry as OTLP over HTTP. If you already run an OpenTelemetry Collector — or want one in front of your services — you point its exporter at Sluicio’s ingest endpoint and authenticate with an ingest key. Nothing Sluicio-specific is required in your apps; they keep sending OTLP to the Collector as usual.

The minimum

Sluicio needs just three things from a Collector:

• An ingest key for your organisation — minted in the app or via the API.
• An otlp_http exporter pointed at your instance (endpoint: https://your-instance-name.sluicio.com). It must send HTTP with protobuf, the exporter’s defaults; Sluicio accepts neither gRPC nor JSON on ingest. (On a Collector older than v0.144.0 the same exporter is called otlphttp.)
• The key in the authorization header on that exporter — Bearer <ingest-key>.

Wire your traces / metrics / logs pipelines to that exporter and telemetry flows. Everything below is the detail behind these three.

1 · Get an ingest key

Ingest keys are per-organisation and minted by an admin.

• In the app: open Settings → Ingestion, create a key, and copy it. The full value is shown once — store it somewhere safe (a secret manager or the Collector host’s environment).
• Via the API: POST /api/v1/ingest-keys (admin session) returns the key once; GET /api/v1/ingest-keys lists them; DELETE /api/v1/ingest-keys/{id} revokes one.

Treat it like a password

Anyone with the key can write telemetry into your organisation. Keep it out of source control — inject it as an environment variable (below), and revoke + reissue if it leaks.

2 · Configure the Collector

Add an otlp_http exporter pointing at your Sluicio instance URL, and send each signal’s pipeline to it. The key comes from the environment, so it never lives in the file.

otel-collector-config.yaml

receivers:
  otlp:
    protocols:
      grpc:        # your services can send to the Collector over gRPC…
      http:        # …or HTTP — both are forwarded to Sluicio over HTTP

processors:
  batch:           # batch before export — easier on the network and on ingest

exporters:
  otlp_http/sluicio:
    endpoint: https://your-instance-name.sluicio.com   # ← your Sluicio instance URL
    compression: gzip
    headers:
      authorization: "Bearer ${env:SLUICIO_INGEST_KEY}"

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

Replace your-instance-name.sluicio.com with your own Sluicio instance host — the URL you sign in to.

Use the HTTP exporter, not gRPC

Sluicio’s ingest speaks OTLP/HTTP only. Export to it with otlp_http (not otlp, which is gRPC). Your services can still talk to the Collector over gRPC - the Collector translates to HTTP on the way out. The otlp_http exporter sends protobuf by default, which is what Sluicio expects; don’t switch it to JSON (Sluicio returns 415 Unsupported Media Type).

The exporter was renamed in Collector v0.144.0: before it, the type is otlphttp, and the config is otherwise the same. The command below pins v0.157.0.

The exporter appends the standard OTLP paths automatically, so endpoint: https://your-instance-name.sluicio.com becomes …/v1/traces, …/v1/metrics and …/v1/logs.

Give every source a service name

Sluicio groups everything — traces, metrics, logs, health and alerts — by the OTLP service.name resource attribute. If it’s missing, that telemetry lands under unknown_service and can’t be told apart from anything else, so make sure every source sets one.

• App-instrumented telemetry already carries it: the SDK sets service.name from OTEL_SERVICE_NAME (or OTEL_RESOURCE_ATTRIBUTES=service.name=…). The Collector just forwards it — nothing to add here.
• Collector-only sources - scraped metrics, file_log, host_metrics, a broker receiver - have no SDK to set it. Add a resource processor and put it on those pipelines:

otel-collector-config.yaml

processors:
  resource/rabbitmq:
    attributes:
      - key: service.name
        value: rabbitmq        # ← how this source appears in Sluicio
        action: upsert

service:
  pipelines:
    metrics/rabbitmq:
      receivers: [prometheus]
      processors: [resource/rabbitmq, batch]   # set the name before export
      exporters: [otlp_http/sluicio]

Give each Collector-only source its own named resource processor so each shows up as a distinct service rather than collapsing into one.

3 · Run the Collector

export SLUICIO_INGEST_KEY="<the key you copied>"

docker run --rm \
  -v "$(pwd)/otel-collector-config.yaml:/etc/otelcol-contrib/config.yaml" \
  -e SLUICIO_INGEST_KEY \
  -p 4317:4317 -p 4318:4318 \
  otel/opentelemetry-collector-contrib:0.157.0

Ports 4317 (gRPC) and 4318 (HTTP) are where your services send their telemetry to the Collector.

4 · Verify

Send some traffic through an instrumented service, then open Sluicio — the service and its traces appear within a few seconds.

If nothing shows up, check the Collector’s logs for the exporter response:

Response from Sluicio	Meaning
200	Accepted — telemetry is flowing.
401	Missing or invalid ingest key — check the authorization header / SLUICIO_INGEST_KEY.
415	Body isn’t protobuf — don’t set the exporter to JSON encoding.
connection refused / TLS error	Wrong endpoint host, or the instance isn’t reachable.

Authentication header reference

Either header works — Authorization is the OTLP-idiomatic one used above:

Authorization: Bearer <ingest-key>
# or
X-Sluicio-Ingest-Key: <ingest-key>

Where to go next

• Monitoring with the OpenTelemetry Collector — the end-to-end setup: install a Collector, scrape your infrastructure (Kafka, RabbitMQ, …), and monitor the Collector itself.
• Instrument a service — emit OTLP from your apps (Java, .NET, JavaScript) so the Collector has something to forward.
• Track RabbitMQ queue depth and consumer lag — a Collector-only integration that needs no app code.