OpenTelemetry backend

OpenTelemetry settled how telemetry should be described. Most backends accept OTLP and then take it apart to fit a schema that predates it. Gigapipe stores what the Collector actually sent.
What OTLP-native means here
Accepting OTLP at the door is not the same as keeping it. Three things decide whether your instrumentation survives the write.

Four signals, one destination

Logs, metrics, traces and profiles all terminate in the same store. There is no fan-out to four backends, so a question that crosses signals is a join rather than a reconciliation you perform yourself.

Attributes are kept, not filtered

Resource, scope and record attributes are all stored, with no allowlist deciding which ones survive. Nested values become dotted keys rather than being discarded, so the dimension you added last week is still there to group by.

Both transports, one port

OTLP/gRPC and OTLP/HTTP are served by the same listener on the same port. There is no second endpoint to expose, no 4317-and-4318 pair to route, and no sidecar in between.

An unmodified Collector needs one exporter block and nothing else.

Every OTLP signal, both transports
Paths are the OTLP defaults, so the standard exporters resolve them without extra configuration.
Signal
OTLP/HTTP
OTLP/gRPC
Logs
POST /v1/logs
LogsService
Metrics
POST /v1/metrics
MetricsService
Traces
POST /v1/traces
TraceService
Profiles
POST /v1development/profiles
ProfilesService

Profiles sit on the development path because that is where the OpenTelemetry specification still has them. The signal is implemented on both transports; the path will move when upstream moves it.

Point a Collector at Gigapipe
A stock OpenTelemetry Collector, a standard exporter, and the host you already run. No distribution to rebuild and no plugin to install.
otel-collector-config.yaml
extensions:
  basicauth/gigapipe:
    client_auth:
      username: <user>
      password: <password>

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  # gRPC and HTTP are served on the same port, so either exporter
  # points at the same host. Swap otlphttp for otlp to use gRPC.
  otlphttp/gigapipe:
    endpoint: https://<your-gigapipe-host>:3100
    auth:
      authenticator: basicauth/gigapipe

service:
  extensions: [basicauth/gigapipe]
  pipelines:
    logs:
      receivers: [otlp]
      exporters: [otlphttp/gigapipe]
    metrics:
      receivers: [otlp]
      exporters: [otlphttp/gigapipe]
    traces:
      receivers: [otlp]
      exporters: [otlphttp/gigapipe]
See every supported agent and protocol
OpenTelemetry on Gigapipe
Which OTLP signals does Gigapipe accept?
Do I need a special exporter or a custom Collector build?
Which port does OTLP use?
Are semantic conventions and resource attributes preserved?
How do I query data that arrived over OTLP?
How is OTLP secured?
Send OTLP somewhere that keeps it.