OpenTelemetry

Ossido has built-in OpenTelemetry support. The server exports traces and logs over OTLP (http/protobuf) to any collector - Jaeger, Grafana, Honeycomb, otel-tui, and so on. There's no Ossido config for it: it's switched on at runtime with the standard OTEL_* environment variables. With none set, nothing is exported and nothing changes.

Turning it on

Point the server at an OTLP-HTTP endpoint:

OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 ossido dev

The same variable works for a production server binary - set it wherever you set the rest of the server's environment (see Building & deploying).

For a quick local collector, otel-tui shows traces and logs right in the terminal:

otel-tui &
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318 ossido dev

What you get automatically

With an endpoint set, every request is traced without any code changes:

• A server span per request, named after the matched route (for example GET /api/pokemons/{name}), with the HTTP semantic conventions. An incoming W3C traceparent header is continued, so Ossido joins traces started upstream.
• A child span per handler - page and layout handlers, #[api] routes, and #[action]s.
• Server rendering spans for each phase of SSR: ssr.queue_wait (time spent waiting for a render pool worker), ssr.render_job, ssr.v8_compile, and ssr.render.
• Logs as OTLP log records - every framework log and every logger call (and, in development, forwarded browser logs) is exported and correlated with the request's trace. Console output is unchanged: logs still print exactly as before.

Adding your own spans

Ossido re-exports the tracing crate as ossido::tracing. Spans you create there become children of the request's server and handler spans.

The span macros work with no extra dependency:

use ossido::{tracing, handler, Logger, Props, Request};

#[Props]
struct IndexProps {
    subtitle: String,
}

fn build_subtitle() -> String {
    tracing::info_span!("build_subtitle").in_scope(|| "Traced".to_string())
}

#[handler]
async fn index(_req: Request, logger: Logger) -> IndexProps {
    let subtitle = build_subtitle();
    logger.info("serving the index page");
    IndexProps { subtitle }
}

The #[tracing::instrument] attribute expands to ::tracing paths, so it needs a direct tracing dependency in your Cargo.toml:

[dependencies]
tracing = "0.1"

// Becomes a child span of the request, with `name` recorded as an attribute.
#[tracing::instrument]
fn level_for(name: &str) -> u32 {
    name.len() as u32
}

When OpenTelemetry isn't enabled, these spans cost next to nothing.

Supported variables

Configuration comes entirely from the standard OpenTelemetry environment variables:

Only the http/protobuf transport is supported. Any other OTEL_EXPORTER_OTLP_PROTOCOL value is ignored with a warning.

If your app defines an Environment struct, its .env files are loaded before telemetry starts, so the OTEL_* variables can live there too (the kitchen-sink example does this). Telemetry reads them once at startup, so changing one needs a server restart - the .env hot reload doesn't apply to them.

The telemetry feature

OpenTelemetry is compiled in behind the ossido crate's telemetry Cargo feature, which is on by default. If you never export telemetry and want to drop the dependency weight (and some compile time), turn default features off:

[dependencies]
ossido = { version = "0.1.9", default-features = false }

Without the feature, the OTEL_* variables are ignored, and ossido::tracing is still available for your own instrumentation.

Example

The with-opentelemetry example shows all of the above, and the kitchen-sink example uses it alongside a real database. Start a project from either:

ossido new my-app --template with-opentelemetry

Next: Building & deploying · Back to Tooling & developer experience