Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの目次
 

IBAプローブでのカスタムテレメトリデータの使用

概要 このトピックでは、IBAプローブを作成し、異常を検出して参照用に履歴データベースに保存する方法について説明します。

このチュートリアルでは、デバイスから収集するデータを定義するカスタム テレメトリ コレクター サービスを作成しました。次に、このデータをブループリントのIBAプローブに取り込み、Apstraがデータを視覚化して分析できるようにします。

プローブの作成

まず、展開したブループリントに新しいプローブを作成し、Apstraがカスタムテレメトリコレクターからデータを取り込めるようにします。この例では、BFDセッションデータを視覚化し、セッションがダウンしたときに異常(アラート)を生成するというシンプルなユースケースのための最小限の設定セットに焦点を当てます。
メモ：

データセンターとFreeformの両方のブループリントが、カスタムテレメトリコレクションを備えたIBAプローブをサポートしています。
  1. ブループリントから Analytics > プローブに移動し、「プローブを作成」>「新規プローブを作成」をクリックします。
  2. 名前と(オプションの)説明(この例では BFD-Example-Probe)を入力し、[プロセッサの追加] をクリックします。
  3. プロセッサの種類を選択します。
    この例では、 拡張サービス データ コレクター プロセッサを選択しました。
  4. [追加(Add)] をクリックして、プロセッサをプローブに追加します。
    各プロセッサの詳細については、 Juniper Apstraユーザーガイドを参照してください。
  5. [作成(Create)] をクリックしてプローブを作成し、テーブル ビューに戻ります。
  6. [グラフ クエリ] フィールドの右側にある [定義済みグラフ クエリの選択] ボタンをクリックし、[定義済みクエリ] ドロップダウンから [DC – すべての管理対象デバイス (任意のロール)] を選択します。
    このクエリは、テレメトリ コレクションが実行されるブループリント内のスコープを決定します。つまり、ブループリント内のデバイスがグラフ クエリと一致しない場合、そのデバイスのテレメトリ収集サービスは開始されません。

    グラフクエリは、ブループリントのグラフデータベース内のすべてのシステムノードに特に一致します。リーフ スイッチやスパイン スイッチなどの各管理対象デバイスは、グラフにノードとして表示されます system 。

    上記で選択した定義済みクエリでは、クエリは、デプロイ モードでは 、accessspineまたは superspineのロールleafを持つ タイプのsystemすべてのノードと一致します。

  7. [更新] をクリックしてテーブル ビューに戻ります。
  8. システム ID フィールドに、 と入力しますsystem.system_id。
    このエントリは、グラフクエリが( name='system’)という名前の system管理対象デバイスで一致することをプローブに伝えます。
    各システム ノードの属性 system_id は、各デバイスのシステム ID を参照します。この属性は、Apstraが各デバイスを一意に識別するために使用します。
  9. [サービス名] ドロップダウンから [BDF] を選択します。
  10. [データ型] を選択します。

    • テレメトリ サービスが値の種類として収集stringする場合は、[ダイナミック テキスト] を選択します。

    • サービスが値の種類として収集integerする場合は、[動的番号] を選択します。

    この例では、BDF セッション状態に文字列値 Up と Down が含まれているため、ダイナミック テキストを選択しました。

  11. 「プローブの作成」をクリックします。
  12. データ・コレクター・ プロセッサーの出力ステージに移動して、プローブがカスタム・テレメトリー・コレクターからデータを正しく取り込んでいることを確認します。
    おめでとう！プローブが正常に作成されました。

プローブのカスタマイズ

ここまでで、ネットワーク内のすべてのデバイスのBFD状態を収集する実用的なプローブを作成しました。それでは、プローブを微調整するための便利なカスタマイズオプションをいくつか見ていきましょう。

サービス間隔

サービス間隔によって、テレメトリ収集サービスがデバイスからデータをフェッチしてプローブに取り込む頻度が決まります。

サービス間隔は、過度に積極的な間隔はデバイスに過度の負荷をかける可能性があるため、注意すべき重要なパラメーターです。最適な間隔は、収集するデータによって異なります。例えば、数千のエントリーを含む大規模なルーティングテーブルのコンテンツをフェッチするコレクターは、少数のBFDセッションのステータスを収集するよりも高い負荷を発生させる可能性があります。

クエリ タグ フィルター

もう 1 つの便利なカスタマイズ オプションは、 クエリ タグ フィルターです。ブループリント内の一部のスイッチを、特定の監視ユースケースの ストレージ としてタグ付けしたとします。次の例に示すように、このフィルターを構成して、一致するタグを持つデバイスでのみテレメトリ収集を実行できます。

カスタムテレメトリコレクターからの生データを表示すると、生データのみが表示されるため、それがネットワークの状態が正常か異常かを判断するのが難しい場合があります。Asptraを使用すると、異常が検出されたときに事前に通知されます

パフォーマンス分析

IBAプローブは、分析パイプラインとして機能します。すべてのIBAプローブには、パイプラインの開始時に少なくとも1つのソースプロセッサがあります。この例では、カスタム テレメトリ コレクターからデータを取り込む 拡張サービス データ コレクター プロセッサを追加しました。

プローブ内の追加のプロセッサを連鎖させて、データに対して追加の分析を実行し、ネットワークの正常性に関するより有意義な洞察を提供できます。これらのプロセッサは 、分析プロセッサと呼ばれます。

分析プロセッサを使用すると、データを集計してロジックを適用し、異常を発生させるための意図した状態 (または参照状態) を定義できます。たとえば、未加工のテレメトリ データの瞬時値ではなく、集計や傾向に関心がある場合があります。

分析プロセッサは、平均、最小/最大、標準偏差の計算などの情報を集約します。次に、集計データを期待値と比較して、データが指定された範囲内にあるかどうかを特定できます。範囲外の場合は、異常が発生します。また、この異常が一定期間持続し、特定のしきい値を超えているかどうかを確認することもできます。異常値にフラグが付けられるのは、一過性または一時的な状態と見なされる異常値のフラグ付けを回避するために、しきい値を超えた場合のみです。これは、Time_In_State プロセッサを構成することで実現できます。

表 1 に、さまざまなタイプの分析プロセッサーを示します。

表 1: 分析プロセッサ

プロセッサの種類

説明

レンジプロセッサー

プロセッサ名: 範囲、状態、Time_In_State、Match_String

範囲プロセッサは参照状態を定義し、異常を生成します。

プロセッサーのグループ化

プロセッサ名: Match_Count、Match_perc、Set_Count、合計、平均、最小、最大、およびStd_Dev

グループプロセッサは、レンジプロセッサに供給する前にデータを集約して処理します。これらのプロセッサは次のことができます。

  • プロトコル状態のデバイスごとの数を生成します。

  • ファブリック上の合計を表すために、複数のデバイスからカウンターの合計を生成します。

マルチ入力プロセッサ

プロセッサ名: Match_Count、Match_perc、Set_Count、合計、平均、最小、最大、およびStd_Dev

分析プロセッサは、複数のステージから入力を受け取ります。これらのプロセッサは次のことができます。

  • 複数のステージからの入力の和集合である単一の出力データ・セットを作成します。

  • 複数のステージからの入力間の論理比較を実行します。

すべての分析プロセッサの詳細については、 Juniper Apstraユーザーガイドの プローブプロセッサ(分析) を参照してください。

メモ：

複数入力プロセッサは、動的データ型 (動的テキストまたは動的数値) ではサポートされていません。これらのプロセッサは、通常、カスタムテレメトリコレクションを活用するIBAプローブに使用されます。

次のセクションでは、異常を検出して発生するように BFD サンプル プローブを構成します。

異常の発生と履歴データの保存

次に、BDF セッションがダウンした場合に異常を検出して発生するようにサンプル プローブを構成します。その後、参照用に異常を履歴データベースに保存します。
  1. 「プローブの作成」で作成したプローブに 2 つ目のプロセッサを追加し、[プロセッサの追加] をクリックします。
  2. [一致カウント] プロセッサを選択し、プロセッサにわかりやすい名前 (たとえば、ダウン セッション数) を付けます。
    一致カウントプロセッサは、ダウン状態の BFD セッションの数をカウントし、デバイスごとにカウントをグループ化します。
  3. 2 番目のプロセッサを構成します。
    このプロセッサは、前のプロセッサからのデータが相互に供給されるようにプローブ パイプラインを構成します。
    「参照状態」フィールドに 「下」と入力します。
    プローブを更新すると、出力には各デバイスによる ダウン 状態の BFD セッションの数が表示されます。
  4. 3 つ目のプロセッサを追加します。
    次に、3 番目の最後のプロセッサを追加します。このプロセッサは、ダウン状態の BFD セッションが 1 つ以上ある場合に警告する異常を生成します。
  5. 「プロセッサーの追加」をクリックし、「マッチ・カウント」プロセッサーを選択します。
    プロセッサにわかりやすい名前 ( たとえば、BFD 異常 (ダウン > 0)) を付け、[ 追加] をクリックします。
  6. プロセッサを設定します。

    1. 入力ステージ - ステージ名を入力し、列名の値を選択します。この例では、ステージ名をダウンセッション数として定義しました。

    2. [ 異常範囲] を [次の 値 と等しい] および [1] に設定します。

    3. [ 異常の発生] をクリックします。

  7. プローブ構成インターフェースで、「メトリック・ロギングの使用可能化」をクリックし、2 番目のプロセッサーの出力ステージを選択します。
    このアクションにより、データの履歴ログ記録が有効になります。
  8. [プローブの更新] をクリックします。
    ダウン状態の BFD セッションがある場合、プローブは BDF セッションの異常を生成します。
  9. プローブ構成で [ストリーミングを有効にする] をオンにします。
  10. 最後に、[データ ソース: 時系列] ビューを選択して、このステージによって監視されるデータ値の変更履歴を表示します。