Dimensions

A dimension is any key you can put inside {...} or by (...) in a query, or in a source query’s where clause. The Explorer groups them into four kinds. Available dimensions depend on the measurement’s source; each selected metric must support your filters and grouping.

Dimensions describe one metric record (the individual measurement a check produced). They include platform fields and the labels on tests and agents described in Core concepts: those configured labels are also stamped onto measurement records and can be queried by their bare keys.

Identity

Which test ran, on which agent, against what. These are the first keys to check; a dimension can be empty when it does not apply to that measurement.

Key	What it is
metric_name	The metric’s own name
test_id	The test definition that produced the record
test_type	Which kind of test ran
agent_id	The agent the record is credited to
target	What the test was pointed at
family	IPv4 or IPv6

Platform

Context the system stamps on every record, or that the agent reports as a typed field. You never write these as labels yourself; they describe the measurement, not the thing measured.

Key	What it is
metric_kind	Gauge, counter, duration, ratio, bool, or distribution. Bool is how a check’s pass/fail is stored
unit	The metric’s unit
mode	Active probing or passive observation. A missing sample alone does not establish a failed probe or packet loss
transport	The transport the probe actually used
clock_quality	How well the producing agent’s clock was disciplined
agent_version	The agent build that produced the record
namespace	The network scope used to interpret internal devices and IPs, see Core concepts
cluster_id	Set when the test was assigned to a cluster rather than one agent; empty otherwise
executing_agent_id	Which cluster member actually ran the test, what makes a failover diagnosable after the fact
sharing_mode	How the producing agent is shared between tenants
subject_kind	What the record’s subject is: a device, an interface, an address
subject_address	The subject’s address, as the agent reported it
subject_hostname	The subject’s hostname, as the agent reported it
subject_if_name	The subject interface’s name, as the agent reported it
rs.flow_id_control	Whether the agent could pin the probe’s flow identifier, decides how much an ECMP path comparison can be trusted
rs.schema_version	The wire schema version the producing agent stamped
rs.cardinality_bucket	Present when this record’s own labels were discarded for exceeding its test’s cardinality budget

Entity

Facts resolved after the record was written, by correlating its subject against your device inventory, see Infrastructure. Querying one of these switches the query to read the resolved view rather than the raw table, which is why the Explorer groups them apart from platform dimensions: they exist only where a subject could be matched to something in inventory, and “unresolved” is itself a meaningful, filterable state.

Key	What it is
device_id	The device the subject resolved to
device_name	The resolved device’s name
interface_id	The interface the subject resolved to
provenance	How the subject was identified in the first place
resolution	How the entity stage resolved the subject, or why it refused to
namespace_tier	Which rung of the resolution ladder answered, and so how much the correlation can be trusted
subject_resolved_by	Whether the device was matched by address or by name

Your labels

Agent labels, test labels (including inherited test-group labels), and labels attached by a check or custom script are queryable by their bare keys. For example, an agent label site="east" and a test label service="checkout" can be used in either query form:

http_check_total_ms{site="east", service="checkout"} | p95 by (agent_id)

from tests
| where site = "east" and service = "checkout"
| summarize p95(http_check_total_ms) as latency by agent_id

You can also group by labels, for example by site, service, and order source results by a label retained in the grouping. No promotion is required.

Queries read label values stored on each measurement; changing a configured label does not relabel existing measurements. Agent and test labels share a record-label map, with the agent value winning when both define the same key. There is no automatic agent.labels.KEY or test.labels.KEY namespace. Use distinct keys when both values need to survive. Built-in dimensions take precedence over labels with the same key, and a source’s metric- or resource- specific label map can take precedence over record labels. This differs from agent.name, test.name, and agent.site, which resolve current metadata.

A script-defined label works the same way:

{shard="us-3"} | avg by (shard)

An unpromoted label like shard above is read from a map on matching rows. Discovery includes promoted keys, configured agent and test labels, and a bounded sample of observed label keys and values. It is not an exhaustive list of every key a script might have used; you can type an undiscovered key directly.

Promoting a label key in Settings → General gives it a dedicated, indexed column. Promoted keys appear in the browser under “Your labels” with their own recent-values list, and matchers against them run faster on a large time range. Promote a key once it is one you query often; an unpromoted label is still queryable even when it has not appeared in autocomplete.

Aliases

A handful of platform dimensions are also stamped as a raw label with an rs. prefix, rs.transport, rs.agent_version, rs.namespace, rs.cluster_id, rs.executing_agent_id, rs.sharing_mode. Both spellings resolve identically; the bare name is the canonical one and the one autocomplete offers, so someone who saw the rs. spelling in a raw row and typed it gets the right answer without the list looking duplicated.

This is a read-side convenience only. Writing a label under the rs. prefix yourself is not possible; that prefix is reserved so a script cannot claim to be a different cluster member than it is.

Browsing values

Expanding a dimension in the browser shows a sample of its recent distinct values, each a button that appends key="value" to your query. Dimensions marked non-facetable in the tables above (target, test_id, subject_address, and a few others) skip this: they are effectively unbounded, and a top-25 sample of thousands of targets is not a useful list to render or a query worth spending on. Type the value directly, or use the editor’s name-aware agent and test suggestions described below.

Source dimensions and current metadata

Discovery also includes dimensions from the host-resource, container, and Kubernetes sources. For example, process_name, process_instance, resource_kind, and monitored are available for host queries. Dimensions marked as suitable for value discovery return at most 25 suggestions, drawn from recent observations; high-cardinality dimensions remain available as keys even when their value list is empty.

agent.name, agent.site, test.name, and test.group_id offer bounded values from the tenant’s current metadata. Name-aware editor suggestions also carry agent and test ID/name pairs, independently of the top-25 observed-value lists. Choose a name in an ID filter to insert its ID, or in a name filter to insert its escaped name. Duplicate names display their IDs so you can choose exactly. Metadata discovery is limited to 10,000 entities per relationship; exceeding the limit returns an error rather than a silently incomplete identity list.

These values are current even for queries over historical samples. agent.id and test.id are accepted aliases for agent_id and test_id. test.name belongs to the test definition (one check); test.group_id identifies its containing test group. Group by IDs alongside names when names are not unique. A configured entity appearing in suggestions is not proof of recent measurements.

Use the source’s own field and dimension suggestions inside a from pipeline. An observed value list is a starting point, not an exhaustive list of valid values; exact names can always be typed directly. See the query reference for filtering, grouping, and joining examples.

Next

• Query language: how these keys combine into a full query
• Metrics Explorer