プローブ
IBAプローブの概要
プローブはインテントベース分析の抽象化の基本ユニットです。一般的に、特定のプローブはネットワークから何らかのデータセットを消費し、それに対してさまざまな連続する集計と計算を行い、必要に応じて、アノーマリを発生させる集約と計算の一部の条件を指定します。
プローブは、グラフのノードがプロセッサとステージである方向付け非環グラフ(DAGs)です。ステージは、コンテキストに関連付けられたデータであり、オペレーターが検査できます。プロセッサーは、入力データからの出力データを生成して削減する一連の操作セットです。プロセッサーへの入力は 1 ステージまたは多ステージで、プロセッサーからの出力も 1 ステージまたは多ステージです。プローブAGG内のエッジの方向性は、この入力から出力までのフローを表しています。
重要なのは、プローブ内の初期プロセッサーは特殊で、入力ステージを持たないということです。それらは概してデータの発電機である。これらをソースプロセッサーと呼んでいます。
IBAは、コレクターから生のテレメトリを取り込み、プローブに取り込み、知識(異常、アグリゲーションなど)を抽出することで機能します。特定のコレクターがテレメトリをメトリックの集まりとして公開し、各メトリックには ID(単位と値のペアのセット)と値が設定されます。IBAプローブは、グラフクエリを使用することがよくありますが、プローブにその値を取り込むには、メトリックのIDを完全に指定する必要があります。この機能を使用すると、プローブは、インジェストフィルターを使用して、アイデンティティの部分的な仕様でメトリックを取り込み、未知のIDを持つメトリックの取り込みを可能にします。
一部のプローブは自動的に作成されます。これらのプローブは自動的に削除されません。これにより、運用と実装の面でシンプルな運用が維持されます。
プロセッサ
プローブの入力プロセッサは、未加工のテレメトリをプローブに取り込むのに必要な設定を処理し、データ処理パイプラインを開始します。これらのプロセッサーの場合、ステージ出力項目の数 (1 つまたは複数) は、指定されたグラフ照会の結果の数と等しくなります。例えば、複数のグラフ照会が指定されている場合などです。 graph_query: [A, B]、クエリAは5ノードに一致し、クエリーBは10ノードに一致し、クエリAの結果は0から4のインデックスを使用 query_result し、クエリBの結果は5~14のインデックスを使用してアクセスできます。
プロセッサーの入力タイプおよび/または出力タイプが指定されていない場合、プロセッサーは in と呼ばれる単一の入力を受け取り、 out と呼ばれる単一の出力を生成します。
一部のプロセッサー・フィールドは 式と呼ばれます。 グラフクエリ であり、非常に知られている場合があります。それ以外の場合は、値 を生成するPython式 です。例えば、累積プロセッサーでは、長さを秒の整数として、例えば 900、または式 60 * 15として指定することができます。ただし、式の方が便利です。パラメータ化する方法は複数あります。
式は、文字列値をサポートしています。文字列であり、式をサポートするプロセッサ構成パラメーターでは、静的値を指定する際に特別なクォートを使用する必要があります。たとえば、 state: "up" 静的文字列ではなく「up」変数を参照するため、無効です state: '"up"'。
式はグラフ クエリに常に関連付けされ、そのクエリの結果の一致ごとに実行されます。式の実行コンテキストは、クエリで指定されたすべての変数が、関連する一致結果の名前付きノードに解決されるようなものです。詳細については、 サービス データ コレクターの例を 参照してください。
グラフベースのプロセッサは、query_tag_filterで拡張され、グラフクエリ結果をタグでフィルタリングできるようになりました(バージョン4.0の新機能)。IBAプローブでは、特にECMP不均衡(外部インターフェイス)プローブと総東西トラフィックプローブに対して、サーバーと外部ルーターのフィルター基準としてのみタグが使用されます。特定のプロセッサ情報については、「参照」セクションの 「プローブ プロセッサ 」を参照してください。
取り込みフィルター
「インジェスト フィルター」を使用すると、1 つのクエリ結果で複数のメトリックをプローブに取り込むことができます。テーブルデータタイプは、単一ステージの出力項目の一部として複数のメトリックを格納するために使用されます。表のデータ・タイプには、既存のタイプに対応するために 、 、 、 dssts それぞれが含まれますtable_nstable_dsstable_ts。 ns
IBA収集フィルター
収集フィルターは、ターゲット デバイスから収集されるメトリックを決定します。
特定のデバイス上の特定のコレクターのコレクション フィルターは、さまざまなプローブに存在する単なる取り込みフィルターのコレクションです。IBAまたはプローブのコンテキスト外でサービスを有効にする一環として指定することもできますが、サービス有効化の既存の優先度ルールはここで適用されます。指定された優先度レベルのフィルターのみが集約されます。複数のプローブが特定のデバイス上の特定のサービスをターゲットとする取り込みフィルターを指定した場合、収集されたメトリックは共用体(つまり、メトリックがフィルターのいずれかに一致すると)が公開されます。そのため、データはIBAプローブに取り込む前に、コントローラーコンポーネントによってもフィルタリングされます。
このフィルターはテレメトリ コレクターによって評価され、多くの場合、利用可能なメトリックのサブセットが基になるデバイス オペレーティング システムから取得されても、より優れた制御を行います。例えば、膨大な数のルートをすべて取得するのではなく、ルートのサブセットのみを取得する場合。いずれの場合も、収集フィルターに一致するメトリックのみが未加工のテレメトリとして公開されます。
デバイスでサービスを有効にする一環として、サービスの収集フィルターを指定できるようになりました。このフィルターは、「self.service_config.collection_filters」の一部としてコレクターに提供される追加入力になります。
IBAフィルター形式
フィルター(取り込みと収集)の設計/使いやすさの目標を以下に示します。
- 作成のしやすさ - 特定のプローブの著者がこれを特定
- ほとんどの場合、任意のケースが一致し、可能な値の特定のリストと一致する、等しい一致、キーに数値が含まれていないかどうかの範囲チェック。
- 効率的な評価 - 収集または取り込みのホット パスでフィルターが評価される場合。
- 集約可能 - 複数のフィルターが集約されるため、この集約論理が個々のコレクターの責任になる必要はありません。
- プログラミング言語ニュートラル - フィルターで動作するコンポーネントは、Python や C++ またはその他の言語で使用できます。
- Programmable - 使いやすさやパフォーマンスなどを向上させるために、コントローラ自体やコレクターによって、フィルターに関する将来のプログラマビリティに対応できます。
上記の目標を考慮して、以下に、フィルタ1について示唆され、具体的なスキーマを示す。詳細については、取り込みフィルターのセクションを参照してください。
FILTER_SCHEMA = s.Dict(s.Object(
'type': s.Enum(['any', 'equals', 'list', 'pattern', 'range', 'prefix']),
'value': s.OneOf({
'equals': s.OneOf([s.String(), s.Integer()]),
'list': s.List(s.String(), validate=s.Length(min=1)),
'pattern': s.List(s.String(), validate=s.Length(min=1)),
'range': s.AnomalyRange(), validate=s.Length(min=1),
'prefix': s.Object({
'prefixsubnet': s.Ipv6orIpv4NetworkAddress(),
'ge_mask': s.Optional(s.Integer()),
'le_mask': s.Optional(s.Integer()),
'eq_mask': s.Optional(s.Integer())
})
), key_type=s.String(description=
'Name of the key in metric identity. Missing metric identity keys are '
'assumed to match any value'))
フィルター指定の 1 つのインスタンスは、指定されたすべてのキー(キーごとの制約)の AND として解釈されます。複数のプローブから提供される複数のフィルター仕様は、フィルタ レベルで OR と見なされます。
ここで示すスキーマは、要件を伝えるためのものであり、エンジニアリングは、指定されたユースケースを達成する方法を自由に選択できます。
コレクター プロセッサーの構成で指定additional_propertiesコレクター プロセッサーは、特別な context. 名前空間を使用してアクセスできます。たとえば、コレクターがプロパティ system_roleを定義する場合は、次のように使用できます。
duration: 60 * (15 if context.system_role == "leaf" else 10)
アイテム・コンテキストは、コレクター・プロセッサー構成から派生した元のセットから変更されていない限り、使用できます。データがこのセット(グループ化プロセッサなど)を変更するプロセッサを通過すると、使用できなくなります。
ブループリントから Analytics > Probes に移動し、プローブテーブルビューに移動します。プローブの詳細に移動するには、その名前をクリックします。プローブのインスタンス化、作成、複製、編集、削除、インポート、エクスポートが可能です。 
いくつかのプローブのステージをさまざまな方法で表示できます。たとえば、「 デバイス トラフィック」という名前のプローブをクリックすると、以下の画像が表示されます。 平均インターフェイスカウンター のデータソースを リアルタイム から 時系列 に変更すると、時系列を別のグラフ、結合グラフ(線形グラフまたは複合グラフ:積み重ねグラフ(Apstraバージョン4.0時点)として表示できます。また、各プローブで使用されているディスク容量も、該当する場合に確認できます。
Apstraコントローラのディスク容量が不十分な場合は、古いテレメトリデータファイルが削除されます。古いテレメトリデータを保持するために、 Apstra VMクラスタで容量を増やすことができます。
数十のプロセッサを搭載した非線形プローブの構造と論理は、標準的なビューでは容易に区別できません。展開ボタン(左パネルの上部)をクリックすると、プロセッサの相互関連(バージョン 4.0 の新機能)が拡大表示されます。たとえば、以下の画像は 、MLAG不均衡 プローブの拡大ビューを示しています。 