Filtering with Dynamic Focus

The following example helps you to understand the concept of Dynamic Focus.

Consider the graph representation of a zoned application that is running on two hosts with four containers each. A Java virtual machine (JVM) runs in every container, and each of the two hosts runs two Tomcats and two Elasticsearch instances, which provide a service per host. A simplified version of the Dynamic Graph model looks like the following diagram:

The filtering capability reduces the nodes in the graph based on a search query.

A query for entity.type:tomcat matches all the Tomcat instances in the graph. This means that containers with Elasticsearch entities and the corresponding services no longer are visible when you view your infrastructure, application, and traces in the standard views.

Any chart, change, issue, or incident in Instana can be seen only in the context of the reduced graph.

Another example query is to search for all JVMs 1.8, such as entity.jvm.version:1.8.*

In this case, the graph looks as shown:

Dynamic Focus is a powerful tool to find and focus user attention on single entities, or groups of entities, within the graph that match certain criteria.

Instana also has structures that are outside the Dynamic Graph, but refer to the Dynamic Graph, such as events (like a change), issues, or incidents. An incident might contain services where Instana found KPI outliers and might contain entities with issues like high CPU load.

By using the search capability of Dynamic Focus, you can query and filter for incidents like event.state:open event.type:incident. The search filters all the active incidents in the currently selected time frame. In this example, it is assumed that only one active incident is available when a degradation of an Elasticsearch service causes subsequent degradation of a Tomcat service.

Because the incident that matches has references to the two services, the query filters only the relevant entities.

If you search for a service, then only the incidents that contain this service are shown.

Instana uses Lucene query syntax to build complex queries from the terms that are mapped to the application components and Boolean operators. A robust variety of query types are supported, like free text searches, tag filtering, CPU count queries, and more. The search bar aides the user in building queries by automatically highlighting valid individual terms from the rest of the string. In addition, you can avoid common string syntax pitfalls, such as confusing the free text query and with the Boolean operator AND.

The form that Lucene queries take varies depending on the implementation. In Instana, all queries proceed from a field to a field modifier and then to a quantifier. Both field values are separated by a period, while the quantifier is set off by a colon. For example, if you want to filter all the Tomcat instances in your application, then use the query entity.type: tomcat in the search bar. Instana removes everything from view except for all entities of the type labeled "tomcat."

The entity.type:tomcat query is just one query phrase. To build flexible and complex filters that show you exactly what you need, string different query phrases together with Boolean operators, such as AND, OR, and NOT. See the following example:

The AND operator is the default conjunction operator. So, if no Boolean operator is used between two terms, the AND operator is used.

For example, entity.type:tomcat event.state:open is equivalent to entity.type:tomcat AND event.state:open. Using of the AND operator when no Boolean operator is used, diverges from the Lucene standard, which uses OR by default.

entity.kubernetes.namespace:my-namespace AND NOT (entity.kubernetes.pod.name:my-name AND event.text:"ContainersNotReady")
 

entity.kubernetes.namespace:my-namespace AND NOT entity.kubernetes.pod.name:my-name AND NOT event.text:"ContainersNotReady"
 

The Dynamic Focus search bar supports autocompletion for search fields and highlights the Lucene query terms while you type. When typing the query terms, the search bar proposes search fields that match the current input. If you do not have a command of Lucene syntax, then you can get automatic help. All query proposals that appear in a drop-down list as follows the search bar. If the needed proposal is in view, click or go to it by using the arrow keys.

Instana's search function is zero-time, which means that the results appear when you enter your search criteria. You can also save, edit, and delete filters to speed up your workflow.

Using wildcard (*) inside double quotation marks ("") does not yield expected results.

No matches are returned because the * symbol is evaluated as a character and not as a wildcard in this case. According to the Lucene specification, single and multiple character wildcard searches in phrase queries are not supported. A phrase query is a group of words that are surrounded by double quotation marks, such as event.text:"something bad happened".

Using wildcard (*) in entity.service.name queries does not return expected results.

The query did not return any results because the asterisk (*) symbol is treated as a character and not as a wildcard. The entity.service.name query internally uses the contains operator to search for matching services. For example, the entity.service.name:proxy query returns all the services that contain the name proxy.

I am getting search result counts, which seem inconsistent.

Sometimes, the result counts might be confusing. For instance, when you search within the Infrastructure map, the searches within the views can match more entities than that are visible within the views, such as services, which are not visible in the Infrastructure map.

What fields are searched when I do not specify any fields in the search query?

When you don't specify any fields in a search query, Dynamic Focus targets the current context to provide meaningful results. This means that it searches the entity fields when you are on the infrastructure map view and searches event data when you are on the event view.

What is the difference between entity.selfType and entity.type?

Searching with entity.selfType limits the search results to the entity that is searched for. Searching with entity.type includes all the children of the entity that is searched for. For example, when you search with entity.selfType:host, the Infrastructure map shows only the host entities and all parent entities, like the zone. But when you search with entity.type:host, the search results include what is running on the host, such as webservers and databases. However, both entity.type and entity.selfType yield the same results for entity types of the application perspectives. For example, when you use the entity.type:endpoint query in the events view, the list contains only the events that are detected on endpoint entities.