SUSE Observability Query Language (STQL)
SUSE Observability
Last updated
SUSE Observability
SUSE Observability
Last updated
This page describes how to use the built-in SUSE Observability Query Language (STQL) to write advanced topology component filters. STQL queries are used in SUSE Observability to write .
An STQL query consists of and . The query output is a component, or set of components, filtered from the complete topology.
Component filters are used in two ways in STQL:
Define the set of components to be included in the query output.
Specify the set of components to be handled by an in-built STQL function.
The filters described below can be combined using the available to achieve complex selections of components.
healthstate
"all"
Components with the named health state.
label
"all"
Components with the named labels.
name
"all"
Components with the specified name.
type
"all"
Components of the specified type.
identifier
"all"
layer
"all"
Components in the named layer.
domain
"all"
Components in the specified domain(s).
environment
"all"
Components in the named environment.
The operators described below are available to use in STQL queries. Note that boolean operators will be executed in the standard order: NOT, OR, AND.
=
Equality matching
name = "cert-manager"
!=
Inequality matching
name != "coredns"
IN
Value is in subset
name in ("cert-manager", "cluster_autoscaler")
NOT
Negation
name NOT in ("cert-manager", "cluster_autoscaler")
AND and OR
Filter based on more than one condition or sub-query
name = "cert-manager" OR type = "deployment"
()
Use parenthesis to group results
(name = … AND type = …) OR (…)
For example:
You can use * as a full wildcard in a component filter. It isn't possible to filter for partial matches using a wildcard character.
The function withNeighborsOf extends STQL query output, adding connected components in the specified direction(s). The number of topology levels included can be adjusted up to a maximum of 15.
withNeighborsOf(components=(), levels=, direction=)
components
"all"
A component filter
levels
1
"all", [1:14]
The number of levels to include in the output. Use "all" to display all available levels (maximum 15)
direction
"both"
"up", "down", "both"
up: only components that depend on the named component(s) will be added down: only dependencies of the named component(s) will be added both: components that depend on and dependencies of the named component(s) will be added.
The example below will return all components in the application layer that have a health state of either DEVIATING or CRITICAL. Components with names "appA" or "appB" and their neighbors will also be included.
You can switch from basic to advanced filtering by selecting Advanced under Filter Topology in the View Filters panel.
It's always possible to switch from basic to advanced filtering. The selected basic filters will be converted directly to an STQL query.
You can switch from advanced to basic filtering by selecting Basic under Filter Topology in the View Filters panel.
It isn't always possible to switch from advanced filtering to basic filtering. Mpst simple queries can be converted to basic filters, however, some advanced queries aren't compatible with basic filters.
Basic filters can't contain an inequality.
Basic filters don't use =, they're always formatted using the IN operator. For example name IN ("cert-manager”) and not name = "cert-manager”.
Basic filters use AND/OR in a specific way:
All items in each basic filter box are joined with an OR: layer IN ("Containers", "Services", "Storage")
The different basic filter boxes are chained together with an AND: layer IN ("Containers") AND domain IN ("cluster.test.stackstate.io”)
The Include components basic filter box (name) is the exception - this is chained to the other filter boxes with an OR: layer IN ("Containers") AND domain IN ("cluster.test.stackstate.io") OR name IN ("cert-manager”)
To be compatible with basic filtering, the withNeighborsOf function and identifier filter must be joined to other filters with an OR: layer in ("Containers") OR identifier IN ("urn:kubernetes:/cluster.test.stackstate.io:kube-system:pod/cert-manager-7749f44bb4-vspjj:container/cert-manager")
If you try to switch from an advanced filter to a basic filter and the query isn't compatible, SUSE Observability will ask for confirmation before removing the incompatible filters. To keep the filters, you can choose to stay in advanced filtering.
Components with the specified URN identifier. The identifier filter is only compatible with basic filtering when it's specified using identifier IN (...) and combined with other filters using an OR operator. When the set filter is compatible with basic filtering, the number of component identifiers queried will be reported in the .
To be compatible with basic filtering, the function can only be combined with other filters using an OR operator. When an advanced filter includes a function withNeighborsOf that's compatible with basic filtering, the number of components whose neighbors are queried for is shown in the .
The component(s) for which the neighbors will be returned, see .