{ resource.service.name = "checkout" && duration > 2s }Requests over the latency budget.
One service, one threshold, every trace that broke it.
Spans arrive over OTLP from the SDK you already run, or from eBPF with no code changes at all. The service graph, the critical path and the exceptions come with the trace rather than as a separate product.
Included on the free tier: 20,000 active series, 50 GB of logs and 50 GB of traces a month. No card.
What you get
| CALLER → CALLEE | RATE | P95 |
|---|---|---|
| web → checkout | 42/s | 2.14 s |
| checkout → cart | 42/s | 61 ms |
| checkout → openai | 41/s | 1.68 s |
| checkout → postgres | 84/s | 112 ms |
| checkout → payments | 39/s | 241 ms |
Computed from the spans themselves, with no service map to declare.
How it gets there
Your application knows one thing, the agent's OTLP endpoint. The agent adds the credentials on the way out.
Point your OTLP exporter at the agent on 4317 or 4318.
The agent adds the auth and tenant headers.
Traces are searchable in Insights as they arrive.
export OTEL_SERVICE_NAME=checkoutexport OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317opentelemetry-instrument python app.pyWhat you can ask
Paste any of these into Insights, or use them as an alert rule.
{ resource.service.name = "checkout" && duration > 2s }One service, one threshold, every trace that broke it.
{ status = error && span.http.route != nil }Errors on spans that carry a route, so the result groups cleanly.
{ span.db.system = "postgresql" && duration > 500ms }Database spans long enough to matter to the user.
Questions
Something not here? Talk to an engineer who works on the platform.
Book thirty minutesNone to start. eBPF gives RED metrics and server and client spans without code changes. SDK instrumentation buys span detail rather than basic coverage.
20,000 active series, 50 GB of logs and 50 GB of traces a month, 90-day retention, and the whole of Insights.