Metrics Quickstart Guide 2026: From Code to Dashboard

This metrics quickstart guide covers the essential vocabulary and concepts you need to start instrumenting any application, with special attention to serverless and edge environments. You will learn the four core metric types (counter, gauge, histogram, summary), how metrics are collected and structured, and which frameworks help you decide what to measure. If you want to skip straight to code, the Distlang Metrics quickstart gets you from zero to dashboard in minutes.

Why You Need a Metrics Quickstart Guide

Someone just told you to “add metrics to this service.” You open a browser, search around, and find yourself drowning in Prometheus documentation, OpenTelemetry specs, and vendor-specific tutorials that each assume you already know the other two. The terminology is scattered across ecosystems, and every guide seems to start in the middle.

This metrics quickstart guide collects the core concepts in one place. It defines every term you will encounter in your first week of instrumentation, explains when each one matters, and points you toward working code. Whether you are brand new to observability or an experienced developer picking up an unfamiliar tool, the goal is the same: get oriented fast, then get building.

The guide pays particular attention to serverless and edge runtimes. Traditional monitoring vocabulary was built for long-running servers with persistent endpoints. If you are deploying to Cloudflare Workers or Vercel, some of those assumptions break down. The terms and patterns covered here account for that.

What Is a Metric?

A metric is a numerical measurement captured at a point in time. That is the entire concept at its core. Your application records a number, attaches a timestamp, and sends it somewhere for storage and visualization.

Metrics generally fall into three categories:

• Resource metrics track infrastructure: CPU usage, memory consumption, disk I/O.

• Application metrics track software behavior: request counts, error rates, response times.

• Business metrics track outcomes: signups, purchases, conversion rates.

Every individual metric has four elements: a name (what you are measuring), labels (dimensions that describe it), a value (the number), and a timestamp (when it was recorded). Understanding this structure is the foundation for everything else in this quickstart guide for metrics.

If you want to jump straight into code, the Distlang Metrics quickstart documentation walks through a working example in under five minutes.

Metric Types

These four types form the universal vocabulary of metrics. Prometheus established the naming convention, and OpenTelemetry adopted the same core concepts with minor variations. Regardless of which tool you use, you will encounter these types everywhere.

Counter

A counter is a cumulative value that only goes up. Prometheus defines it as “a metric that represents a single monotonically increasing counter whose value can only increase or be reset to zero on restart.” OpenTelemetry puts it more simply: think of an odometer on a car. It never runs backwards.

Use a counter when you need to track totals over time: HTTP requests served, errors logged, jobs completed, bytes transferred.

Practical tip: Pierre Zemb, who writes about observability on his practitioner blog, observes that most developers remember to count successful operations but forget the error paths. Always instrument both success and failure counters. You will be blind when things break if you only track the happy path.

Counters become useful through rates. A raw count of “50,000 requests” means nothing without context. A rate of “500 requests per second, up from 200 an hour ago” tells a story.

Gauge

A gauge is a snapshot of a value right now. Unlike a counter, it can go up or down freely. Prometheus describes it as “a metric that represents a single numerical value that can arbitrarily go up and down.”

Use a gauge when you need to know current state: memory usage, active database connections, items in a queue, temperature of a server room.

The key distinction from a counter: if you miss a gauge reading, you have a gap in your data but no lasting confusion. If you miss counter increments, your totals are permanently wrong. Gauges are forgiving. Counters require reliable delivery.

Histogram

A histogram records observations (typically durations or sizes) by sorting them into configurable buckets. Prometheus uses cumulative buckets with the le (less-or-equal) label. A bucket labeled le="0.005" counts all observations that took 5ms or less.

Use a histogram when you need to answer distribution questions: “What percentage of requests complete in under 200ms?” or “What is the 95th percentile response time?” Averages hide outliers. Histograms reveal them.

Histograms are the right choice for request latency, response body sizes, and any measurement where the shape of the distribution matters more than a single number. If you are working with the Distlang JavaScript metrics client, counters and histograms are the two supported instrument kinds, which covers the vast majority of use cases.

Summary

A summary computes quantiles (like the median or 99th percentile) on the client side before sending data. This is a Prometheus-specific type, and modern guidance generally favors histograms over summaries. The reason: summaries cannot be meaningfully aggregated across multiple instances. If you have ten replicas of a service, you cannot combine their summaries into a meaningful global view. Histograms can be aggregated. Choose histograms unless you have a specific reason not to.

Anatomy of a Metric

Understanding the structure of a metric is just as important as knowing the types. This section of the metrics quickstart guide covers the building blocks that appear in every observability system.

Metric Name

Names should be descriptive and follow a consistent convention. The widely adopted pattern uses a prefix (your app or subsystem), a description of what is measured, and a unit suffix: http_requests_total, api_response_seconds, queue_depth_current.

Counters conventionally end in _total. Including the unit in the name (_seconds, _bytes) prevents confusion when someone reads a dashboard months later.

Labels and Attributes

Labels are key-value pairs that add dimensions to a metric. A single metric name can describe many things depending on its labels:

http_requests_total{method="GET", status="200", endpoint="/api/users"}
http_requests_total{method="POST", status="500", endpoint="/api/orders"}

Labels are powerful and dangerous. Each unique combination of label values creates a separate time series.

Cardinality

Cardinality is the total number of unique time series produced by a metric. The formula is simple multiplication: unique values of Label 1 × unique values of Label 2 × unique values of Label N. A metric tracking HTTP requests across 20 endpoints, 5 services, and 300 VMs can create roughly 30,000 unique time series.

High-cardinality labels (user IDs, IP addresses, raw URLs, phone numbers) can blow this number into millions. That slows down your monitoring system, increases storage costs, and makes queries unusable. Keep label values bounded. Use categories, not identifiers.

Time Series

A time series is the sequence of values for one specific combination of metric name and labels over time. DigitalOcean defines it as “a series of data points that represent changes over time.” Every unique name-plus-labels combination is a separate time series.

Metric Set

Some platforms (including Distlang Metrics) use the concept of a metric set to group related metrics for a single application or service. Think of it as a namespace. You might have metric sets named api-gateway, checkout-service, or edge-cache. Stable, descriptive naming for metric sets makes dashboards and alerts easier to manage as your system grows.

How Metrics Are Collected

The path from “my code recorded a number” to “I can see it on a dashboard” involves a collection mechanism. This is where serverless environments diverge sharply from traditional infrastructure.

Pull Model

In the pull model (Prometheus-style), a central collector scrapes metric endpoints on a schedule. Your application exposes an HTTP endpoint (typically /metrics), and the collector visits it every 15 or 30 seconds. This requires two things: a persistent, reachable endpoint and a service discovery mechanism so the collector knows where to look.

Pull works well for long-running services on VMs or Kubernetes pods. It does not work for serverless functions that exist for milliseconds and have no persistent address.

Push Model

In the push model, the application sends metric data to a backend. The app is the initiator, not the receiver. This is the only viable pattern for serverless and edge workloads, where there is no persistent host to scrape. Distlang Metrics uses the push model through its JavaScript client and HTTP Metrics API, letting you send counters and histograms directly from your application code.

Instrumentation

Instrumentation is the act of adding code to your application to emit metrics. DigitalOcean describes it as “the ability to track the behavior and performance of software, accomplished by adding code and configuration to software to output data.” Good instrumentation is invisible to users and cheap to run. Worth noting: the act of measuring itself consumes some resources (CPU cycles, memory, network). Effective monitoring minimizes this overhead.

Flush

Flushing is the act of sending buffered metric data to the backend before a handler exits. In traditional servers, this happens in the background continuously. In serverless functions, it becomes critical because the runtime may shut down the moment your handler returns.

Practitioners on engineering blogs confirm this is a real pain point. Boris Tane, founder of Baselime, has written about how “observing serverless applications is a pain” because of their stateless, ephemeral nature. Standard monitoring approaches fail because there is no persistent host to attach agents to.

waitUntil and after()

These are platform-specific APIs that solve the flush problem without blocking the user’s response:

• waitUntil(promise) on Cloudflare Workers keeps the runtime alive long enough to complete asynchronous work (like sending metrics) after the response has already been sent to the user. Inngest’s engineering blog notes that waitUntil is ideal for tasks that “should not block the user’s response” like logging and metrics.

• after() on Vercel/Next.js serves the same purpose in that ecosystem.

Neither guarantees delivery. If the promise fails, data is lost silently. But for metrics (where occasional loss is tolerable), this tradeoff is usually acceptable.

For working code examples of both patterns, see the Cloudflare Workers metrics guide and the Vercel route handler metrics guide.

Dashboards, Retention, and Alerting

Collecting metrics is only half the job. You also need to see them, store them, and act on them.

Dashboard

A dashboard is a visual representation of metrics over time, typically composed of charts, graphs, and summary panels. The best dashboards answer specific questions (“Is checkout latency normal right now?”) rather than displaying every metric you collect.

Retention

Retention is how long metric data is stored before deletion. This ranges from days to years depending on your tool and pricing tier. For most operational monitoring, 7 to 30 days covers the useful window. Longer retention matters for capacity planning and trend analysis.

Resolution and Sampling Rate

Resolution refers to the density of data points over a time window. Higher resolution means more data points per unit of time and a more detailed picture, but also more storage. Many systems downsample older data automatically, keeping high resolution for recent hours and lower resolution for past months.

Aggregation

Aggregation combines many individual measurements into summary statistics. OpenTelemetry defines it as “a technique whereby a large number of measurements are combined into either exact or estimated statistics about metric events that took place during a time window.” Common aggregations include sum, average, min, max, and percentile calculations.

Alerting and Thresholds

An alert fires when a metric crosses a predefined threshold. “Error rate above 5% for more than 2 minutes” is a typical alert rule. The concept is simple. The execution is tricky.

Dr. Droid’s observability series warns about alert fatigue: too many dashboards and too many alerts create noise that teams learn to ignore. The fix is fewer, more meaningful alerts tied to customer-facing impact, not internal implementation details.

Frameworks for Choosing What to Measure

One of the hardest questions in a metrics quickstart guide is not “how” but “what.” These three frameworks give you a starting point.

RED Method (Rate, Errors, Duration)

Designed for request-driven services. For every service, track: how many requests arrive per second (Rate), how many of those fail (Errors), and how long they take (Duration). If you instrument nothing else, RED gives you a useful baseline for any API or web service.

USE Method (Utilization, Saturation, Errors)

Designed for infrastructure and resource monitoring. For every resource (CPU, memory, disk, network), track: how much is in use (Utilization), how overloaded it is (Saturation), and how many errors occur. USE is the right framework when you are debugging capacity problems.

Four Golden Signals (Latency, Traffic, Errors, Saturation)

From Google’s SRE book. This is the minimal set of signals to understand any system’s health. It overlaps with RED and USE but works as a universal checklist.

Pierre Zemb takes a broader view, categorizing metrics into five buckets: operational counters, resource utilization, performance and latency, data volume and throughput, and business logic. This taxonomy is useful because it reminds you that not all important metrics are technical. Conversion rates and signup completions matter just as much as p99 latency.

Common Mistakes to Avoid

A metrics quickstart guide would be incomplete without the pitfalls that trip up most teams.

High-cardinality labels. Putting user IDs, session tokens, or raw URL paths into labels is the fastest way to blow up your monitoring system. Use bounded categories instead.

Not flushing in serverless handlers. If you record metrics but do not flush before the function exits, your data never reaches the backend. This is the single most common serverless metrics bug. Use waitUntil or after() and always await the flush.

Only measuring the happy path. Counting successful requests without counting failures leaves you blind during incidents. Instrument both.

Too many dashboards, too few insights. Creating a dashboard for every possible metric creates clutter. Focus on dashboards that answer specific operational questions. If nobody looks at a chart, delete it.

Treating monitoring as an afterthought. The SigNoz blog notes that engineers are increasingly expected to own the full lifecycle of a feature, from coding to monitoring. Adding metrics after the fact means reverse-engineering behavior you should have instrumented from the start. Thinking about what helpers and abstractions your platform provides early in the process saves significant rework later.

Quick-Reference Table

Next Steps

This metrics quickstart guide covered the vocabulary. Now it is time to write some code.

The fastest path from here to a working dashboard is the Distlang Metrics quickstart, which walks through defining a metric set, recording counters and histograms, and viewing results on a hosted dashboard. The free tier at dash.distlang.com includes 500K rows per month, 7-day retention, unlimited metric sets, and AI chart suggestions, so you can try everything covered in this guide without a credit card.

For environment-specific setup, see the Cloudflare Workers metrics guide or the Vercel metrics guide. If you are working outside JavaScript, the Metrics HTTP API accepts raw requests from any language.

For background on why Distlang was built and where it is headed, read Introducing Distlang.

FAQ

What is the difference between a counter and a gauge?

A counter only increases (or resets to zero on restart). It tracks cumulative totals like request counts. A gauge can move in either direction and represents a current value like memory usage or queue depth. If the thing you are measuring can decrease during normal operation, use a gauge. If it only accumulates, use a counter.

Why do serverless functions need special handling for metrics?

Serverless functions are stateless and short-lived. The runtime may shut down the instant your handler returns a response. If you have buffered metric data that has not been sent yet, it disappears. Using waitUntil (Cloudflare) or after() (Vercel) keeps the runtime alive long enough to flush metrics without delaying the response to the user.

How do I avoid high-cardinality problems with labels?

Keep label values bounded. Good labels have a small, predictable set of values: HTTP methods (GET, POST, PUT), status code classes (2xx, 4xx, 5xx), or environment names (production, staging). Bad labels contain unbounded values like user IDs, email addresses, or full URL paths. A metric with just three labels of 100 unique values each creates 1,000,000 time series.

Should I use histograms or summaries for latency tracking?

Use histograms. Summaries compute quantiles on the client side and cannot be aggregated across multiple service instances. Histograms use server-side bucket counting that supports aggregation. Unless you have a very specific reason to prefer summaries, histograms are the modern default.

What is a metric set?

A metric set is a namespace that groups related metrics for a single application or service. Instead of having all your metrics in one flat list, you organize them by service (like api-gateway or checkout-service). This makes dashboards cleaner and access control simpler as your system grows.

What is the difference between push and pull collection?

In pull collection (Prometheus-style), a central system scrapes your application’s metrics endpoint on a schedule. In push collection, your application sends data to the backend. Pull requires persistent, discoverable endpoints. Push works everywhere, including serverless environments where no endpoint exists between invocations.

Which metrics framework should I start with?

Start with RED (Rate, Errors, Duration) if you run request-driven services like APIs or web applications. It gives you the most actionable information with the fewest metrics. Add USE (Utilization, Saturation, Errors) when you also manage infrastructure. The Four Golden Signals from Google’s SRE book combines elements of both and works as a universal checklist.

How much does it cost to get started with metrics?

Many tools offer free tiers for small workloads. Distlang Metrics, for example, includes 500K rows per month, 7-day retention, and unlimited metric sets on its free plan at dash.distlang.com. The important thing is to start instrumenting early rather than waiting until you can justify a large observability budget.