Instrumenting Your Application

A team takes over a service it didn't write. The scrape endpoint exists, /metrics responds, and it contains four hundred and twelve metrics: garbage collector counters, connection pool statistics, internal queue sizes from the HTTP library, certificate ages. Only one thing is missing: the number of orders that fail. No one, looking at that list, can answer the question the business has been asking for two days. The instrumentation exists, it is even abundant, and it is useless.

The opposite reflex is just as costly. Instrumenting every function "just in case" produces tens of thousands of series, a storage bill that doubles every quarter, and measurable extra latency on hot paths. Useful instrumentation is a work of selection, not exhaustiveness: a few metrics chosen to answer precise questions are worth more than everything the client library can produce by default. This lesson gives the selection criterion, how to name what you keep, and the order of magnitude of the cost you accept.

Exposing a Metrics Endpoint

In Python, the official library exposes a dedicated HTTP server or plugs into your existing application.