A production API can become slow or start returning unexpected errors before anyone reports a problem. Monitoring gives the team a way to detect known conditions: collect predefined measurements, display them on dashboards, and trigger alerts when preset rules are met. Sharing production metrics with developers supports a continuing cycle of diagnosis and improvement. section 11.2 section 1.2
Separate measurements by what they describe:
- Infrastructure metrics describe the components an API runs on, including CPU, memory, disk I/O, queues, network usage, and database connections. section 11.2
- Service-level metrics describe the API’s health, including latency, error rate, throughput, and uptime. section 11.2
Choose a focused set of measurements rather than collecting metrics without a strategy. For a microservice API, the RED method focuses attention on request rate, error rate, and duration. Set alert rules for conditions that warrant attention, such as multiple 5xx responses, a traffic spike, or rising latency; notifications can go to SMS, Slack, or PagerDuty. section 11.2 section 11.2.4
Check the API before a consumer reports a failure
Run synthetic checks at regular intervals to simulate common interactions, such as authentication followed by API requests. Checks from different geographic locations can test availability and performance from more than one vantage point. A failed check or triggered alert prompts investigation; neither alone identifies every possible root cause. section 11.2.4 section 1.2
Monitoring is strongest when the condition and measurement are known in advance. Observability complements it by querying instrumented systems to investigate problems that were not anticipated. API product analytics answers a different question: how API usage and consumer experience relate to product goals. section 1.2 section 11.0
