Filtering: wildcards, operators, tags, Smartscape

zietho — Wed, 25 Mar 2026 07:38:39 GMT

Filtering is how you turn “all the telemetry” into the slice that answers your question.
In Dynatrace, in a tile (Dashboards) or section (Notebooks), you’ll typically filter in either of the two ways:

Explore data (Dashboards/Notebooks): a point‑and‑click interface for exploring logs, metrics, events, traces, and more data types. It uses the Strato Filter field that provides operators, wildcards, AND/OR, escaping, variables support, simple search, and much more. Whenever you need more flexibility, you can easily transition to DQL with a single click.
DQL: for precise, reusable, and more complex filtering logic using commands like filter, filterOut, and search.

If you’re working in Data Explorer (used in the previous Dynatrace), the same concepts apply (filter/split/rate), just in a different UI and workflow. If you have Dashboards Classic content from the previous Dynatrace, there’s an official upgrade path to the latest Dashboards app, and it also describes how to upgrade a single Data Explorer–based visualization using Open with.

The filtering mental model (works everywhere)

Think of filtering as three separate decisions:

WHO (scope): Which entities are in scope? Examples: only services or hosts tagged team:payments.
WHAT (slice): Which subset of records or metric dimensions do you want?
Examples: only region = eu-west-1, only status_code = 500, only one endpoint.
HOW (matching rules): Exact match, contains, prefix/suffix, exclusions, grouped logic. Examples: include "/api/*" but exclude "/api/health".

If you mix these levels (for example, filtering by a field that doesn’t exist for your selected data), you’ll often get no results even though the telemetry exists. Most “why is nothing showing?” situations happen because we stack filters too quickly. A safer flow:

Start with no filters to confirm data exists.
Add one filter.
Run and verify.
Add the next filter (AND/OR) only after the previous one clearly worked.

In Explore data, you can always inspect what you built and then create a DQL section/tile once you need more complex logic.

Filter data with the Filter field in Explore (Dashboards/Notebooks)

Explore data is the “start here” option: point‑and‑click exploration with a filter field that suggests fields, matching operators, and existing field values.

Operator basics

Comparators:

= equals, != doesn’t equal
<, <=, >, >=
in (value1, value2), not in (value1, value2)
= * (is any value), != * (isn’t any value)docs.dynatrace
Wildcards (the “quick win”), they use *. Combining = with a wildcard before/after your term resolves to starts/ends/contains behavior like:

key = value* → starts with
key = *value → ends with
key = *value* → contains

AND/OR + grouping

Filters default to AND if you don’t specify an operator.
Use parentheses () to group statements when mixing AND/OR.

Escaping and quoting (❗don’t skip this❗)

If your values include spaces or special characters, escape them.

Wrap in quotes: “Product Name” = “Widget A”
Or escape individual characters with backslash \.

Variables (Dashboards)

You can reference dashboard variables with $var, and you can combine them with wildcards (prefix/suffix/contains patterns).

Smartscape

Filtering entity related dimensions is simple. Just enter "smartscape" into the Filter field and all available fields will appear as suggestions.

When to switch to DQL (and what to use)

Use DQL when you need:

more complex conditions,
reusable/shareable logic,
a clearer “source of truth” than UI-built filters.

Start here: DQL filter and search commands.

The three commands to know

filter: keeps records that match a condition.
filterOut: removes records that match a condition.
search: search-like filtering; supports searching across all fields or within specific fields; supports wildcards for matching tokens.

💡 Practical workflow tip: Start in Explore data for speed, then use Show DQL and Create DQL section/tile when the logic becomes non-trivial.docs.dynatrace

Practical filtering patterns (copy/paste mindset)

Pattern 1: Exact match vs contains vs prefix/suffix
- Use exact matches when values are stable and known.
- Use prefix/suffix for naming conventions that appear at the beginning or end of a field value.
- Use contains sparingly; validate you’re not matching unintended results. Implement these with wildcards as described above.
Pattern 2: Include first, then exclude (avoid accidental “zero results”)
- Build the include rule and confirm results.
- Add the exclusion rule and confirm you still get results.
- Only then combine multiple conditions.
- In DQL, exclusions are often clearer as filterOut … (versus piling up NOT logic).
Pattern 3: “One of these values”
- Prefer in (a, b, c) for controlled lists.
- Wildcards are not supported inside in (…) (it’s exact-match).
Pattern 4: Search-any-field vs field-specific search
- In the Explore filter syntax, * ~ term searches across all data and can be combined with AND/OR logic and other filters.
- In DQL, use search for search-like behavior and then refine further with filter as needed.

Real-world examples (Explore data first → DQL when needed)

Find various filters in tiles examples on the Dynatrace playground.

Example 1: Logs: narrow to a k8s container and an error keyword

Goal: “Show me logs for a specific service, then focus on logs that mention an error keyword.”

In Explore data, use the filter field to add a service-related filter (choose the suggested field/value).
Add a search across fields using * ~ keyword (for example, * ~ error).
If you need more complex logic, click DQL / Show DQL and then create a DQL section/tile to continue in DQL.

Example 2: Metrics: filter to a host name pattern, then split

Goal: “Show CPU usage, but only for hosts that follow a naming pattern.”

In Explore data → Metrics, select the metric you need, then add a filter for example, a host name filter.
Use wildcards to match patterns like prefixes/suffixes/contains. For example, host.name = prod-*.
Add a split, for example, split by host so the chart compares the hosts you selected.

Example 3: DQL: remove noisy results with filterOut

Goal: “Keep errors but remove a known noisy pattern.”

In DQL, use:

filter to keep what you care about
filterOut to remove the known noise. This is usually easier to reason about than stacking multiple NOT clauses in a UI filter.

Data Explorer (previous Dynatrace)

Data Explorer is designed to query and visualize metrics and provides classic query components such as:

selecting a metric,
choosing aggregation,
Split by dimensions,
Filter by to set scope,
Rate options (per second/minute/hour) for rate-based views.

If you prefer learning by doing, Dynatrace provides a “start with a template” flow and a “start from scratch” walkthrough in the Data Explorer quick start.

If you have Dashboards Classic content from the previous Dynatrace, you can upgrade it to the latest Dashboards app—and you can also upgrade a single Data Explorer–based visualization using Open with into Dashboards or Notebooks.

Troubleshooting: “no data / no records” caused by filters

Work through this in order:

Timeframe: confirm data exists in the selected time range.
Simplify logic: remove OR/NOT/parentheses; add conditions back one by one.
Validate the key/field: make sure the field exists for this data type.
Fix escaping: quote values with spaces/special characters; escape literal * if needed.docs.dynatrace
Switch to DQL for clarity: filter / filterOut / search make complex logic easier to reason about.docs.dynatrace
Re-check scope: make sure you didn’t filter the wrong “WHO” (entity scope) when you meant “WHAT” (dimension slice).

In general a debug method that works is start broad → add one filter → verify → repeat.

topic Filtering: wildcards, operators, tags, Smartscape in Dashboarding