このページの目次
Junos Telemetry Interface データの集約に関するガイドライン
Junos Telemetry Interfaceの重要な機能の1つは、デバイスではなく、データをストリーミングするコレクターでデータ処理が行われることです。データは自動的には集計されませんが、分析のために集計することはできます。
データ集計は、次のシナリオで役立ちます。
一定時間における同じメトリックのデータ(30 秒間隔における物理インターフェイスイングレスエラーの平均数など)。
ラベルスイッチパス(LSP)統計やフィルターカウンター統計など、同じメトリックに対する異なるソース(複数のラインカードなど)からのデータ。
集合型イーサネットインターフェイスの入出力統計など、複数のソースからのデータ。
次のセクションでは、さまざまなシナリオでデータ集計を実行する方法について説明します。これらのセクションの例では、InfluxDB 時系列データベースを使用して、テレメトリ データに対するクエリを受け入れます。InfluxDB は、時系列データを処理するために Go で記述されたオープンソースのデータベースです。
一定期間のデータの集計
一定の期間にわたって同じメトリックのデータを集計することは、傾向を検出するための一般的で便利な方法です。メトリックには、ゲージ、つまり単一の値、または累積カウンターを含めることができます。また、データを連続的に集計することもできます。
例: ゲージ メトリックのデータの集計
この例では、from port.proto のJuniperNetworksSensors.jnpr_interface_ext.interface_stats.egress_queue_info.current_buffer_occupancyデータが、ホスト名、インターフェース名、対応するキュー番号を識別するタグとともに current_buffer_occupancyInfluxDB データベースに書き込まれます。この例で使用される特定の値については、表 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_endには$time_start、実際の時間範囲を指定します。
例: 累積統計のデータの集計
一部の Junos テレメトリ インターフェイス センサーは、 として定義された JuniperNetworksSensors.jnpr_interface_ext.interface_stats.ingress_stats.packetsイングレス パケット数などの累積カウンター値を報告します。
トラフィックレートは、パケットカウンターまたはバイトカウンターから導き出すのが一般的です。ゲージ メトリックとは異なり、累積カウンターの系列の初期データ ポイントは、ベースラインの設定にのみ使用されます。
次のガイドラインを使用して、累積統計用のデータベース クエリを作成します。
-
特定の時間間隔の累積値を計算します。時間間隔中に記録された複数のデータポイントの平均を計算することも、値を補間することもできます。すべてのデータポイントは同じ系列に属している必要があります。異なる時間に報告された 2 つのデータ ポイント間でカウンター リセットが発生した場合は、両方のデータ ポイントを使用しないでください。
-
前の時間間隔の適切な値を決定します。前回の更新以降にカウンターがリセットされている場合は、その値を使用不可として宣言します。
-
前の間隔が使用可能な場合は、データ ポイントとトラフィック レートの差を計算します。
これらのガイドラインは、次の 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 つのデータ ポイントには があり、他の 2 つのinit_time t1データ ポイントには init_time t0があります。ではなく、最終変更タイムスタンプタグ 、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-1LSP のパケット レートに関するすべてのラインカードのデータが集約されます。
select sum(value) from lsp_packet_rate where counter_name=’lsp-sjc-den-1’, host=’sjc-a’
このクエリは、タグまたはラインカードに従って component_id データをグループ化しないため、すべてのコンポーネントまたはラインカードからのLSPパケットレートが返されます。
複数のメトリックのデータの集計
複数の値のメトリックを集計すると便利な場合があります。例えば、集合型イーサネットインターフェイスの場合、通常、各インターフェイスメンバーのパケットレートとバイトレート、および集約型リンクのインターフェイス使用率を追跡する必要があります。
例: 複数のメトリック値の集計
この例では、次の 2 つのクエリを実行します。
-
集合型イーサネットインターフェイス内の各メンバーリンクのイングレスパケット数を導き出すための連続クエリー
-
同一の集合型イーサネットインターフェイスに属するすべてのメンバーリンクのパケット数データを集約するためのクエリー
次の連続クエリは、集合型イーサネットインターフェイス内の各メンバーリンクの測定値、 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 、実際のメンバーリンクを検証しません。