Osuite concepts

OTLP

Osuite ingests all telemetry over the OpenTelemetry Protocol (OTLP) — the vendor-neutral wire format defined by OpenTelemetry. There are no proprietary agents and no Osuite-specific SDKs: anything that speaks OTLP can send to Osuite.

OTLP is carried two ways, and Osuite accepts both — gRPC and HTTP/protobuf — on the same port, 443.

Whichever transport you use, telemetry is sent to your regional ingest endpoint, ingest.<region>.osuite.io:443, authenticated with your ingest token. See Architecture for the full path.

The three signals

OpenTelemetry models observability data as three signals. Osuite stores and correlates all three.

Signal	What it is	Where it appears in Osuite
Traces	A trace follows one request across every service it touches. Each unit of work is a span, with a duration, attributes, and a parent.	APM & Tracing
Logs	Timestamped records emitted by your application or infrastructure, structured or plain text.	Logs
Metrics	Numeric measurements sampled over time — counters, gauges, and histograms.	Dashboards → Explore metrics

Each signal carries a resource — a set of attributes describing where it came from (service.name, host, Kubernetes pod, and so on). The resource is what lets Osuite tie the signals back together.

The correlation model

Signals in Osuite are correlated by design, not stitched together after the fact. Two mechanisms make this work:

• Shared resource attributes. Traces, logs, and metrics from the same service, host, or pod carry the same resource attributes, so Osuite groups them under one entity. A degraded service in APM links straight to the host metrics beneath it.
• Trace and span IDs. When a log record is emitted inside a traced request, it carries the active trace_id and span_id. From any span you can jump to the exact log lines it produced, and from any log line you can open the trace that emitted it — no manual timestamp matching.

The result is a single thread from a frontend event, through the request trace, to the logs and the infrastructure metrics involved — the context the Investigation Agent uses to locate a root cause.

The service.environment attribute

service.environment is the resource attribute Osuite uses to separate environments. Set it to a value such as prod, staging, or dev, and Osuite groups and filters all telemetry — traces, logs, and metrics — by that environment.

OTEL_RESOURCE_ATTRIBUTES="service.environment=prod"

Two things to know:

• It is required. Telemetry without service.environment is not grouped into an environment. Set it on every service.
• It is Osuite-specific. Use this key, not the standard OpenTelemetry deployment.environment. Osuite reads service.environment.

For the complete list of resource attributes Osuite recognises, see the resource attributes reference.