What is OTLP and why it matters for monitoring

If you've set up monitoring in the past few years you've probably seen "OTLP" in documentation. It stands for OpenTelemetry Protocol — a wire format for transmitting telemetry data (metrics, traces, and logs) between agents, collectors, and backends.

The problem OTLP solves

Before OpenTelemetry, every observability vendor had its own agent, its own protocol, and its own data format. Switching from Datadog to Grafana meant ripping out one agent and installing another, rewriting dashboards, and converting historical data.

OpenTelemetry is a CNCF project that standardises:

• The data model — how metrics, traces and logs are structured
• The wire protocol — how that data is transmitted (OTLP)
• The SDK — how instrumentation is added to application code

If your agent speaks OTLP, it can send data to any backend that also speaks OTLP: Grafana, Datadog, Honeycomb, Lightstep, Jaeger, your own self-hosted collector. One agent, any backend.

How OTLP works

OTLP has two transport options:

OTLP/gRPC — the default. Uses Protocol Buffers over HTTP/2 with TLS. Efficient binary encoding, multiplexing, and bidirectional streaming. OxiPulse uses this transport.

OTLP/HTTP — uses JSON or Protobuf over HTTP/1.1 or HTTP/2. Easier to debug with tools like curl, but less efficient for high-frequency metric export.

A typical OTLP export looks like this:

ExportMetricsServiceRequest
  └── ResourceMetrics
        ├── Resource (attributes: service.name, service.version, host.name)
        └── ScopeMetrics
              └── Metric[]
                    ├── name: "system.cpu.usage"
                    ├── unit: "%"
                    └── Gauge
                          └── DataPoint { value: 12.4, timestamp: ... }

The Resource section carries attributes that describe the source — in OxiPulse's case, the agent version and identifier. The Metric section carries the actual measurements.

Resource attributes in OxiPulse

OxiPulse attaches the following resource attributes to every export:

These attributes allow the ingestor to track which version of the agent is running on each host without any additional configuration.

The OpenTelemetry Collector

The OpenTelemetry Collector is a standalone process that receives OTLP data, applies transforms, and exports to one or more backends. It acts as a fan-out router:

OxiPulse → Collector → Prometheus
                     → Datadog
                     → S3 (for archiving)

You don't need the Collector if your backend accepts OTLP directly (SecuryBlack's ingestor does, as does Grafana Cloud).

Why OxiPulse chose OTLP

We wanted OxiPulse to be genuinely vendor-neutral. If we had built a custom protocol, every backend would need a custom integration and every user would be coupled to our infrastructure.

OTLP means that OxiPulse is useful even if you never create a SecuryBlack account. Point it at your own OpenTelemetry Collector and use whatever storage and visualisation tools you already have.