Instrument one endpoint group with metrics and spans
A group of endpoints with no latency or error data, instrumented with a dashboard query included.
The ticket
Add metrics and tracing spans to one endpoint group.
Acceptance criteria
- Each endpoint reports latency, throughput, and error rate
- Span names follow a convention and are asserted in tests
- Cardinality is bounded, with no unbounded identifiers as labels
- A dashboard query using the new signals is included
What lands as proof
A dashboard query returning real data from the new instrumentation, not just the instrumentation code.
Why teams defer it
- Instrumentation is invisible until it is missing, and by then the outage is already underway.
- A careless label explodes cardinality and the bill, so it needs somebody who knows the metrics backend.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: add metrics and tracing spans to one endpoint group. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means span names asserted in tests, dashboard query included, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops once the plan is written. Somebody reads the approach and approves it before any code exists, which is the cheapest moment to redirect the work.