Metrics, Timeseries, and Types
Key Takeaways
- A timeseries is a sequence of timestamped numeric values; Datadog stores metrics as timeseries for graphing, rollups, and alert evaluation.
- Core metric types include gauge, count/rate, and distribution — each affects how values aggregate in queries.
- Default Agent collection interval is ~15 seconds; graphs roll up points into larger buckets over longer time windows.
- Query modifiers like as_count() and as_rate() change how count-type metrics display without changing stored raw data.
- Changing a metric's type in Metrics Summary affects that metric globally across all dashboards and monitors.
Quick Answer: A timeseries is a stream of numeric measurements tied to timestamps. Datadog metric types (gauge, count, rate, distribution) control how values aggregate. Agent metrics arrive about every 15 seconds; graphs rollup points into larger buckets over long windows. Editing a metric type in Metrics Summary changes behavior globally.
Understanding metrics as timeseries — not isolated numbers — is essential for both Data Collection and Visualization domains. The exam asks what makes a metric graphable, why counts look like decimals, why cloud metrics lag host metrics, and what happens when someone "fixes" a metric type in the UI.
What Is a Timeseries?
A timeseries is a sequence of (timestamp, value) pairs for a named metric, optionally distinguished by tags. Datadog indexes each unique combination of metric name + tag set as a separate series.
| Concept | Definition |
|---|---|
| Metric name | Identifier such as system.cpu.user or orders.completed |
| Point | Single numeric observation at a Unix epoch timestamp |
| Series | All points sharing the same name and tag values |
| Rollup | Aggregating points into larger time buckets for display |
Example: system.cpu.user{host:web-01} might report 23.4 at 12:00:00, 25.1 at 12:00:15, 21.8 at 12:00:30 — one series, many points.
On the Exam:
os:linuxis a tag (metadata for filtering).system.cpu.useris a timeseries metric (numeric values over time). Do not confuse descriptive metadata with measurable signals.
Metric Types and Aggregation Behavior
When data arrives — from an integration, DogStatsD, or API — Datadog interprets it according to metric type:
| Type | Meaning | Query Behavior |
|---|---|---|
| Gauge | Value at a point in time (memory used, queue depth) | avg, max, min over intervals |
| Count | Number of events in an interval | Often shown with as_count() or normalized as_rate() |
| Rate | Per-second occurrence | Derivative-style display |
| Distribution | Global percentile stats (p50, p95, p99) | Percentile aggregations across hosts |
| Histogram (legacy path) | Local aggregation before forward | Being superseded by distributions for global percentiles |
Count vs Rate Display
DogStatsD count submissions are normalized over the Agent flush interval, so Metrics Explorer may show a per-second decimal rather than an integer. That is expected — not a sign the wrong type was chosen.
| Modifier | Question It Answers |
|---|---|
as_count() | "How many events in this rollup bucket?" |
as_rate() | "How many events per second on average?" |
Exam scenario: "Counter shows 0.5 per second" → explain flush-interval normalization, not data loss.
Collection Cadence and Graph Rollups
Agent and integration metrics default to roughly 15-second collection. Each check run produces a new point. High-frequency DogStatsD emissions can arrive more often, but the UI still aggregates for display.
When you zoom a graph from one hour to one week, the curve often looks smoother because Datadog rolls up points into larger buckets to fit display limits. The underlying stored data still exists; the rendered graph shows aggregated values (avg, sum, max depending on query).
| Time Window | Typical Bucket Behavior |
|---|---|
| Last hour | Fine-grained points (~seconds) |
| Last day | Moderate rollups |
| Last month | Large buckets; spikes may average out visually |
Common Trap: A smoothed weekly graph does not mean Datadog deleted short spikes — rollups summarize visually.
Partial Buckets
The right edge of a timeseries graph may show a shaded partial bucket — the current interval is incomplete. This is a visualization cue, not necessarily missing data or an Agent failure.
Metrics vs Logs vs Traces (Collection View)
The three observability pillars enter Datadog through different intake paths but share tagging conventions:
| Signal | Structure | Best For |
|---|---|---|
| Metrics | Numeric timeseries | Rates, utilization, trends, alerting thresholds |
| Logs | Discrete text records | Stack traces, messages, audit detail |
| Traces | Request spans with timing | Latency breakdown across services |
Metrics answer "how much and how fast" over time; logs answer "what exactly happened." Datadog correlates them when env, service, and version tags align.
Cloud vs Host Metric Latency
Not all timeseries arrive at the same speed:
| Source | Typical Latency | Reason |
|---|---|---|
| Host Agent check | Seconds | Local collection every ~15s |
| DogStatsD | Seconds | Local UDP to Agent |
| AWS CloudWatch via crawler | Minutes possible | Provider publish delay + API poll interval |
Exam questions compare RDS CPU (crawler) with EC2 host CPU (Agent) — both are valid timeseries, but freshness differs by architecture.
Metrics Summary and Type Changes
Administrators can edit metric metadata in Metrics Summary, including changing a metric's type (e.g., gauge to count).
Warning: Type changes apply globally to that metric name — every dashboard, monitor, and notebook query using it may change behavior. This is not a per-dashboard override.
| Action | Scope |
|---|---|
| Edit metric type in Metrics Summary | Entire organization for that metric name |
| Change widget time frame | Single widget view only |
| Add tag to Agent config | New points going forward on that host |
Query Visibility Rules
The Metrics Explorer query editor autocomplete shows metrics that reported in the last 24 hours by default. A metric that exists historically but stopped reporting will not appear in autocomplete — you can still type the name manually if you know it.
Changing metric type or tags does not instantly rename series; tag changes affect new points.
Worked Scenario: Interpreting a Latency Metric
An API team graphs api.request.duration submitted as a distribution from DogStatsD. They want p95 latency by service tag.
- Query:
p95:api.request.duration{*} by {service}. - Over one hour: points every few seconds per service series.
- Over 30 days: graph smooths via rollups; p95 still meaningful.
- A teammate changes the metric type to gauge in Metrics Summary.
- All dashboards and monitors on that metric now aggregate differently — revert or update every query.
The exam tests step 4's global impact more often than percentile syntax.
What makes a metric a timeseries in Datadog?
Why can a Datadog metric graph look smoother when you zoom from one hour to one week?
An engineer changes a metric's type from gauge to count on the Metrics Summary page. What is the main caution?
Why can metrics from a cloud integration such as AWS arrive later than host metrics from the Agent?