オンボックスアグリゲーションの概要
ジュニパーのデバイスは、オンボックスアグリゲーションをサポートしています。インターフェイス、CoS、MPLS、AF、AEの各カウンターがジュニパーのデバイスで集約され、テレメトリデータがコレクターにストリーミングされます。カウンターがコレクターにストリーミングされ、そこで集約されるオフボックス集約と比較して、オンボックス集約は、ラインカードのリセットやLAGメンバーシップの変更などのシステムイベントを認識するより正確なテレメトリデータを提供します。オンボックスアグリゲーションにより、コレクターでの生産エラーが減少します。また、データが従量制課金される特定のクラウドベースの環境では、テレメトリ データ帯域幅の全体的な使用量も大幅に削減されます。
集計ロジック
データ集約とは、na-grpcd デーモンで Google protobuf メッセージとして受信したすべてのパケット転送エンジンインスタンスから与えられたカウンタ値を簡単に加算することです。na-grpcd デーモンのアグリゲーションモジュールは、受信したサブスクリプションリクエストに基づいて、複数のパケット転送エンジンからの統計をキャッシュします。キャッシュは、受信したサブスクリプションごとに実行されます。
データ集計には、次の点が適用されます。-
統計データがゲージ タイプの場合、フィールド値は 、
MaxまたはMinのいずれかになりAverage、集計モジュールはゲージ タイプのフィールド値に基づいて集計を順序付けします。 -
集計は、YANG ファイルで注釈が付けられたカウンター データ型とゲージ データ型の両方に対して行われます。
- キャッシュには、特定のパケット転送エンジンのデータソースはいつでも1つしかありません。新しいエントリは、既存のキャッシュを上書きします。
-
個別のタイマーがデータを集約またはストリーミングすることはありません。パケット転送エンジンからサンプルデータを受信するたびに、集約とストリーミングの時間が、以前に送信された集約されたタイムスタンプでチェックされます。例えば：
-
-
現在のタイムスタンプ – 以前に集計されたタイムスタンプ> reporting_interval
-
-
エクスポートタイムスタンプには、集計データのタイムスタンプの中央値が記載されます。
-
na-grpcd デーモンでのレコード・キャッシングは、サブスクリプションが有効な (アクティブ) 間のみ使用可能です。サブスクリプションが非アクティブの場合、エクスポートされた集約テレメトリ データは、ルーティング エンジンのコマンド ライン インターフェイスの統計情報と一致しない場合があります。次のトリガーにより、この不一致が発生する可能性があります。
-
子メンバーが集合型インターフェイスの一部である 1 つ以上の FPC の再起動。
-
集合型インターフェイスから最大 n-1 個の子メンバー(少なくとも 1 つの子リンクがアクティブ)の削除。
-
-
最後に、サブスクリプションが削除されると、関連付けられているキャッシュも削除されます。
gNMI または gRPC ストリームでは、ルーティング エンジンからの最初のインターバルが複数の FPC から 1 つのサンプルしか受信していない可能性があるため、最初のサンプルに集約された統計カウンター値が含まれない場合があります。ただし、2 番目の間隔以降、ストリームにはすべての FPC から受信した集計カウンター値が含まれます。
サンプルの集計は、受信サンプルの 1 つに基づいてトリガーされます。 図1に示すように、サンプルS2は遅延している。この遅延のため、A2 集計では、サンプルのタイムスタンプの中央値を持つ古い t0 サンプルが使用されます。これには t1' というラベルが付けられます (実際には t1 です)。
の集計
パケット転送エンジンのデータエクスポート
アグリゲーション機能は、基本的な protobuf ベースのテレメトリ インターフェイスに依存して、パケット転送エンジンからデータをエクスポートします。protobuf ベースのテレメトリ ストリームは、エクスポートするデータを TelemetryStream と呼ばれる共通の最上位レベルのエンベロープにカプセル化します (以下を参照)。
message TelemetryStream {
// router hostname
// (or, just in the case of legacy (microkernel) PFEs, the IP address)
required string system_id = 1 [(telemetry_options).is_key = true];
// line card / RE (slot number)
optional uint32 component_id = 2 [(telemetry_options).is_key = true];
// PFE (if applicable)
optional uint32 sub_component_id = 3 [(telemetry_options).is_key = true];
// configured sensor name
optional string sensor_name = 4 [(telemetry_options).is_key = true];
// sequence number, monotonically increasing for each
// system_id, component_id, sub_component_id + sensor_name.
optional uint32 sequence_number = 5;
// timestamp (milliseconds since 00:00:00 UTC 1/1/1970)
optional uint64 timestamp = 6 [(telemetry_options).is_timestamp = true];
…
}
このトップレベルエンベロープは、 コンビネータと呼ばれる操作でパケット転送エンジン統計キャッシュを構築するために必要な情報を提供します。コンビネータは、共通のインターフェース ID とキュー ID を持つ複数のデータ・インスタンスに対して論理結合を実行し、システム全体に集約された出力キュー統計を生成します。すべての受信 protobuf は、 テレメトリストリーム protobuf のセンサー、コンポーネント、およびパケット転送エンジン スロット フィールドを使用してキャッシュに編成されます。コンビネータは、特定のセンサーのパケット転送エンジンからの最新のprotobufエクスポートをキャッシュすることにより、パケット転送エンジンごとのインスタンスデータを追跡します。バイナリ protobuf を集約単位として使用すると、protobuf 内に含まれるカウンターのコレクションごとにキャッシュとブックキーピングのオーバーヘッドが最小限に抑えられます。
パケット転送エンジンからエクスポートされたテレメトリデータのタイムスタンプが、集計データの計算をトリガーします。前回の集計データのエクスポートからの経過時間がセンサーの更新間隔を超える場合は、新しい集計値がエクスポートされます。この新しい値は、集計値のエクスポートをトリガーした最後のパケット転送エンジンサンプルのタイムスタンプを使用します。この方法では、集計データを取得するためにコンビネータ内でセンサーごとのタイマーを実行する必要がなくなります。また、パケット転送エンジンから最後に受信したデータをキャッシュすることで、エクスポートされた集約データの「ドリフト」を最小限に抑えることができます。これは、パケット転送エンジンのエクスポートの遅延や、パケット転送エンジンからのさらなるエクスポートを妨げる可能性のある運用上の変更などの場合に特に役立ちます。
集計データサンプルの識別
集計されたサンプルは、 という値 na-grpcdと一致するヘッダーフィールドによって識別できます。na-grpcd デーモンは、集約されたデータを生成します。
system_id: r1q13dep
component_id: 65535
sensor_name: sensor_1004_1_1
subscribed_path: /interfaces/interface/subinterfaces/subinterface/
streamed_path: /interfaces/interface/subinterfaces/subinterface/
component: na-grpcd
sequence_number: 2097152
export_timestamp: 1663783826926
update {
timestamp: 1663783826901000000
prefix: /interfaces/interface[name='ge-1/0/0']/subinterfaces/subinterface[index='16386']
update {
path {
elem {
name: init-time
}
}
val {
uint_val: 1663780730
}
}
使用上のヒント
オンボックス集計を使用する場合は、次の考慮事項に注意してください。
-
パケットとバイトレートの計算は、集約された統計タイムスタンプメッセージに基づいています。タイムスタンプメッセージは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/queues/queue/state/
-
/interfaces/interface/state/counters/
-
/interfaces/interface/subinterfaces/subinterface/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データモデルエクスプローラ を参照してください。