# API Analytics and OpenTelemetry Observability

> Use API analytics and OpenTelemetry traces to investigate latency, errors, throughput, operation impact, and identified client usage in Nitro.

Canonical source: https://chillicream.com/platform/analytics

Track latency, errors, and throughput for the operations your services report. When something slows down, open the related traces and inspect which calls took the time.

[Start Nitro for Free](https://nitro.chillicream.com/) [Read the analytics docs](https://chillicream.com/docs/nitro/open-telemetry/operation-monitoring)

healthywarningerror

operation · checkoutWarning

operation

mutation checkout

p99

318ms▲ 7.6×

latency / 5m

p95

42ms

throughput

1.2k/m

errors

0.3%

distributed trace · checkout7f3a·9b2e·c1 · 318ms

0ms100ms200ms318.0 ms

🌐POST /graphql318.0 ms

◈mutation checkout306.0 ms

↪users-svc · GET /me44.0 ms

↪billing · Charge204.0 ms

⚙worker · receipt.enqueue58.0 ms

⚙orders.db · INSERT38.0 ms

204ms of this 318ms request were spent in the billing service.

## OpenTelemetry-native, end to end.

Configured services export supported traces, metrics, and logs over plain OTLP. Nitro links reported operation signals to the related distributed traces for investigation.

GraphQLRESTgRPCjobDB

- Vendor-neutral OTLP in, no proprietary agent
- Hot Chocolate is auto-instrumented
- Works with any OpenTelemetry backend, not just Nitro

C#Program.cs

```
builder.Services
    .AddNitro()
    .AddOpenTelemetry();

builder.Services
    .AddGraphQLServer()
    .AddInstrumentation();
```

## What’s slow. How bad.
And for whom.

## Rank operations to investigate with the impact score.

The impact score combines traffic, latency, and error rate to help you decide which reported operations to investigate first.

### Operations

ranked by impact · last 1h

| Operation              | Avg latency | Throughput | Errors | Latency | Impact |
| ---------------------- | ----------- | ---------- | ------ | ------- | ------ |
| Qmutation checkout     | 62 ms       | 1.2k/m     | 0.3%   |         |        |
| QgRPC · Billing.Charge | 204 ms      | 610/m      | 0.4%   |         |        |
| QREST · POST /orders   | 31 ms       | 1.4k/m     | 0.0%   |         |        |
| Qmutation applyCoupon  | 16 ms       | 340/m      | 1.4%   |         |        |
| Qjob · receipt.worker  | 58 ms       | 240/m      | 0.2%   |         |        |

## The whole latency picture, not an average.

An average can look healthy while a small number of requests are much slower. Percentiles show you where the tail starts, so you can find and fix those slow paths before they affect more users.

### Latency · checkout

p95 / p99 · ms

p95p99

p99

318ms

p95

42ms

throughput

1.2k/m

error rate

0.31%

## Know which identified clients are affected.

See which client apps and versions are behind an operation. When one starts causing trouble, you can tell whether it affects everyone or only a particular client.

### Clients · checkout

share of impact

web-storefront

mobile-ios

android

## Move from a metric spike to the related traces.

## Follow one request through its reported trace.

Open the trace waterfall to inspect the services and spans that reported timing for one request, including which calls contributed the most latency.

## Inspect the trace behind a failed operation.

When errors spike, open the failing operation and inspect its traces, spans, and captured exception details without correlating logs by hand.

## The whole story, from spike to span.

Follow an incident from the latency chart to the affected operation and down to the spans behind it, without leaving Nitro.

[Start Nitro for Free](https://nitro.chillicream.com/) [Read Analytics Docs](https://chillicream.com/docs/nitro/open-telemetry/operation-monitoring)