OpenTelemetry with Sazabi

Last verified on Nov 8, 2026.

OpenTelemetry is the most direct way to get telemetry into Sazabi. The intake is OTLP/HTTP compatible, so you set an endpoint on an exporter you already have. There is no Sazabi SDK to install for this path.

Four sources, one standard

OpenTelemetry defines traces, metrics, logs and baggage as separate signals. Sazabi maps them onto four log sources:

• OpenTelemetry takes logs and traces from any SDK, sent to one intake URL.
• OpenTelemetry traces stores every span, plus a separate error record for each exception a span records.
• OpenTelemetry metrics stores each metric data point as a record with metric.name, metric.type, metric.unit and metric.value.
• OpenTelemetry Collector forwards logs and traces from a Collector pipeline.

Logs and traces arrive as separate streams. Metrics sent to the general source are not stored, which is why the metrics source exists.

What this tells you

Logs tell you what your code said happened. Traces tell you which request it happened in and how long each step took. When both carry the same trace ID, one search returns the failing span, its exception and the log lines around it. That correlation is the main reason to prefer the SDK over file scraping when you can modify the application.

Metrics sit on the other end. They are cheap summaries, good for noticing that something changed. Because Sazabi stores a metric data point as a record, you can search it next to the logs from the same service in the same thread.

Example: environment variables and a sizing check

Set these where the process starts. This is an example for a service named checkout-api:

OTEL_SERVICE_NAME=checkout-api
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_EXPORTER_OTLP_ENDPOINT=<your intake URL>

OTEL_SERVICE_NAME sets the service.name resource attribute, and that is what separates your services from each other when you count or filter. Confirm the data arrived with the CLI:

sazabi logs ask "how many log lines did each service send in the last 24 hours"

Exporters buffer in memory. The SDK batch processor holds a bounded number of records per process, with OTEL_BLRP_MAX_QUEUE_SIZE defaulting to 2048, and it drops records when the queue fills. The queue fills only when exports fall behind, for example while intake is slow. A rough way to size it is peak lines per second per process times the longest stall you want to ride out. A process that peaks at 400 lines per second and should survive a 10 second stall needs room for about 4,000 records, so raise the queue above the default.

Setup choices that trip people up

• Node.js auto-instrumentation exports traces but not logs. Add a BatchLogRecordProcessor with the OTLP log exporter yourself.
• Python needs the logging bridge. Start with opentelemetry-instrument and set OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED=true, or attach a LoggingHandler once per worker process after the fork.
• Don't run two auto-instrumentation agents in one process. Both patch the same libraries and compete for the tracer provider. If you keep an APM agent for traces, send only logs from OpenTelemetry.
• Set the variables in the running process. A build step or CI job is not enough.

The general endpoint variable is a base URL, and OpenTelemetry's HTTP exporters build the per-signal paths from it. The per-signal variables, such as the traces and metrics endpoints, are used as written.

Resource attributes decide how you filter

Every record carries the resource attributes your SDK sets, and service.name is the one you filter on most. Add deployment.environment and a version attribute through OTEL_RESOURCE_ATTRIBUTES, for example deployment.environment=production,service.version=2026.11.08. Then staging noise stays out of production queries, and after a release you can ask what changed between two versions of one service.

OTEL_SERVICE_NAME takes precedence if service.name also appears in OTEL_RESOURCE_ATTRIBUTES, so set the name in one place only. Pick service names once and keep them stable, because a renamed service looks like a new one in every search that groups by it.

Where to go next

If your services already ship to a Collector, use the Collector source and leave the application alone. If you run Vector, Fluent Bit or Grafana Alloy, compare them in telemetry pipelines. For AI workloads that emit spans, see LLM observability sources.