Variable Query¶

Variable queries in views are used to define the value range and data source of variables. They support configuring whether the value range follows the dashboard time widget, meeting different data filtering needs.

Value Range Control¶

The selectable values obtained from the query can be configured to be affected or not by the dashboard time range:

Main Query Methods¶

View variables currently support five types of query methods. You can choose as needed:

DQL Query¶

Supports all data types including Metrics, LOG, Infrastructure, Objects, Traces, RUM, etc. It is the most comprehensive in functionality.

Click Learn more about DQL definitions and syntax.

Basic Syntax Structure¶

Data Type::Data Source:(distinct('Attribute Field Name')){Filter Conditions}

Example:

# Get hostnames of all Docker containers
O::docker_containers:(distinct(`host`))

Specifying Time Range¶

DQL supports directly specifying the time range within the statement, which takes precedence over the dashboard time widget:

Example:

# Only show hosts with data in the last 10 minutes
O::docker_containers:(distinct(`host`)) [10m]

Show Function Query¶

Suitable for querying metric-related metadata information. Does not support time range.

Syntax Structure¶

Click Learn more about DQL function descriptions.

Example:

# Query all measurements
SHOW METRIC_SET()

# Query all tags for a specified measurement
SHOW LABELS FROM M::cpu

PromQL Query¶

PromQL queries support manually writing query statements. By default, they use the time selected by the dashboard time widget for querying and return data.

For information about PromQL queries, refer to PromQL Quick Start.

Data Type Query¶

If you need quick configuration and don't want to write query statements, you can directly select the data type and choose filter conditions on the page.

Supported data types:

• Metrics
• Basic Objects (hosts, containers, processes, etc.)
• Resource Catalog
• LOG
• APM
• RUM

In this mode, you cannot add time ranges or configure cascade queries.

External Database¶

If your target query selectable values are stored in an external database (e.g., MySQL, PostgreSQL), you can choose this query method to directly connect to your existing data system.

1. Select the data source;
2. Enter the query statement;
3. Select the sorting method.

For more details, refer to External Database.

External Functions¶

If your target selectable values need to be obtained through custom function logic, you can choose this query method to call externally registered functions in the workspace to dynamically generate candidate value lists.

1. Select function: Choose from externally registered functions in the current workspace;
2. Add function parameters as needed, fill in parameter names and corresponding values. Supports referencing other view variables in the dashboard, using the format #{variable name}. When the referenced variable changes, the system will automatically re-call the function and refresh candidate values;
3. Value field: Used to specify which field's value in the function's returned data will serve as the variable's candidate value (❗️This field is optional; if not set, the system defaults to taking the first field in the returned data; if you need to return the value of a specific field, manually enter the field name).

This query method does not support adding time ranges or configuring cascade queries.

Custom Query¶

If your target selectable values are fixed and limited in number, and there's no need to query a database, you can directly define a set of values for the view variable. There's no need to obtain values through query statements. Separate each option with an English comma ,, e.g., prod,test,dev,staging.

This query method does not support adding time ranges or configuring cascade queries.

Cascade Query¶

Used when multiple variables have a hierarchical relationship. For example:

• After selecting "Service", the "Environment" dropdown only shows environments for that service (not all environments).
• After selecting "Environment", the "Version" dropdown only shows versions for that environment.

Configuration Conditions¶

1. Only DQL queries support cascade configuration;
2. In the child variable's query statement, reference the parent variable's current value using #{parent variable name}.

Configuration Example¶

The following example uses the cascade filtering of view variables in the Web Application Overview of RUM, based on service, environment, and version for linked query configuration:

Three variable query statements need to be configured in the dashboard. The second and third query statements use the #{variable name} configured in the first query:

• Variable 1 (Service): Query all application lists:

T::re(`.*`):(distinct(service))

• Variable 2 (Environment): Query all application lists, and the environment list selected in Variable 1:

T::re(`.*`):(distinct(env)) { service = '#{service}'}

• Variable 3 (Version): Query all application lists, and the version list selected in Variable 2:

T::re(`.*`):(distinct(version)) {service = '#{service}'}

Query Scenario Examples¶

Associating with Charts¶

1. In the chart query, when filtering fields, select the variable for the value;
2. Switch the variable value in the scenario view, and the chart will filter and display based on the variable tag.

Reverse Addition to Charts¶

1. After clicking on a specific time series or data point in the chart;
2. Select Apply to View Variable;
3. The system automatically fills in the query.