Overview
APM (Application Performance Monitoring) and Distributed Tracing are two views of the same underlying trace data. APM gives you the aggregate picture across all your services, and tracing lets you drill into a single request.
Both are powered by OpenTelemetry, which means zero vendor lock-in and auto-instrumentation for most popular frameworks.
APM: the aggregate view
The APM section in Osuite shows every service that has sent at least one trace. For each service you get:
Golden signals
The three metrics that matter most in production:
| Signal | What it tells you |
|---|---|
| Request rate | How much traffic the service is handling (requests per second) |
| Error rate | The percentage of requests that return an error |
| Latency | How long requests take to complete (p50, p90, p95, p99) |
Osuite calculates these automatically from incoming spans — no custom instrumentation required.
Service dependency map
The dependency map is a live graph of every service-to-service call in your system. Each edge shows the request rate, error rate, and latency between two services. When an incident occurs, the map immediately shows you which dependency is degraded and what its blast radius looks like.
Bottleneck detection
Within each service, Osuite surfaces the slowest endpoints by p99 latency. You can drill from the service list → endpoint list → individual traces with a single click, going from “something is slow” to “this specific database query on line 47” without leaving the platform.
Error tracking
Errors are grouped by exception type and stack trace fingerprint. You can see how frequently each error occurs, which endpoint it comes from, and whether it is trending up or down. Each error group links directly to example traces for immediate context.
Distributed Tracing: the per-request view
A trace is a record of everything that happened during a single request as it traveled across your services. Each unit of work within a trace is called a span.
Trace views
Osuite provides three ways to visualise a trace:
Waterfall view shows the full timeline of a request — every span laid out chronologically with its duration, parent-child relationships, and status. This is the fastest way to see where time is spent and whether calls are sequential or parallel.
Flamegraph view aggregates spans by operation name. Where the waterfall shows one request in detail, the flamegraph shows patterns across many, making it easy to identify hot paths in deep call stacks.
Span list is a flat table of all spans in a trace. Use it to inspect attributes, find spans by operation name, or export raw span data.
Span attributes
Every span carries attributes that provide context:
service.name— which service produced this spanhttp.method,http.url,http.status_code— for HTTP callsdb.system,db.statement— for database queriesrpc.service,rpc.method— for gRPC calls- Custom attributes you add in your own code
Trace-to-log correlation
If your application emits logs through the same OTel SDK, Osuite automatically links them to their trace using trace_id and span_id. You can see all the related logs right there in the trace view.
Ingestion Pipeline and tail-based sampling
By default, Osuite ingests every trace. As your volume grows, the Ingestion Pipeline lets you configure tail-based sampling — a sampling strategy that makes the keep/drop decision after a trace is complete.
This is important because tail-based sampling lets you keep 100% of error traces and slow traces while dropping routine healthy ones. You never lose the traces that matter, and you keep ingestion costs predictable.
Sampling rules are configured per service.
Instrumentation guides
Use Osuite instumentation agent to automatically instrument your code. It will figure out which libraries are installed in your application and will instument them automatically. You can find it in the Osuite Instrumentation Agent section.