StackState for Kubernetes troubleshooting
The Filters menu on the top right corner of the view UI allows you to filter the components (topology), events and traces displayed in a view. Once applied, the filters will affect the content of all the perspectives in a view.
Topology filters can be used to select a sub-set of topology components to be shown in any one of the available perspectives. Whilst the events and the traces filters are the same for all the view types, the topology filters depend on the type of view you are in. Read more:
On the kubernetes views, the topology filters are limited to a small set of basic filters that persist across all the Kubernetes views:
clustersand / or
namespaces. The persistent topology filters for Kubernetes views are placed outside the regular
filtersmenu in the UI and are not interdependent on each other (e.g. selecting a cluster does not automatically update the
namespacesfilter to reflect only the namespaces of that cluster).
Kubernetes topology filters
For other view types, you can browse your topology using basic or advanced topology filters. Read more about:
The main way to filter topology is using the available basic filters. When you set a filter, the open perspective will update to show only the visualization or data for the subset of your topology that matches the filter. Setting multiple filters will narrow down your search further. You can set more than one value for each filter to expand your search
Layers, Domains, Environments and Component types
Filter by the component details included when components are imported or created.
Only include components with a specific label.
Components named here will be included in the topology in addition to the components returned from other filters.
To filter the topology using basic filters, click the Filters menu in the top right corner of the UI and select Switch to basic under the Topology vertical tab.
Basic topology filters
You can use the in-built StackState Query Language (STQL) to build an advanced topology filter that zooms in on a specific area of your topology.
To filter the topology using an STQL query, click the Filters menu in the top right corner of the UI and select Switch to STQL under the Topology vertical tab.
The STQL query example below will return components that match the following conditions:
- In the Domain
- AND has a Health state of
- OR is the Component with the name
(domain IN ("security check") AND healthstate IN ("CLEAR", "DEVIATING")) OR name IN ("ai_engine")
Advanced topology filters
You can switch between basic and advanced filtering by selecting Switch to basic or Switch to STQL under the Topology vertical tab in the Filters menu.
It's always possible to switch from basic to advanced filtering. The selected basic filters will be converted directly to an STQL query. For simple queries it's also possible to switch from advanced to basic filtering, however, some advanced queries aren't compatible with basic filters.
The advanced filters listed below are compatible with basic filtering, but can't be set or adjusted as a basic filter.
- withNeighborsOf - when an advanced filter includes the function withNeighborsOf, the number of components whose neighbors are queried for is shown in the Other filters box. To be compatible with basic filtering, a
withNeighborsOffunction must be joined to other filters using an
- identifier - when an advanced filter selects components by identifier, the number of component identifiers queried is reported in the Other filters box. To be compatible with basic filtering, an
identifierfilter must be specified and joined to other filters using the operator
OR identifier IN (...).
The Other filters box in the basic topology filters lists all these advanced filters and the number of affected components.
The Other filters box only gives details of advanced filters that have been set and are compatible with basic filtering.
To optimize performance, a limit is placed on the amount of elements that can be loaded to produce a topology visualization. The filtering limit has a default value of 10000 elements. If a basic filter or advanced filter query exceeds the filtering limit, a message will be shown on screen and no topology visualization will be displayed.
Note that the filtering limit is applied to the total amount of elements that need to be loaded and not the amount of elements that will ultimately be displayed.
In the example below, we first LOAD all neighbors of every component in our topology and then DISPLAY only the ones that belong to the
applicationslayer. This would likely fail with a filtering limit error as it requires all components in the topology to be loaded.
withNeighborsOf(direction = "both", components = (name = "*"), levels = "15")
AND layer = "applications"
To successfully produce this topology visualization, we would need to either re-write the query to keep the number of components loaded below the configured filtering limit, or increase the filtering limit. By fitering for only components in the
applicationslayer, we will DISPLAY the same components as the query above, without first needing to LOAD all components. This query is therefore less likely to result in a filtering limit error.
layer = "applications"
The View Filters panel on the left of the StackState UI can be used to filter the events shown in the Events Perspective. They're also included in the Event list in the right panel View summary tab and the details tabs - Component details and Direct relation details.
The following event filters are available:
Click the Type filter box to open a list of all event types that have been generated for the currently filtered components in the current time window. You can select one or more event types to refine the events displayed.
Events can be generated by StackState or retrieved from an external source system, such as Kubernetes or ServiceNow, by an integration. Click the Source filter box to open a list of all source systems for events that have been generated for the currently filtered components in the current time window. Select one or more source systems to see only those events.
Relevant event properties will be added as tags when an event is retrieved from an external system. For example
Traces shown in the Traces Perspective can be filtered based on two properties of the spans they contain:
- Span types
- Span tags
For example, if you filter the trace list for all spans of type
database, this will return all traces that have at least one span whose type is