obsdog

Datadog Fundamentals Certification / 06 / 06

Data Visualization

What this domain covers

In this domain, you learn how to make use of the data collected by the Agent and integrations from the perspective of those who view and use it. There are 5 pillars. First, getting an overview of everything with the Host Map (what color and size represent, and how to use Group by and Filter). Second, reading data side by side on dashboards (the difference between Timeboard and Screenboard, how to choose widgets, template variables, and sharing externally). Third, understanding the structure of metric queries (filtering with from, time aggregation and space aggregation, and functions). Fourth, filtering and grouping with tags. Fifth, notifying on anomalies with monitors (detection methods, evaluation window and thresholds, no data, simple alerts and multi alerts, variables in notification messages, and downtimes). The exam asks questions in the form of "which widget or feature do you use for this purpose", "what does this query represent", and "with this configuration, when does the monitor fire and who receives it". Numbers and defaults are based on the official documentation as of September 2026.

Topics listed in the official guide

  • Host map
  • Dashboards
  • Working with metrics
  • Working with tags
  • Monitors and alerts

Key points

  • The color of each object in the Host Map represents the metric chosen in Fill by; the default is CPU usage, shifting from green at 0% to orange at 100%. Size is determined by Size by.
  • Group by in the Host Map accepts multiple tags. Entering availability-zone and then instance-type subdivides first by zone and then by instance type.
  • A Timeboard is an automatic layout in which all widgets share the same point in time, suited to troubleshooting and correlation; a Screenboard is free-form and suited to status boards.
  • Template variables are defined by a tag key and used in a widget's from field as $<NAME>. The default value is *, and depending on the selection, &tpl_var_<NAME>=<VALUE> is appended to the URL.
  • In a metric query, time aggregation (rollup) is always applied, and the wider the displayed time range, the longer the period each point represents. Space aggregation combines by tag using avg, sum, min, or max.
  • The Query Value widget reduces the aggregation result to a single value, and Top List lays out one value per group. Timeseries suits viewing trends, and Heatmap suits viewing distributions.
  • Tag inclusion combines with AND and exclusion with OR. On dashboards, you filter in the from field, and entering a tag key in the avg by field yields one line per value.
  • The default evaluation window for a metric monitor is 5 minutes. With average aggregation it is the average over the period; with max it fires if even one point crosses; with min it fires only when every point crosses (for an above threshold).
  • If the query has no grouping, a simple alert (1 notification) is the default; if it does, a multi alert (1 notification per group that meets the condition) is the default.
  • The @ notation in notifications requires a space immediately before it, and conditional variables such as {{#is_alert}} and {{#is_recovery}} switch the body and destination by state. A downtime stops notifications but does not stop state transitions.

Terms and concepts

Host Map (Fill by and Size by)

The Host Map is a screen that lays out hosts, pods, containers, and clusters as hexagonal objects so you can grasp the state of your entire infrastructure at a glance. The color of each object represents the metric or signal chosen in Fill by; by default, CPU usage shifts from green at 0% to orange at 100%. You can also switch it to memory or the number of error logs. When no Secondary resource is specified, Size by lets you tie size to a metric as well, so you can read two indicators at once, such as "color is CPU, size is error logs". The Filter field supports AND, OR, NOT, and the * wildcard, and Group by lets you layer multiple tags to divide objects spatially.

Timeboard and Screenboard

Datadog dashboards come in several layouts. A Timeboard is an automatic layout in which the entire dashboard shares a single point in time (fixed or real time). Because it lets you cross-check what was happening at a given moment across multiple graphs, it suits troubleshooting, correlation analysis, and data exploration. A Screenboard is a free-form layout that can hold diverse objects such as images, graphs, and logs, so it suits status boards that update in real time and displays that tell a story. The grid-based Dashboards layout has a maximum width of 12 grid units and can be used as a middle ground between the two. The basic approach is to work backward from the purpose when choosing a layout.

Template Variables

Template variables are a mechanism for dynamically filtering or grouping the widgets on a dashboard all at once. You define them by a tag key (such as env or service) or an attribute, and the name is assigned automatically to match the chosen tag. The default value is * (all values), and the list of available values always includes * as well. In a widget query, you write $env in the from field, and selecting production from the dropdown narrows every widget that uses $env to production at the same time. The selection can be shared as &tpl_var_env=production in the URL, and when you want to embed only the value, you use $env.value. The selected state can be saved under a name as a Saved view.

Structure of a Metric Query (Time Aggregation and Space Aggregation)

A single metric query is built in this order: choose the metric name, filter by tags (from), decide the time aggregation, decide the space aggregation, and apply functions if needed. Time aggregation is always applied to solve the problem of "more points than pixels", and the longer the displayed time range, the wider each time bucket (rollup) becomes and the coarser the granularity. The default is avg; sum, min, max, and count are also available, and you can specify it explicitly as in .rollup(max, 60). Space aggregation splits the time series by tags such as host or region and combines each group with one of avg, sum, min, or max. Even the same max means different things as "max along the time axis" and "max along the space axis", so it is important to distinguish the two to avoid misreading graphs.

Choosing Widgets

You choose dashboard widgets by "what question you want to answer". Timeseries suits seeing how a value moved over time; Query Value suits summarizing the results of time aggregation and space aggregation into a single number (KPI); Top List suits seeing which host or service is the largest by rank; and Heatmap suits seeing the distribution of values across tags or the spread of a distribution metric. The Hostmap widget lets you view resource usage across your whole infrastructure as an area, and Monitor Summary lets you list the current state of alerts. The fastest way to get started is to clone a preset dashboard that ships with an installed integration and adjust the widgets to your own purpose.

Filtering and Grouping with Tags

Tags deliver value not just by being applied but by being used. Entering a tag in a dashboard's from field narrows the metric to all sources that carry the tag, and entering a tag key in the avg by field splits it into one line per value. With nothing specified you get a single line for the average of all hosts; with region:eastus in from you get the average for the eastern region; and with host added to avg by you get a line for each host in the east. This gives you a step-by-step way of reading. Inclusion of multiple tags combines with AND and exclusion with OR, and dashboards also accept the boolean syntax NOT, IN, and NOT IN. In the Host Map and Infrastructure List, the Filter by and Group by at the top play the same role, as do the from, excluding, and avg by fields in monitors.

Monitor Detection Methods and Evaluation

Monitor types include Host, which checks whether a host is reporting; Metric, which compares against a threshold; Integration, which checks an integration's values or health; and Composite, which combines multiple monitors with an expression. Metric monitors have 5 detection methods: Threshold, which compares against a static threshold; Change, which looks at the difference from N minutes ago; Anomaly, which learns the expected range from past behavior; Outliers, which finds the odd one out within a group; and Forecast, which predicts future values. The default evaluation window is 5 minutes, and the points in the window are summarized into a single value with average, max, min, or sum and compared against the threshold. Thresholds include Alert (required) and Warning, and you can also specify separate recovery thresholds.

Simple Alerts and Multi Alerts

The unit of notification is determined by the query's grouping. A query with no grouping becomes a simple alert, and only 1 notification is sent when the value aggregated across all reporting sources meets the condition. This is the usage where you get 1 notification when the average CPU across all servers crosses the threshold. Grouping such as avg by service turns it into a multi alert, and a separate notification arrives for each service that meets the condition. If you group by service and host but want notifications consolidated per service, you can remove host from the notification grouping to reduce the count. The title of a multi alert automatically includes the tags of the scope that fired, and in the body you can indicate the target with tag variables such as {{host.name}}.

Notification Messages and Conditional Variables

Notification messages are built from Markdown and variables. Destinations are written in @ notation such as @slack-<CHANNEL>, @pagerduty-<SERVICE_NAME>, or @<EMAIL_ADDRESS>, and a space is required immediately before them (if attached directly, as in low@ops-team@example.com, they are not interpreted). Conditional variables are wrapped in open and close pairs such as {{#is_alert}} and {{/is_alert}}, and by writing the body and destination inside them you can switch the content and destination between alert, recovery ({{#is_recovery}}), warning ({{#is_warning}}), and missing data ({{#is_no_data}}). Because a monitor holds only one state at a time, state-based conditions are split into separate blocks. Using notification rules is recommended for managing destinations.

Downtimes and No Data

A downtime is a mechanism for stopping a monitor's alerts and notifications during planned maintenance or shutdowns. It does not stop the state transitions themselves, so you can review the state history afterward. You select targets by monitor name or monitor tag, and adding a condition such as service:web-store to the Group scope silences only that service's groups while notifications for other services are delivered as usual. No data, on the other hand, is how the "no data arriving" state is handled; you choose from evaluating it as zero, keeping the last state, showing NO DATA, showing NO DATA and notifying, or showing OK. For a metric that should always be reporting, the setting that notifies on missing data is the safe choice.

Check your understanding

Check what you have learned with 5 questions