Metric
A number measured over and over with a timestamp, so you can graph it: requests per second, memory used, errors per minute.
See it
What it is
A metric is one number, sampled over and over with a timestamp: requests per second, memory in use, checkout failures per minute. Each sample is tiny, so you can keep years of them and chart, compare, and alert on them cheaply. That is the trade: metrics are aggregate, so they tell you what changed and roughly when, but never which specific user hit it. Logs and traces answer the why.
Three shapes cover almost everything. A counter only goes up (total requests, total errors) and you chart its rate. A gauge goes up and down (queue depth, connected sockets, temperature). A histogram buckets a distribution so you can pull percentiles out of it (request duration). Metrics carry labels, a route of '/checkout' or a status of '500', which is how you slice one number into many lines on a chart.
Gotcha: labels are where the bill lives. Every unique combination of label values creates a separate stored series, so tagging a metric with 'user_id' or a raw URL turns one metric into millions and takes the cost (and often the query speed) with it. Keep label values to a small known set, and put the unbounded stuff in structured logs instead.
Ask AI for it
Instrument this service with Prometheus-style metrics and expose them on a /metrics endpoint: a counter for total handled requests, a counter for errors, a gauge for in-flight requests and queue depth, and a histogram for request duration in seconds with buckets tuned to this app's expected latency. Label every metric with route, method, and status class only. Do not add user id, session id, or full URL as labels, because unbounded label values blow up cardinality. Then give me a starter dashboard with request rate, error rate, and p95 duration.