Application Metrics

Application metrics quantify how a backend service behaves, including request volume, latency, errors, and resource usage. They help engineers detect problems, understand service health, and investigate performance issues.

Application metrics are numerical measurements collected while a service runs. Common examples include requests per second, request duration, error count, active requests, and memory or CPU usage. Metrics are usually recorded over time so engineers can see trends and changes.

For an API, useful metrics often describe the four basic signals: traffic, latency, errors, and saturation. Traffic measures demand, latency measures how long work takes, errors measure unsuccessful operations, and saturation shows how heavily resources are being used.

Metrics can be counters, gauges, or histograms. A counter generally increases as events occur, a gauge represents a value that can rise or fall, and a histogram records observations such as request durations so distributions and percentiles can be calculated.

For a Python backend, application metrics can be emitted by instrumentation libraries and exported to a monitoring system. Good metric names and labels make the data useful, but labels should have bounded cardinality; putting values such as arbitrary user IDs into labels can create an excessive number of time series.

Key points

Interview questions

What are application metrics, and why would you collect them?

Application metrics are numerical measurements of a service's runtime behavior. Examples include request count, request latency, error count, and memory usage. They make service behavior measurable over time and can support dashboards and alerts. This helps engineers detect abnormal behavior and investigate performance problems.

What is the difference between a counter, gauge, and histogram?

A counter represents an accumulated count of events, such as completed requests or errors. A gauge represents a value that can increase or decrease, such as active connections or current memory usage. A histogram records observed values, such as request durations, into a distribution that can be used to analyze latency. Choosing the right metric type makes the resulting measurements easier to interpret.

Which metrics would you instrument on a Python HTTP API?

I would start with request volume, request duration, and error counts, broken down by stable dimensions such as HTTP method and route. I would also monitor resource-related measurements such as CPU, memory, and active requests. Latency distributions are useful because averages can hide slow tail requests. The exact set should reflect the service's operational risks and important user-facing behavior.

Why can metric label cardinality become a problem?

Each distinct label combination can create a separate time series in a metrics system. If a label contains highly variable values such as user IDs or request IDs, the number of series can grow very quickly. That increases storage, processing, and query costs and can degrade the monitoring system. Labels should therefore usually use bounded, meaningful dimensions such as route, method, or status class.