Introduction
After the installation, turn on request tracing to see, under Requests in the dashboard, every request your service handled with its route, duration, queries and outbound calls — and to open the exact request behind any error. See Request Tracing for what the dashboard shows.Enable it
lerix.tracing package is never
imported and no hook is installed. The request span itself comes from the
framework integration you already registered:
What is recorded
- One server span per request, named after the route template, never the
raw path. An incoming W3C
traceparentheader is continued. - PostgreSQL —
psycopg(3) andpsycopg2, so Django and SQLAlchemy on Postgres too. Each query becomes aclientspan named after the SQL template (SELECT * FROM users WHERE id = ?); parameters and rows are never recorded. - Outbound HTTP —
httpx(sync and async) andrequests. Each call becomes aclientspan namedMETHOD hostand carries atraceparentheader so a downstream service continues the trace. Calls to the Lerix API itself are ignored.
error if it raises. Outside a traced request
tracer.child(...) does nothing.
The current trace
awaits and task switches (it is a contextvars
variable); a thread you start by hand does not inherit it.
Sampling
Failed requests and requests that reported an error are always kept whole.
Every request’s root span is still sent, so the per-route counts and
percentiles in the dashboard cover 100% of traffic.
Errors and traces
Every error report made inside a request — the integrations’ automatic reports as well as your ownlerix.capture_exception() — carries that
request’s trace, so the issue page shows the waterfall inline with the
failing query highlighted. An error reported outside any request records as
before, with no trace attached.
Client addresses
Each request span carries the client’s address, resolved the way the project asks under Project settings → Tracing: in the defaultmasked mode the
SDK zeroes the last IPv4 octet or truncates IPv6 to its /64 before anything
is sent; in hashed and full modes the address is handled on the Lerix
side. The trusted-proxy depth and header decide how it is read from
X-Forwarded-For; the whole chain is never trusted.
Exporter options
Spans leave as OTLP/HTTP JSON from a background thread. If the Lerix API is
unreachable the batch is counted and dropped; nothing is retried, nothing
blocks a request, nothing raises into your code. Counters are on
lerix.get_client().tracing.stats().