Introductory guide to using time series metrics for observability, instrumentation, and monitoring across apps, infrastructure, databases, CI CD and cloud to detect issues and inform operations.
This lesson explains the role metrics play in observability, with practical analogies and concrete guidance for instrumentation and monitoring. If you’re already experienced with metrics you may skip ahead; if not, follow this introductory guide to learn why metrics are the primary “vital signs” of systems and how to use them effectively.Think of how doctors monitor health: they continuously check a few high-level numbers—temperature, blood pressure, blood sugar—to detect issues before symptoms appear.
Similarly, everyday devices capture metrics continuously: an electricity meter is a counter of consumed units, and a car dashboard displays speed, RPM, and fuel to help prevent problems before they occur.
In software systems we measure CPU cycles, memory usage, request rates, and user interactions. These time-series metrics give a quick view of system health and enable early detection—much like a dashboard helps prevent car breakdowns.Key operational questions metrics answer:
Is my app healthy right now?
Is traffic growing?
Are things degrading over time?
Is latency increasing?
Should I add more servers or CPU?
What are metrics?
Metrics are quantitative measurements captured over time and typically stored as time series (a sequence of data points indexed by time). Common examples include requests per second, memory used, CPU utilization, and response latency. Correlating multiple time-series reveals system behavior—e.g., CPU usage climbing to 75%—and points to actionable follow-up.
Metrics can be different types:
Gauges: instantaneous values like memory used or temperature.
Counters: monotonically increasing values such as total requests or error counts (good for rates and delta calculations).
Histograms/Summaries: distributions of latencies or sizes, useful for percentile calculations and SLIs.
Counters often drive alerts when growth or thresholds indicate a problem.
Metric anatomy
Use consistent naming and metadata so metrics are discoverable, aggregatable, and actionable.
Metrics across layers of the stack
Applications span multiple layers—each layer needs targeted metrics to answer operational questions. Below is a concise mapping of where to collect metrics and why.
Layer
Key metrics to collect
Why it matters
Front-end
Page load time, JS error rate, rendering times
Measures user experience and regression impact
API gateway
Request count, error rate, endpoint latency
Detects traffic issues and failing endpoints
Backend / App
DB query time, cache hit rate, request duration
Reveals internal bottlenecks and performance regressions
Infrastructure
CPU, memory, disk I/O, network throughput
Tracks resource utilization and capacity needs
When instrumenting microservices, combine service-level metrics (e.g., request durations from a Cart service) with platform-level metrics (e.g., node CPU utilization) to form a holistic view of performance and resource consumption.
Database visibility
Databases are a frequent source of latency and capacity constraints. Track metrics such as query duration, connection counts, and cache hit/miss rates to detect slow queries, connection leaks, and growing workload trends before they cause outages.
CI/CD and delivery metrics
Observability should include delivery pipelines. Useful pipeline metrics: build duration, build failure counts, deployment latency, and test coverage ratio. These metrics help track developer productivity and DORA-style indicators (deployment frequency, lead time for changes, change failure rate, MTTR).
Cloud cost and utilization metrics
In cloud environments, metrics also drive cost-awareness. Track function invocation counts, egress bytes, storage utilization, and compute cost to allocate spend by account, subscription, or project and to optimize for efficiency.
Best practices (brief)
Define clear naming conventions and consistent units.
Limit label cardinality to avoid high storage and query cost.
Collect rates from counters rather than raw counters for alerting (e.g., requests/sec).
Use histograms or summaries for latency percentiles (SLOs/SLIs).
Correlate metrics with logs and traces—metrics tell you what, logs/traces help explain why.
Summary
Metrics are time-series quantitative measurements used for real-time monitoring and trend analysis.
They are efficient at surface-level detection and alerting but rarely contain full context for root-cause analysis.
Combine metrics with logs and traces for diagnosis: metrics tell you what is happening; logs and traces explain why.
Instrument the right metrics at each layer (frontend, gateway, backend, infra, DB, CI/CD, cloud) to build a complete observability strategy.
This article provided a high-level introduction to metrics in observability. For deeper study, explore metric types, aggregation methods, label cardinality, and instrumentation best practices with tools such as OpenTelemetry, Prometheus, and vendor observability platforms.
