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 otlphttp exporter pointed at your instance (endpoint: https://your-instance-name.sluicio.com). It must send HTTP with protobuf — the otlphttp defaults; Sluicio accepts neither gRPC nor JSON on ingest.
• 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 → Ingest keys, 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 otlphttp 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:
  otlphttp/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: [otlphttp/sluicio]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/sluicio]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/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 otlphttp (not otlp/gRPC). Your services can still talk to the Collector over gRPC — the Collector translates to HTTP on the way out. The otlphttp exporter sends protobuf by default, which is what Sluicio expects; don’t switch it to JSON (Sluicio returns 415 Unsupported Media Type).

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, filelog, hostmetrics, 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: [otlphttp/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:latest

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

• 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.