Junos Telemetry データの集約に関するガイドライン
Junos Telemetry の重要な機能の 1 つは、データ処理がデバイスではなく、データをストリーミングするコレクターで行われることです。データは自動的には集計されませんが、分析のために集計することはできます。
データ集計は、次のシナリオで役立ちます。
例えば、30秒間隔における物理インターフェイスイングレスエラーの平均数など、一定期間にわたる同じメトリックのデータ。
ラベルスイッチパス(LSP)統計情報やフィルターカウンター統計など、同じメトリックの異なるソース(複数のラインカードなど)からのデータ。
集合型イーサネットインターフェイスの入出力統計など、複数のソースからのデータ。
次のセクションでは、さまざまなシナリオでデータ集計を実行する方法について説明します。これらのセクションの例では、InfluxDB 時系列データベースを使用して、テレメトリデータに対するクエリを受け入れます。InfluxDB は、時系列データを処理するために Go で記述されたオープンソースのデータベースです。
固定された期間にわたるデータの集計
一定期間にわたって同じメトリックのデータを集計することは、傾向を検出するための一般的で便利な方法です。メトリックには、ゲージ、つまり単一の値または累積カウンターを含めることができます。また、データを継続的に集計することもできます。
例: ゲージ・メトリックのデータの集計
この例では、port.proto からのJuniperNetworksSensors.jnpr_interface_ext.interface_stats.egress_queue_info.current_buffer_occupancyのデータが、ホスト名、インターフェイス名、対応するキュー番号、および current_buffer_occupancy と呼ばれる単位を識別するタグを使用して、InfluxDB データベースに書き込まれます。この例で使用されている特定の値については、表 1 を参照してください。
| タイム スタンプ (秒) |
価値 |
タグ |
|---|---|---|
| 1458704133 |
1547 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
| 1458704143 |
3221 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
| 1458704155 |
4860 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
| 1458704166 |
6550 |
queue_number=0,interface_name='xe-1/0/0',host='sjc-a' |
各測定データポイントには、タイムスタンプと記録された値があります。この例では、タグ queue_number がインターフェイスキューの数値識別子です。
このデータを 30 秒間隔で集計するには、次の influxDB クエリを使用します。
select mean(value) from current_buffer_occupancy where time >= $time_start and time <= $time_end and queue_number=’0’ and interface_name=’xe-1/0/0’ and host=’sjc-a’ group by time(30s)
$time_startと$time_endには、実際の時間範囲を指定します。
例: 累積統計のデータの集計
一部のJunos Telemetry Interfaceセンサーは、 JuniperNetworksSensors.jnpr_interface_ext.interface_stats.ingress_stats.packetsとして定義されたイングレスパケットの数などの累積カウンター値を報告します。
通常、パケット カウンターまたはバイト カウンターからトラフィック レートを取得します。ゲージ メトリックとは異なり、累積カウンターの系列の最初のデータ ポイントは、ベースラインを設定するためにのみ使用されます。
次のガイドラインを使用して、累積統計のデータベース問合せを作成します。
-
特定の時間間隔の累積値を計算します。時間間隔中に記録された複数のデータポイント間の平均を計算するか、値を補間することができます。すべてのデータポイントは、同じ系列に属している必要があります。異なる時間に報告された 2 つのデータ ポイント間でカウンター リセットが発生した場合は、両方のデータ ポイントを使用しないでください。
-
前の時間間隔の適切な値を決定します。前回の更新以降にカウンターがリセットされた場合は、その値を unavailable として宣言します。
-
前の間隔が使用可能な場合は、データポイントとトラフィックレートの差を計算します。
これらのガイドラインは、次の influxDB クエリにまとめられています。このクエリは、データが測定 ingress_packetsに格納されていることを前提としています。クエリでは、ゲージ メトリックの例と同じタグと、カウンターの初期化時間 init_time のタグを使用します。クエリでは、30 秒の時間間隔の平均値が使用されます。これは、同じカウンター初期化を持つメトリックのレートを計算します。
select non_negative_derivative(mean(value)) from ingress_packets
where time >= $time_start and time <= $time_end and
interface_name=’xe-1/0/0’ and host=’sjc-a’
group by time(30s), init_time
次のクエリを使用して、レートを導出せずに、一定時間間隔で受信したパケット数を計算します。
select difference(mean(value)) from ingress_packets where time >= $time_start and time <= $time_end and interface_name=’xe-1/0/0’ and host=’sjc-a’ group by time(30s), init_time
場合によっては、特定の時間間隔で複数の集計データポイントがクエリによって返されます。たとえば、時間間隔で 4 つのデータ ポイントを使用できます。2 つのデータ ポイントにはinit_time t0があり、他の 2 つのデータ ポイントにはinit_time t1があります。init_time ではなく最終変更タイムスタンプタグ last_change を使用するクエリを実行して、差を計算し、同じ最終変更タイムスタンプを持つ 2 つのデータポイント間のレートを導き出すことができます。
select difference(mean(value)) from ingress_packets
where time >= $time_start and time <= $time_end and
interface_name=’xe-1/0/0’ and host=’sjc-a’
group by time(30s), last_change
これらのクエリはすべて連続クエリとして実行でき、新しい時系列測定値を定期的に入力できます。
複数ソースからのデータの集約
特定のメトリックは、複数のラインカードまたはパケット転送エンジンから報告されます。以下のシナリオでは、さまざまなソースから派生したデータを集計すると便利です。
-
ラベルスイッチパス(LSP)のパケット数とバイト数は、各ラインカードで個別に報告されます。ただし、パス計算要素コントローラには、デバイス全体のLSPパスのビューが必要です。
-
仮想出力キューをサポートするデバイスの場合、各キューのテールドロップまたはランダム早期検出ドロップの統計情報は、各物理インターフェイスの各ラインカードによって個別に報告されます。インターフェイスのすべてのラインカードの統計を集約できると便利です。
-
転送テーブルまたは集合型イーサネットインターフェイスにアタッチされたファイアウォールフィルターのフィルターカウンターは、各ラインカードで個別に報告されます。すべてのラインカードの統計情報を集約すると便利です。
複数のソースからデータを集計するには、次の手順を実行します。
各ソースの特定の期間のデータ(各ラインカードなど)を集計します。
ステップ 1 で各ソースについて派生したデータを集計します。
InfluxDB データベースに保存されているデータの場合、連続クエリを実行し、新しい測定値を入力することで、手順の ステップ 1 を完了できます。各ソースに従ってデータ ポイントをグループ化することを強くお勧めします。たとえば、LSP 統計情報の場合、gpb メッセージ内の component_id は、データを送信するラインカードを識別します。一意の各 component_idに基づいてデータポイントをグループ化します。
例: 複数ソースからのデータの集計
この例では、2つのクエリーを実行して、すべてのラインカードからのデータのLSPパケットレートを導き出します。
まず、各 component_id タグと counter_name タグの lsp_packet_count という名前の測定に対して、次の連続クエリを実行します。一意のcomponent_idタグは、それぞれ異なるラインカードに対応しています。このクエリは、新しい測定値lsp_packet_rate.
select non_negative_derivative(mean(value)) as value from lsp_packet_count into lsp_packet_rate group by time(30s), component_id, counter_name, host
LSP 統計センサーは、カウンターの初期化時間を報告しません。
この連続クエリから派生した新しい測定値(lsp_packet_count)を使用して、 lsp-sjc-den-1 という名前の LSP のパケットレートに関するすべてのラインカードからのデータを集約する次のクエリを実行します。
select sum(value) from lsp_packet_rate where counter_name=’lsp-sjc-den-1’, host=’sjc-a’
このクエリは、 component_id タグまたはラインカードに従ってデータをグループ化しないため、すべてのコンポーネントまたはラインカードからの LSP パケットレートが返されます。
複数のメトリックのデータの集計
複数の値のメトリックを集計すると便利です。例えば、集合型イーサネットインターフェイスの場合、通常、各インターフェイスメンバーのパケットレートとバイトレート、および集約されたリンクのインターフェイス利用率を追跡したいと思われます。
例: 複数のメトリック値の集計
この例では、次の 2 つのクエリを実行します。
-
集約されたイーサネットインターフェイスの各メンバーリンクのingressパケットカウントを導き出すための継続的なクエリ
-
同じ集約されたイーサネットインターフェイスに属するすべてのメンバーリンクのパケットカウントデータを集約するクエリ
次の連続クエリーは、集約されたイーサネットインターフェイス内の各メンバーリンクの測定値 ingress_packetsを導き出します。 interface_name タグは、各メンバーインターフェイスを識別します。また、 parent-ae-name タグは、特定の集合型イーサネットインターフェイスのメンバーシップを識別するためにも使用します。各メンバーリンクを parent-ae-name タグでグループ化することで、現在のメンバーリンクについてのみデータが収集されるようになります。例えば、レポート間隔中にインターフェイスのメンバーシップが変更される場合があります。メンバーインターフェイスを特定の集合型イーサネットインターフェイスでグループ化すると、そのメンバーリンクのデータは、現在メンバーとなっている新しい集約型イーサネットインターフェイスに転送されません。
select difference(mean(value)) as value from ingress_packets
into ingress_packets_difference
group by time(30s), component_id, interface_name, host, parent-ae-name
次のクエリは、集合型イーサネットインターフェイス、つまりすべてのメンバーリンクのイングレスパケットのデータを集約します。
select sum(value) from ingress_packets_difference
where parent-ae-name=’ae0’ and host=’sjc-a’
このクエリは、集約されたイーサネットインターフェイス ae0のデータを集約します。 parent-ae-name タグは、実際のメンバーリンクを検証しません。