ダイナミック・フォーカスによるフィルタリング

以下の例は、ダイナミック・フォーカスの概念を理解するのに役立ちます。

それぞれが 4 つのコンテナーを持つ 2 つのホスト上で実行されているゾーン・アプリケーションのグラフ表現について考えてみます。 すべてのコンテナ内で Java 仮想マシン（ JVM ）が実行されており、2台のホストそれぞれが2つのTomcatインスタンスと2つの Elasticsearch インスタンスを実行しており、これによりホストごとに1つのサービスが提供されています。 単純化されたバージョンの動的グラフ・モデルは、以下の図のようになります。

フィルター機能により、検索照会に基づいてグラフ内のノードが削減されます。

entity.type:tomcat の照会は、グラフ内のすべての Tomcat インスタンスと一致します。 つまり、 Elasticsearch エンティティーおよび対応するサービスを持つコンテナーは、標準ビューでインフラストラクチャー、アプリケーション、およびトレースを表示するときに表示されなくなります。

Instana におけるあらゆるチャート、変更、課題、またはインシデントは、縮小グラフの文脈においてのみ確認できます。

もう 1 つの照会例は、すべての JVM 1.8を検索することです (例: entity.jvm.version:1.8.* )。

この場合、グラフは以下のようになります。

ダイナミック・フォーカスは、特定の基準に一致するグラフ内の単一のエンティティーまたはエンティティーのグループを検出し、それらにユーザーの注意を集中させるための強力なツールです。

Instana また、ダイナミックグラフの外にあるものの、ダイナミックグラフを参照する構造（変更などのイベント、課題、インシデントなど）も存在します。 あるインシデントには、 Instana がKPIの異常値を検出したサービスが含まれている可能性があり、また、CPU負荷が高いなどの問題を抱えるエンティティが含まれている可能性があります。

ダイナミック・フォーカスの検索機能を使用して、 event.state:open event.type:incidentなどのインシデントを照会およびフィルタリングすることができます。 検索は、現在選択されている時間枠内のすべてのアクティブなインシデントをフィルタリングします。 この例では、 Elasticsearch サービスの低下が原因で Tomcat サービスがその後低下する場合、使用可能なアクティブ・インシデントは 1 つのみであると想定しています。

一致するインシデントには 2 つのサービスへの参照があるため、照会では関連するエンティティーのみがフィルタリングされます。

サービスを検索すると、そのサービスを含むインシデントのみが表示されます。

Instana Luceneのクエリ構文を使用して、アプリケーションコンポーネントにマッピングされた用語とブール演算子から複雑なクエリを構築します。 フリー・テキスト検索、タグ・フィルタリング、CPU カウント照会など、さまざまな照会タイプがサポートされています。 検索バーは、ストリングの残りの部分から有効な個々の用語を自動的に強調表示することによって、照会を作成する際にユーザーを補佐します。 さらに、フリー・テキスト照会 and をブール演算子 ANDと混同するなど、一般的なストリング構文の落とし穴を回避することもできます。

Lucene 照会で使用される形式は、実装環境によって異なります。 Instana では、すべてのクエリはフィールドからフィールド修飾子へ、そして量指定子へと順に進みます。 両方のフィールド値はピリオドで区切られ、数量詞はコロンで区切られます。 例えば、アプリケーション内のすべての Tomcat インスタンスをフィルタリングする場合は、検索バーで照会 entity.type: tomcat を使用します。 Instana 「tomcat」というラベルが付いたエンティティ以外はすべて表示から除外します

entity.type:tomcat 照会は、ただ 1 つの照会句です。 必要なものを正確に示す柔軟で複雑なフィルターを作成するには、さまざまな照会句をブール演算子 ( AND、 OR、 NOTなど) とともにストリング化します。 以下の例を参照してください。

AND 演算子は、デフォルトの結合演算子です。 そのため、2 つの用語の間にブール演算子が使用されていない場合は、 AND 演算子が使用されます。

例えば、 entity.type:tomcat event.state:open は entity.type:tomcat AND event.state:openと同等です。 ブール演算子が使用されない場合に 演算 AND 子を使用することは、デフォルト OR で を使用する Lucene の標準仕様とは異なります。

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"
 

ダイナミック・フォーカス検索バーは、検索フィールドのオートコンプリートをサポートし、入力中に Lucene 照会条件を強調表示します。 クエリー用語を入力すると、検索バーは現在の入力に一致する検索フィールドを提案する。 Lucene 構文のコマンドがない場合は、自動ヘルプが表示されます。 検索バーの下のドロップダウン・リストに表示されるすべての照会プロポーザル。 必要な提案が表示されている場合は、矢印キーを使用してその提案をクリックするか、その提案に移動します。

Instana の検索機能は即時検索に対応しており、検索条件を入力するとすぐに結果が表示されます。 また、フィルターを保存、編集、および削除して、ワークフローを高速化することもできます。

二重引用符 ("") 内でのワイルドカード (*) の使用 期待される結果が得られません。

この場合、 * 記号はワイルドカードとしてではなく文字として評価されるため、一致するものは返されません。 Lucene 仕様によると、句照会での単一文字および複数文字のワイルドカード検索はサポートされていません。 句照会は、 event.text:"something bad happened"のように、二重引用符で囲まれた単語のグループです。

クエリ entity.service.name でワイルドカード（*）を使用しても、期待した結果が得られません。

アスタリスク（*）はワイルドカードとしてではなく文字として扱われるため、クエリは結果を返さなかった。 この entity.service.name クエリは内部で「 contains 」演算子を使用して、一致するサービスを検索します。 たとえば、この entity.service.name:proxy クエリは「 proxy」 という名前を含むすべてのサービスを返します。

検索結果のカウントが表示されますが、これは矛盾しているようです。

場合によっては、結果カウントが混乱することがあります。 例えば、インフラストラクチャー・マップ内で検索する場合、ビュー内の検索は、インフラストラクチャー・マップに表示されないサービスなどのビュー内で表示されるものよりも多くのエンティティーに一致する可能性があります。

検索照会でフィールドを指定しない場合、どのフィールドが検索されますか?

検索照会でフィールドを指定しない場合、Dynamic Focus は現在のコンテキストを対象として、意味のある結果を提供します。 つまり、インフラストラクチャー・マップ・ビューではエンティティー・フィールドが検索され、イベント・ビューではイベント・データが検索されます。

entity.selfType と entity.type の違いは何ですか?

entity.selfType を使用して検索すると、検索結果が検索対象のエンティティーに制限されます。 entity.type での検索には、検索対象のエンティティーのすべての子が含まれます。 例えば、 entity.selfType:hostで検索する場合、インフラストラクチャー・マップには、ホスト・エンティティーとすべての親エンティティー (ゾーンなど) のみが表示されます。 ただし、 entity.type:hostを使用して検索する場合、検索結果には、Web サーバーやデータベースなど、ホスト上で実行されているものが含まれます。 ただし、 entity.type と entity.selfType の両方とも、アプリケーション・パースペクティブのエンティティー・タイプについては同じ結果になります。 例えば、イベント・ビューで entity.type:endpoint 照会を使用すると、エンドポイント・エンティティーで検出されたイベントのみがリストに含まれます。