オンボックス アグリゲーションの概要

アグリゲーションロジック

データ集約とは、アグリゲーションモジュールプロセスでGoogle protobufメッセージとして受信したすべてのパケット転送エンジンインスタンスから指定されたカウンター値を単純に追加することです。アグリゲーションモジュールは、受信したサブスクリプション要求に基づいて、複数のパケット転送エンジンからの統計情報をキャッシュします。キャッシュは、受信したサブスクリプションごとに行われます。

• 統計データがゲージ タイプの場合、フィールド値は Average、 Max 、または Min のいずれかになり、集計モジュールはゲージ タイプのフィールド値に基づいて集計を並べ替えます。

• 集計は、YANG ファイルで注釈が付けられたカウンタ データ タイプとゲージ データ タイプの両方に対して実行されます。

• キャッシュで使用できる特定の パケット転送エンジン のデータ ソースは、常に 1 つだけです。新しいエントリは、既存のキャッシュを上書きします。

• データを集約またはストリーミングする個別のタイマーはありません。パケット転送エンジンからサンプルデータを受信するたびに、以前に送信された集約タイムスタンプで集計およびストリーミング時間がチェックされます。例えば：

• 現在のタイムスタンプ – 以前に集計されたタイムスタンプ> reporting_interval

• エクスポートタイムスタンプには、集計データのタイムスタンプの中央値が含まれます。

• na-grpcd デーモンのレコード・キャッシングは、サブスクリプションが有効 (アクティブ) である間のみ使用可能です。サブスクリプションが非アクティブな場合、エクスポートされた集約テレメトリ データは、ルーティングエンジンのコマンドライン インターフェイスの統計情報と一致しないことがあります。次のトリガーでは、この不一致が発生する可能性があります。

  • 子メンバーが集約されたインターフェイスの一部である1つ以上のFPCの再起動。

  • 集約インターフェイスから最大 n-1 個の子メンバー(少なくとも 1 つの子リンクがアクティブ)の削除。

• 最後に、サブスクリプションが削除されると、関連付けられているキャッシュも削除されます。

gNMIまたはgRPCストリームでは、ルーティングエンジンからの最初の間隔が複数のFPCから1つのサンプルしか受信していない可能性があるため、最初のサンプルに集約された統計カウンター値が含まれていない可能性があります。ただし、2 番目の間隔以降は、ストリームにはすべての FPC から受信した集約カウンター値が含まれます。

サンプルの集約は、受信サンプルの 1 つに基づいてトリガーされます。 図1に示すように、サンプルS2は遅延しています。この遅延のため、A2 集計では、サンプルのタイムスタンプの中央値を持つ古い t0 サンプルが使用されます。これは t1' とラベル付けされます (実際には t1 です)。

図1:サンプル間隔の集計

パケット転送エンジンのデータエクスポート

アグリゲーション機能は、基本的な protobuf ベースのテレメトリインターフェイスに依存して、パケット転送エンジンからデータをエクスポートします。protobuf ベースのテレメトリ ストリームは、 TelemetryStream と呼ばれる共通の最上位エンベロープにエクスポートするデータをカプセル化します (以下を参照)。

この最上位エンベロープは、 コンビネーターと呼ばれる操作でパケット転送エンジン統計キャッシュを構築するために必要な情報を提供します。コンビネーターは、共通のインターフェース ID とキュー ID を持つ複数のデータ・インスタンスに対して論理結合を実行し、システム全体の集約された出力キュー統計を生成します。すべての着信 protobuf は、センサー、コンポーネント、および TelemetryStream protobuf の パケット転送エンジン スロット フィールドを使用してキャッシュに編成されます。コンビネーターは、特定のセンサーのパケット転送エンジンからの最新の protobuf エクスポートをキャッシュすることで、パケット転送エンジンごとのインスタンス データを追跡します。バイナリ protobuf を集計単位として使用すると、protobuf 内に含まれるカウンターの各コレクションのキャッシュとブックキーピングのオーバーヘッドが最小限に抑えられます。

パケット転送エンジンからエクスポートされたテレメトリデータのタイムスタンプが、集計データの計算をトリガーします。前回の集計データのエクスポートからの経過時間がセンサーの更新間隔を超えると、新しい集計値がエクスポートされます。この新しい値は、集約された値のエクスポートをトリガーした最後の パケット転送エンジン サンプルからのタイムスタンプを使用します。この方法では、コンビネータ内でセンサーごとのタイマーを実行して集計データを取得する必要がなくなります。また、パケット転送エンジンから最後に受信したデータ エクスポートをキャッシュすることで、エクスポートされた集約データの「ドリフト」が最小限に抑えられます。これは、パケット転送エンジン のエクスポートの遅延や、パケット転送エンジン からのさらなるエクスポートを妨げる可能性のある運用上の変更などのインスタンスに特に役立ちます。

集計データサンプルの識別

集約されたサンプルは、値 na-grpcd を持つヘッダー フィールド コンポーネントによって識別できます。na-grpcd デーモンは、集約されたデータを生成します。

使用上のヒント

オンボックス集計を使用する場合は、次の点に注意してください。

• パケットおよびバイトレートの計算は、集約された統計タイムスタンプメッセージに基づきます。タイムスタンプメッセージは1つのルーティングエンジンで合成されますが、複数のFPCからのキャッシュデータに基づいているため、パケットとバイトレートが正確でない可能性があります。レポート間隔の構成が妥当な場合(ベストプラクティスのガイドラインによる)、精度は高くなります。

• 統計メッセージがパケット転送エンジンによってエクスポートされない場合(たとえば、運用ステータスがダウンしている場合)、集約統計はコレクターにエクスポートされません。

• AEバンドルを使用したテレメトリMPLS LSP統計では、パケットレートとバイトレートに5%の偏差があると予想されます。

サポートされているリソースパス

オンボックス集計では、次のリソース パスがサポートされています。

• /junos/system/linecard/interface/traffic/

• /junos/system/linecard/interface/queue/

• /junos/system/linecard/interface/logical/usage/

• /junos/system/linecard/cos/interface/interface-set/output/queue/

• /junos/services/label-switched-path/usage/

• /qos/interfaces/interface/output/queues/queue/state/

• /interfaces/interface/state/counters/

• /interfaces/interface/subinterfaces/subinterface/state/counters/

• /interfaces/interface/subinterfaces/subinterface/ipv4/state/counters/

• /interfaces/interface/subinterfaces/subinterface/ipv6/state/counters/

• /network-instances/network-instance/mpls/lsps/constrained-path/tunnels/tunnel/state/counters/

• /junos/system/linecard/interface/queue/(CoS ネイティブ リソース パス)

• /junos/system/linecard/qmon-sw/(CoSネイティブリソースパス)

• /qos/interfaces/interface/output/queues/queue/state/(CoS OpenConfig リソース パス)

• /qos/interfaces/interface/input/virtual-output-queues/voq-interface/queues/queue/state/(CoS OpenConfig リソース パス)

• /junos/system/linecard/interface/queue/(物理インターフェイス統計のネイティブ パス、AE インターフェイスをサポート)

• /qos/interfaces/interface/output/queues/queue/state/(AE インターフェイスをサポート)

リソースパス、サポートされているリーフ、およびそれらをサポートするデバイスプラットフォームの詳細については、 Junos YANGデータモデルエクスプローラ を参照してください。