A request crosses three services and you need to see where the latency sits. What do you instrument?
Why C is the answer
Distributed tracing with OpenTelemetry SDKs
Tracing follows one request across services and shows the time in each. Scaling up before measuring is guessing.
In detail
- Distributed tracing follows one request across services.
- It shows where time is spent.
- Pass trace context between services.
Use case
An illustrative scenario, not a real incident.
A request crosses an API, a worker and a database, and it is slow. Distributed tracing shows that most of the time is in the worker.
See it in different ways
flowchart LR A["API"] --> B["Worker"] B --> C["Database"] A --> D["Application Insights"] B --> D C --> D
sequenceDiagram participant A as Service A participant B as Service B participant C as Service C participant M as Application Insights A->>B: Request, with trace context B->>C: Request, with trace context A->>M: Spans B->>M: Spans C->>M: Spans
sequenceDiagram participant P0 as API participant P1 as Worker participant P2 as Database P0->>P1: Request with trace context P1->>P2: Query P2-->>P1: Result P1-->>P0: Response
Key point: Tracing shows where latency sits.
Why the other options are wrong
- A. A bigger App Service plan so the slow service has more room
- More capacity is a guess until you find the slow service.
- B. A daily log export that you can compare in a spreadsheet
- Spreadsheet comparison is slow, and it cannot link one request.
- D. Key Vault rotation to rule out expired credentials
- Credentials do not explain latency in each service.