Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

Junosテレメトリについて

Junosテレメトリは、ジュニパーネットワークスが開発したフレームワークで、Junosデバイスから外部コレクターに運用データをエクスポートすることができます。このデータは、リアルタイムのデバイス監視のために分析されます。このトピックでは、Junos Telemetryで使用されるモデル駆動型テレメトリ、テレメトリモード、トランスポートプロトコル、テレメトリセンサー、センサーパス、およびデータモデルの概念について説明します。

ネットワークテレメトリ

ネットワークテレメトリとは、ネットワークデバイスからデータを収集、送信、分析するプロセスです。このデータには、トラフィックパターン、デバイスのステータス、エラー率、およびネットワークの健全性と動作に関するインサイトを提供するその他のメトリックに関する情報が含まれます。このデータを使用して、有用なインサイトを引き出し、この情報を使用してネットワークパフォーマンスとセキュリティを効果的に監視および管理できます。ネットワーク管理者は、テレメトリデータを使用して、ネットワーク問題のトラブルシューティング、異常の検出、ネットワーク全体のリソース利用の最適化を行うことができます。ネットワーク テレメトリの主な利点の 1 つは、ネットワーク運用をリアルタイムで可視化できることです。

ネットワーク テレメトリは、ネットワーク セキュリティの強化にも重要な役割を果たします。テレメトリデータを分析することで、セキュリティチームはサイバー攻撃やその他のセキュリティ上の脅威を示す可能性のある異常なパターンを特定できるため、潜在的なセキュリティインシデントの検出と対応が迅速化され、ネットワークとそのデータの保護につながります。

Junosテレメトリ

Junos Telemetryは、テレメトリデータをストリーミングするために開発されたジュニパーのテレメトリソリューションです。拡張性が高く、ネットワーク内のリモート監視デバイスをサポートできます。また、トラブルシューティングの改善、ネットワークのプロアクティブな管理、運用コストの削減にも役立ちます。

Junosテレメトリは、さまざまなネットワークシナリオに適用できます。

  • パフォーマンス監視: インターフェイス使用率、遅延、パケットロスなどの主要なメトリックを監視して、最適なネットワークパフォーマンスを確保します。
  • セキュリティ監視: セキュリティイベントを追跡し、トラフィックパターンを分析し、潜在的なセキュリティ脅威を特定します。
  • アプリケーションパフォーマンス管理: ネットワークデータとアプリケーションデータを関連付けることで、アプリケーションパフォーマンスに関するインサイトを得ることができます。
  • ネットワーク容量計画: 過去およびリアルタイムのデータを分析して潜在的なボトルネックを特定し、将来の容量ニーズに対して計画を立てます。

他のジュニパーアプリケーションも、Junosテレメトリを利用してリアルタイムデータを提供し、ネットワーク要素と外部コントローラ(ジュニパーのMist、ジュニパーのRouting Director、Apstraなど)間の運用状態の同期をサポートします。

モデル駆動型テレメトリ

Junos Telemetryは、モデル駆動型テレメトリ(MDT)アーキテクチャを採用しています。モデル駆動型ネットワークテレメトリシステムは、データモデルを活用してネットワークデバイスからテレメトリデータを定義して収集する、ネットワーク監視への高度なアプローチです。このシステムでは、データモデルがYANG(Yet Another Next Generation)言語を使用して定義され、収集またはストリーミングするデータの構造とタイプが指定されます。

ジュニパーは現在、以下のさまざまなデータモデルをサポートしています。

  • ジュニパーネイティブデータモデル

  • OpenConfigデータモデル

  • Genstateモデル

すべてのモデルは YANG を使用して、ストリーミングするデータ構造とデータ型を指定します。詳細については、「 データモデル」を参照してください。

適切なデータモデルの選択は、特定のニーズによって異なります。任意のモデルのセンサーに同時にサブスクリプションできます。ネイティブセンサーには、さまざまなユースケースをサポートするという点で優位性があります。

モデル駆動型テレメトリ ソリューションを設定するには、次の手順に従います。

  1. テレメトリデータをストリーミングするようにジュニパーデバイスを設定します。 ジュニパーデバイスがJunosテレメトリをサポートする互換性のあるJunos OSバージョンを実行していること、およびジュニパーデバイスとコレクター間のネットワーク接続が存在することを確認します。

  2. データコレクターの設定: データを収集してデコードするようにコレクターを構成します。詳細については、「 テレメトリデータコレクタ」を参照してください。
  3. トランスポートプロトコルを確立する:データ転送に適したトランスポートプロトコルを選択して設定します。詳細については、「 トランスポートプロトコル」を参照してください。
  4. センサーを設定する: センサープロファイルは、監視およびストリーミングするシステムリソースのパラメーターを定義します。各センサープロファイルを監視するシステムリソースを1つだけ有効にすることも、システムリソースごとに異なるセンサープロファイルを設定することもできます。ただし、複数のセンサーを設定して、同じシステムリソースを監視することはできます。詳細については、「 センサーとセンサーパス」を参照してください。
  5. サブスクリプションの作成: 監視する必要があるデータストリームのサブスクリプションを設定します。テレメトリセッションは、デバイスまたは受信機がサブスクリプションを開始するように設定されているかどうかに応じて、ダイヤルインモードまたはダイヤルアウトモードで確立できます。詳細については、「 テレメトリモード」を参照してください。

センサーとセンサーパス

テレメトリセンサーは、テレメトリソリューションの重要なコンポーネントです。さまざまな物理的、環境的、およびパフォーマンスのパラメーターを測定し、それらをデータに変換し、リモート監視と分析のためにTCPまたはUDP接続を介してコレクターに送信します。例としては、温度センサー、インターフェイスセンサー、流量センサーなどがあります。テレメトリセンサーパスは、YANGを使用して定義されたデータモデル内の特定のルートであり、ネットワークデバイスから収集およびストリーミングされる正確なデータを指定します。ジュニパーは、Openconfig、ネイティブ、genstateモデルの両方のセンサーをサポートしています。Openconfigセンサーはカウンターベースまたは状態ベースのメトリックを追跡します。ネイティブセンサーはデバイスの詳細なデータにアクセスできるため、イベント駆動型メトリックを効果的に追跡します。Openconfigベースのセンサーパスを設定して、ベンダーに依存しない形式でセンサー情報を取得したり、ネイティブセンサーパスを設定してジュニパー独自の情報をネイティブ形式で取得することができます。詳細については、「 センサーパスの探索」を参照してください。

テレメトリデータコレクター

テレメトリ コレクターは、テレメトリ データのデータ収集、処理、送信、および保存を実行する特殊なテレメトリ コレクターです。これは、テレメトリデータを生成するJunosデバイスと、データを保存、分析、可視化するバックエンドシステムの間の仲介者です。

データコレクターの機能:

  • データ収集:コレクターは、gRPCまたはUDP接続を介してジュニパーデバイスからテレメトリデータを受信します。
  • データ処理: コレクターは、収集されたデータを集約および正規化して処理し、不要な情報をフィルタリングし、メトリックを集約し、初期分析を実行します。この処理により、データ量を削減し、最も重要なメトリックに集中できます。
  • データ伝送: 信頼性の高いデータ伝送と低遅延を保証します。
  • データストレージ: 処理されたデータは、さらなる分析、視覚化、保存のためにさまざまなバックエンド システムにエクスポートされます。長期的な分析や履歴の比較のために、データレイクに保存することができます。このコレクターは複数のデータ形式とプロトコルをサポートしているため、さまざまな監視ツールや分析ツールと互換性があります。分析されたデータは、インタラクティブなダッシュボードとレポートを通じて表示され、ネットワーク管理者に実用的なインサイトを提供します。

テレメトリモード

Junosテレメトリは、次の2つのモードでテレメトリセッションをサポートします。

ジュニパーデバイスは、ダイヤルインモードとダイヤルアウトモードの両方で動作できます。ネットワークのトポロジーに基づいて、どちらのモードでもジュニパーデバイスを設定できます。どちらのモードも同じデータモデルを使用し、ネットワークを介して同じテレメトリデータをストリーミングします。2つのモードの違いは、コレクターデバイスとジュニパーデバイスのどちらが接続を開始し、維持するかに基づいています。

サブスクリプションタイプ

Junos Telemetryはさまざまなサブスクリプションモードをサポートしており、特定のニーズや状況に基づいてデータを収集できます。サブスクリプションモードは、CLIコマンドを使用してデバイス上で設定するか、テレメトリタイプに基づくサブスクリプションリクエストの一部です。これらのモードは、データストリームの動作を決定します。ストリーミング間隔によって、デバイスとコレクター間のテレメトリデータ転送頻度が決まります。データの収集とストリーミングは、特定の条件が満たされた場合、またはテレメトリデータの収集とストリーミングを開始するイベントが発生したときにトリガーされます。これらのトリガーにより、特定の基準が満たされたときにデータが収集されます。例えば、パケット損失が検出された場合に、テレメトリデータを収集してストリーミングできます。以下のサブスクリプションモードがサポートされています。

  • 1回: これはテレメトリ データの 1 回限りの要求です。このサブスクリプションタイプは、サブスクライブされたデータの現在の状態のスナップショットが必要な場合に設定できます。デバイスは、テレメトリデータをコレクターに一度送信すると停止します。
  • ポーリング: テレメトリデータの定期的なオンデマンド取得です。この構成は、特定の間隔でセンサーを監視するのに適しています。ダイヤルインのシナリオでは、コレクターはこのタイプのサブスクリプションを通じてテレメトリデータをサブスクライブし、必要に応じて情報をポーリングします。
  • ストリーム: この継続的なサブスクリプションは、構成されたトリガーが発生すると、データを継続的にストリーミングします。

注: すべてのセンサー(OpenConfigまたはネイティブ)がすべてのタイプのサブスクリプションをサポートしているわけではありません。

サブスクリプションモード

Junos テレメトリは、以下のサブスクリプション モードをサポートしています。

  • ON_CHANGE: デバイスは、監視対象データが変更されたとき(たとえば、インターフェイス カウンターのインクリメントや状態の反転)にのみ更新を送信します。このモードは、時間駆動型ではなくイベント駆動型メトリックに適しています。
  • サンプル: テレメトリの更新は、設定された間隔に基づいて定期的にストリーミングされます。このモードは、時間の経過とともにサンプリングされるパケット数や転送バイト数などのメトリックに適しています。
  • TARGET_DEFINED:デバイスは、監視されたセンサーまたはリソースに基づいて最適なモード(SAMPLEまたはON_CHANGE)を決定します。センサーで明示的にサポートされていない限り、ジュニパー の実装は既定で SAMPLE ON_CHANGEになる場合があります。
    • 注:設定パスに対するTARGET_DEFINEDのサブスクリプションリクエストは、ON_CHANGEリクエストのみとして扱われます。

ネットワークに適したテレメトリ設定を決定する

ネットワークトポロジーとデータ要件によって、適切なセンサー、サブスクリプションタイプ、サブスクリプションモードが決まります。例えば、OpenConfigセンサーをSAMPLEサブスクリプションモードとともに使用し、マルチベンダーダッシュボードのサポートなど、標準化された定期的な監視を行います。ハードウェアのトラブルシューティングなど、ジュニパー固有のインサイトやイベント主導のインサイトを得るには、ON_CHANGEサブスクリプションモードでネイティブセンサーを使用します。

トランスポートプロトコル

トランスポートプロトコルは、Junosデバイスとテレメトリコレクターの間でテレメトリデータがどのように送信されるかを定義します。

以下のプロトコルがサポートされています。

  • 伝送制御プロトコル(TCP)

  • ユーザーデータグラムプロトコル(UDP)

TCP

TCPは、Junosテレメトリがサポートする主要なプロトコルです。TCPは接続指向で、ステートフルでセキュア(TLSサポート)であるため、データ配信において信頼性が高くなります。TCP は、ダイヤルインおよびダイヤルアウト テレメトリ モードでサポートされます。pre-gNMI(ジュニパー独自仕様)やgNMIなどのテレメトリメカニズムの基盤層を形成します。

表1:TCP
  ダイヤルイン ダイヤルアウト
輸送 TCP TCP
セッション HTTP/2 HTTP/2
RPCフレームワーク gRPC gRPC
テレメトリAPI gNMI gNMI
データモデル

  • OpenConfig

  • JunosネイティブYANG

  • Genstate

  • OpenConfig

  • JunosネイティブYANG

  • Genstate

テレメトリを設定し、テレメトリメッセージをデコードするには、 gNMIサブスクリプション、 gRPCサービスの設定、 サポートされているデータタイプ、 ジュニパーGitHubリポジトリ、 およびProtobufコンパクトメッセージフォーマット(ジュニパー独自)を参照してください。

UDP

UDPは、Junos Telemetryでサポートされている軽量のコネクションレストランスポートプロトコルです。UDPは、ダイヤルアウトテレメトリモードでサポートされています。

表2:UDP
  ダイヤルイン ダイヤルアウト
輸送 - UDP
セッション - -
RPCフレームワーク - gRPC
テレメトリAPI - -
データモデル -

  • OpenConfig

  • JunosネイティブYANG

UDPテレメトリでは、プロトファイルはテレメトリメッセージ構造をデコードするために必要です。テレメトリメッセージを設定およびデコードするには、 UDPを介したテレメトリデータのストリーミング、 センサーデータカプセル化形式、 サポートされているデータ型、 ジュニパーGitHubリポジトリ、 およびProtobufコンパクトメッセージ形式(ジュニパー独自)を参照してください。

データモデル

Junosテレメトリデータモデルは、YANG(Yet Another Next Generation)を使用して、ネットワークデバイスから収集されたテレメトリデータの構造を定義します。YANGは、ネットワークデバイスの構成、運用状態データ、リモートプロシージャコール(RPC)を定義するためにJunosテレメトリで使用される、標準ベースの拡張可能なデータモデリング言語です。Junos Telemetryでは、YANGモデルは、インターフェイスの統計情報などのセンサーを含むデータモデルの構造と詳細を表現します。YANG規格は、 RFC 6020 および RFC 7950で定義されています。

ジュニパーネットワークスは、Junosデバイス用のYANGモジュールを公開しており、 ジュニパーのGitHubリポジトリからダウンロードできます。リリース23.4以降、設定とテレメトリYANGモデルは統合され、 ジュニパーのGitHubリポジトリで公開されています。これには、設定、RPC、テレメトリモデルのYANG定義が含まれています。

OpenConfigワーキンググループは、OpenConfigデータモデルを定義します。これは、ネットワークを設定および管理するためのベンダーに依存しないデータモデルです。OpenConfigデータモデルは、ユニバーサルキー/値形式のGPB(Google Protocol Buffers)メッセージとしてデータを生成します。Junos Telemetryでは、OpenConfigモデルを活用して、ベンダーに依存しない、より広範なネットワークビューを得ることができます。Openconfigセンサーパスは、Openconfigデータモデルに基づいてセンサーからセンサー情報を取得するために使用されます。Openconfigリソースパスの詳細は、 Junos YANGデータモデルエクスプローラを参照してください。

ジュニパーのネイティブデータモデルは、ジュニパーが開発したオープンで拡張可能なフレームワークです。このモデルは、ジュニパーデバイスに搭載されている独自の機能に関するテレメトリデータをストリーミングするために使用されます。これには、インターフェイス統計、ルーティング情報、セキュリティメトリックなどが含まれます。さらに、ネイティブモデルでは、エンタープライズ固有のセンサーを定義できます。ジュニパーまたはエンタープライズ固有のセンサーからの情報にアクセスするには、ジュニパーネイティブセンサーに登録してください。ネイティブセンサーパスは、ネイティブデータモデルに基づいてセンサーからセンサー情報を取得するために使用されます。ネイティブセンサー用ジュニパーのYANGモジュールは、 GitHubにあるジュニパーのYANGリポジトリから入手できます。

生成状態モデルは、運用状態データから派生した自動生成されたYANGモデルです。genstate YANGモデルは、gNMIサブスクライブRPCを介してshowコマンドデータのサブセットを公開します。gNMI テレメトリコレクターは、公開されたモデルで定義されたリソースパスにサブスクライブして、特定の状態データを取得できます。gNMIサブスクリプションを設定するには、 gNMIサブスクリプションを参照してください。コレクターは、genstate モデルを使用してリソース パス クエリを発行し、特定の運用状態データを取得します。各ルートタグは、単一のgenstateモデル(つまり、ルートタグごとに1つのYANGファイル)に対応します。

センサーパスの探索

テレメトリセンサーパスは、監視する必要があるデータポイントまたはメトリックへの階層パスを記述します。関連データの識別、アクティブ化、ストリーミングに使用されます。Junos Telemetryは、Openconfig、Genstate、ネイティブセンサーパスをサポートします。

  • Openconfigセンサーパス

    Openconfigセンサーからのデータ収集を設定するには、サブスクリプションとセンサーパス(例: /interfaces/interface/state/counters)を定義し、データコレクターを設定し、ジュニパーネットワークスサポートページからJunos Telemetryプロトコルバッファファイルをダウンロードします。キャプチャしたデータをコレクターでキャプチャしてデコードします。

  • ネイティブセンサーパス

    ネイティブセンサーパスはJunos OS( /junos/system/line card/interface/など)に固有で、デバイス固有のメトリックへのきめ細かジュニパーに最適化されたアクセスを提供します。

    サブスクリプションモードは、CLIコマンドを使用してデバイス上で設定するか、テレメトリタイプに基づくサブスクリプションリクエストの一部です。プロトコルバッファーのファイルを使用して、コレクター上のセンサーデータをデコードします。

  • Genstateセンサーパス

    genstate リソース パスは、genstate YANG データ モデルを通じて公開された状態データをネットワーク デバイスから取得するために使用されます。genstate YANGモデルは、gNMIサブスクライブRPCを介してshowコマンドデータのサブセットを公開します。genstate モデルのリソースパスには、 /genstate/ が追加されます。例えば、コレクターは以下のクエリを送信して mpls lsp 名を取得します。

    genstate:/genstate/mpls-lsp-information/rsvp-session-data/rsvp-session/mpls-lsp/name

    注:

    genstate YANGモジュールの詳細、および特定のshowコマンドに対応するモジュールと利用可能なリソースパスを検出する方法については、 Junos Genstate YANGデータモデルを参照してください。

    サポートされているshowコマンドとルートパスを表示するには、 Genstate YANGデータモデル を参照してください。

すべてのパスタイプにより、JSON や XML などの形式でデータを構造化して出力できるため、外部コレクターとの互換性が確保されて効率的な監視と分析が実現します。

センサーパスエクスプローラ

ジュニパーネットワークスの Junos YANGデータモデルエクスプローラ は、サポートされているすべてのリソースパス、それに対応するリーフ、およびそれらをサポートするデバイスプラットフォームを表示するためのオンラインツールです。これにより、さまざまなデータモデル属性を調査または比較できます。ソフトウェアリリース番号または製品に基づくフィルターオプションを使用して、各プラットフォームのリソースパスとセンサーのリストを表示します。

注: Junos YANGデータモデルエクスプローラは、23.2R2-S2リリースで導入されました。リリース 20.2R1 から 23.1R1 までのセンサー情報は、 Junos テレメトリ センサー エクスプローラーで利用できます。

テレメトリセンサーパスの選択

モデル駆動型テレメトリシステムでは、センサーパスは、データモデルのコンテナー階層内の任意のレベルで終了するように構成できます。必要なテレメトリ情報に基づいて、広範なデータセットを取得するようにセンサーパスを設定したり、特定のセンサーのターゲット情報を非常に具体的に取得したりできます。例えば、センサーパスは、ルーター上のすべてのインターフェイス統計情報を含むコンテナを指している場合もあれば、特定のインターフェイスでのパケット損失などの単一のメトリックに焦点を当てた、より詳細なパスになる場合もあります。

例えば、デバイス上で生成されたアラームに関するテレメトリデータを(OpenConfigデータモデルを使用して)受信するには、必要なセンサーデータの粒度に基づいて、以下のいずれかのリソースパスを設定できます。

  • /system/alarms/alarm/id:このパスはアラームIDのみを取得します。
  • /system/alarms/alarm/config:このパスは、詳細なアラーム情報を取得します。

正しいセンサーパスを設定することで、効率的なテレメトリシステムが保証されます。各リソース・パスは、システム・リソースのデータ・ストリーミングをグローバル (つまりシステム全体) に有効にします。各リソースパスを変更して、論理インターフェイスまたは物理インターフェイスを指定できます。リソースパス「/interfaces/interface/config」は、グローバルな物理インターフェイスレベルで設定可能な項目のリストを取得し、パス「/interfaces/interface/config/name」はインターフェイスの名前を指定します。デバイスは、インターフェイスのタイプに応じてこのリーフに許可される値を制限する場合があります。

センサーパスの重要なガイドラインと命名規則

ほとんどの場合、センサーを構成するときは、完全かつ直接的なリソース パスを指定する必要があります。「/components/component/」などの部分的なリソースパスを指定すると、設定が不完全になったり、エラーが発生したりする可能性があります。このようなリソースパスは、その階層内で使用可能なすべてのオプションを取得して表示する必要があるため、デバイスに大きな負荷を課す可能性があります。これを防ぐには、常に完全なリソースパスを検証して使用し、正確で効率的なセンサー構成を確保します。

システムコンポーネントには階層コンポーネントの命名規則を使用します。この規則により、ルーティングエンジンの CHASSIS0:REx やネットワーク処理ユニット(NPU)の CHASSIS0:FPCx:PICy:NPUz など、ルートノードから始まるフルパスを使用して、コンポーネントを正確に識別できます。

以下の表に、コンポーネント名の変更例を示します。

表3:コンポーネント名

コンポーネントカテゴリ

古い名称

新しい名前

シャーシ

CHASSIS0

CHASSIS0

コントロールボード(CB)

CB0, CHASSIS0:CB0

CHASSIS0:CB0

ファントレイ

ファントレイ、ファントレイ0

CHASSIS0:FANTRAY0

ファン

ファントレイ0ファン0

CHASSIS0:FANTRAY0:FAN0

FPC

FPC0, CHASSIS0:FPC0

CHASSIS0:FPC0

RE CPU

RE0:CPU0, CHASSIS0:RE0:CPU0

CHASSIS0:RE0:CPU0

FPC CPU(論理)

FPC0:CPU

CHASSIS0:FPC0:CPU

FPC CPU(コア)

FPC0:CPU0, CHASSIS0:FPC0:CPU0

CHASSIS0:FPC0:CPU0

PIC

FPC0:PIC0

CHASSIS0:FPC0:PIC0

CC

FPC0:CC0, FPC0:PIC0:CC0

CHASSIS0:FPC0:PIC0:CC0

NPU

FPC0:NPU0, FPC0:PIC0:NPU0

CHASSIS0:FPC0:PIC0:NPU0

DP

FPC0:NPU0:DP0, FPC0:PIC0:NPU0:DP0

CHASSIS0:FPC0:PIC0:NPU0:DP0

ポート

FPC0:PIC0:PORT0

CHASSIS0:FPC0:PIC0:NPU0:PORT10

XCVR

FPC0:PIC0:PORT0:Xcvr0

CHASSIS0:FPC0:PIC0:NPU0:PORT10:XCVR0

OCH

FPC0:PIC0:PORT0:Xcvr0:OCH

CHASSIS0:FPC0:PIC0:NPU0:PORT20:XCVR0:OCH

レーン

FPC0:PIC0:PORT0:Xcvr0:OCH:Lane0

CHASSIS0:FPC0:PIC0:NPU0:PORT10:XCVR0:OCH:Lane0

FPM

FPM0, CHASSIS0:FPM0

CHASSIS0:FPM0

ミッドプレーン

MIDPLANE0

CHASSIS0:MIDPLANE0

PSM

PSM0, CHASSIS0:PSM0

CHASSIS0:PSM0

ルーティングエンジン(RE)

RE0, Routing Engine 0, CHASSIS0:RE0

CHASSIS0:RE0

FTC

FTC0, CHASSIS0:FTC0

CHASSIS0:FTC0

SIB

SIB0, CHASSIS0:SIB0

CHASSIS0:SIB0

REブートローダー

RE0:Bootloader

CHASSIS0:RE0:BOOTLOADER

RE BIOS

RE0:BIOS

CHASSIS0:RE0:BIOS

2月

FEB0, CHASSIS0:FEB0

CHASSIS0:FEB0

たとえば、 fpc フルパスの例は /components/component[name="CHASSIS0:FPC0"]/state/parent : CHASSIS0です。

コンポーネントの命名規則の詳細については、インターフェイス命名を参照してください

センサーパスの例

注:
表4:センサーパスの例
完全なセンサーパス 部分的なセンサーパス
/interfaces/interface/subinterfaces/subinterface/state/counters/out-pkts /interfaces/interface
注:論理および物理パケット転送エンジン インターフェイス センサーは、一部のリーフをコレクターに不一致で報告します。たとえば、ストリーミング /junos/system/linecard/interface/logical/ usage/パスを生成 /interfaces/interface/サブスクライブパスは、キー名のリーフ parent_ae_nameと init_time(リーフ名にアンダースコア付き)を報告します。ストリーミングパスを生成するサブスクライブパス /interfaces/interface/state/ / junos/system/linecard/interface/queue/ キー名、リーフ parent-ae-name、 init-time(リーフ名にハイフンを含む)を報告します。
注:

Junos Evolvedデバイスのパフォーマンスは、サービスベースのアーキテクチャによって最適化されており、サービス設定に基づいて一部のプロセスまたはデーモンがアクティブ化されます。これらのプロセスは、サービスが設定されるまで非アクティブなままです。テレメトリサブスクリプションが非アクティブなサービスを対象としている場合、テレメトリ出力は生成されません。

センサーデータカプセル化フォーマット

Junosテレメトリは、プロトコルバッファ(GPB)形式でデータをエクスポートする2つの方法をサポートしています。このセクションでは、UDP 経由でテレメトリデータをエクスポートするときにネイティブセンサーが使用するデータ形式について説明します。データはUDPヘッダーにカプセル化され、IPv4ペイロードにさらにカプセル化されます。このテレメトリモデルは、設定されたセンサーによって生成されたデータは、データプレーンから直接エクスポートされる分散アーキテクチャに従います。このアプローチは、コントロールプレーンをバイパスすることで、他の重要な機能のためにコントロールプレーンのリソースを節約するのに役立ちます。

ネイティブセンサーは、UDPを使用してソースに近いデータをエクスポートします。物理インターフェイスの統計情報、ファイアウォールフィルターカウンターの統計情報、ラベルスイッチパス(LSP)の統計情報など、さまざまな種類のテレメトリデータをエクスポートできます。センサーは、有効になるとすぐにデータの出力を開始します。

センサー データは、 TelemetryStream という名前の 1 つの構造化プロトコル バッファー メッセージとして表されます。以下に示すメッセージ( .proto ファイル)には、ラインカード、パケット転送エンジン、ルーティングエンジンなど、データソースを識別する複数の属性が含まれています。設定されたセンサーの名前も含まれています。センサーの構成方法の詳細については、「 センサー パスの探索」を参照してください。サポートされているネイティブセンサーの一覧については、 センサー(Junos Telemetry Interface)を参照してください。

また、ストリーミングサーバーまたはコレクターでサポートされているすべてのセンサーの.proto ファイルもダウンロードする必要があります。OpenConfigおよびYANGモデルファイルをダウンロードするには、Webブラウザを開いて https://www.hpe.com/us/en/networking/hpe-juniper-networking.html に移動し、[サポート]をクリックして https://support.juniper.net/support/ でジュニパーサポートポータルを開きます。ダウンロードタブを選択し、製品名を入力フィールドに製品名を入力し、製品の検索をクリックし、必要な製品を検索して選択し、ドロップダウンリストから適切なJunos OSとソフトウェアバージョンを選択します。同じページを下にスクロールし、+ツールセクションを展開し、必要なファイルをダウンロードします。OpenConfigモデル用のJUNOS Telemetry InterfaceデータモデルファイルとYANGファイル用のYANGモジュール。ストリーミングサーバーの設定の詳細については、streaming-server(Junos Telemetry Interface)を参照してください。

注:テレメトリデータデコードエラーを回避するには、protobuf(proto)ファイルとソフトウェアイメージが同じリリースバージョンのものであることを確認してください。

Protobufコンパクトメッセージフォーマット(ジュニパー独自仕様)

コレクターにストリーミングされた情報は、 TelemetryStream (テレメトリ_top.protoファイル)のトップレベルメッセージ構造を使用して送信されます。メッセージには、ストリーミングされるセンサー データのメタデータが含まれています (たとえば、センサー パス、データが送信されているシステム、データが送信されているノードなど)。実際のセンサー データは、トップレベル メッセージの拡張として送信されます。センサーデータ用に別のプロトファイルが送信されます。 テレメトリ_top.proto ファイルとセンサーprotoファイルは、コレクターでセンサーデータをデコードするために使用されます。

テレメトリ_top.protoファイルの構造

注:

このファイルは、 extension メッセージで終わります。

センサープロトファイルの構造

このファイルは extension メッセージで始まります。

TelemetryStream メッセージには、さまざまな種類のデータを伝送するオプションのネスト構造体も含まれています。ネストされた構造体は、次のようなプライベートに定義されたセンサーデータを伝送することもできますEnterpriseSensors.以下の例を参照してください。

ジュニパーネットワークスなどの個々の企業が、エンタープライズセンサーによって生成される属性を定義および管理しています。各企業には固有の属性識別子が割り当てられています。現在の慣習では、各属性に IANA が割り当てたエンタープライズ MIB 識別子を使用しています。ジュニパーネットワークスの場合、この割り当てられた識別子は2636です。

注:

推奨: 特定のメッセージタイプがエクスポートおよび受信されたことを確認するには、gpbメッセージの TelemetryStream.enterprise.juniperNetworks にある属性を確認します。

センサー データによって収集された各要素 (セマンティクスと対応するスキーマを含む) の説明については、 表 5 を参照してください。

表5:gpbメッセージ内の個々のデータ要素タイプ

要素タイプ

説明

カウンタ

単調に増加する符号なし整数。最大値に達すると、ゼロに戻ります。

ゲージ

値を増減できる符号なしの 32 ビットまたは 64 ビット整数。この要素によって表されるデータの例としては、キューの深さや温度などの特定のリソースの瞬時値があります。

レート

カウンターやゲージなどの基本メトリックが変化するレート。この要素タイプでは、測定単位(ビット/秒など)と、レートが収集される間隔が明示的に定義されます。

平均

基本メトリックの複数のサンプルの平均。例えば、 平均キューの深さ データ要素は、キューの深さの複数の要素を平均することによって計算されます。この要素タイプでは、平均の計算に使用する測定数と、測定値間の時間間隔を定義することを強くお勧めします。それ以外の場合は、この平均値を計算する方法を明示的に定義する必要があります。

ピーク

基本メトリックの複数のサンプルの最大値。たとえば、 ピーク キューの深さ 要素は、キューの深さの複数の測定値を比較し、最大値を選択することによって計算されます。このデータ要素タイプでは、ピーク値の計算に使用する測定数と、測定値と測定値の間隔を定義することを強くお勧めします。それ以外の場合は、このピーク値の定義方法を明示的に定義します。また、この値が決してクリアされず、したがって全期間全体の最大値を表しているかどうかも知っておく必要があります。

注:

各データ要素タイプには、要素サブセットも含まれます。たとえば、 Counter と Gauge のデータ要素には、 rate、 average、および peak 測定用のサブセットが含まれます。

サポートされているデータ型

GetRequest は、コレクター クライアントがテレメトリ データを受信するために Get RPC を開始すると送信されます。GetRequest 内で指定されるのは、ターゲットがデータ型を含むデータをコレクタに返すデータ要素です。データ型は、データが配信される形式を指定する変数です。

表6 は、Junosテレメトリでサポートされているデータ型を示しています。特に指定されていない限り、このデータタイプは、リモートプロシージャコール(gRPC)サービス、gRPCネットワーク管理インターフェイス(gNMI)サービス、またはUDPを使用したJunosテレメトリデータのエクスポートでサポートされています。

表6:データ型

タイプ

値

説明

文字列

string_val = 1

文字列値。

int64

int_val = 2

整数値。

uint64

uint_val = 3

符号なし整数値。

ブール値

bool_val = 4

ブール値。

浮動小数点

float_val = 6

浮動小数点値。

注:

このデータ型は非推奨です。このデータ型ではなく、 double_val を使用します。

ダブル

double_val

double 値は 64 ビット浮動小数点値です。

10進数64

decimal_val = 7)

10進数64でエンコードされた値。gNMIサービスでのみサポートされます。decimal64 を使用して、固定精度の 10 進数をエンコードします。値は、一連の数字として表され、精度は数字セットの小数点に続く桁数を指定します。次に例を示します。

message Decimal64 {
  int64 digits = 1;         // Set of digits.
  uint32 precision = 2;     // Number of digits following the decimal point.
注:

このデータ型は非推奨です。このデータ型ではなく、 double_val を使用します。

スカラー配列

leaflist_val = 8

混合型スカラー配列値。混合データ型 (string、int64、uint64、bool float、または decimal64) の値の同種配列。gNMIサービスでのみサポートされます。
表7:Open Configデータ型
タイプ 値 説明
ieeefloat32 バイナリ、長さ = 4

IEEE 32ビット浮動小数点数。これは Open Config モデルのデータ型です。

この番号の形式は次のとおりです。

 1-bit  sign
        8-bit  exponent
        23-bit fraction
      The floating point value is calculated using:
        (-1)**S * 2**(Exponent-127) * (1+Fraction)";
注:バイナリ形式に相当するgNMIデータ型は「バイト」です。gNMI応答で、デバイスからfloat_val形式のデータが誤って受信され、コンプライアンス違反エラーが表示されました。データがbytes_val形式で返されるように変更が組み込まれました。4バイト(浮動小数点値を表す)は、ネットワークバイト順に送信されます。値を解釈する前に、必ずホストバイト順に並べ替えてください。

データ型の詳細については、 github と http://www.openconfig.net/ を参照してください。

Junosテレメトリによるパフォーマンス監視

Junosテレメトリの主な機能の1つにパフォーマンス監視があります。パフォーマンス管理システムへデータをストリーミングすると、ネットワーク管理者はリンクとノードの使用率の傾向を測定し、ネットワークの輻輳などの問題をリアルタイムでトラブルシューティングできます。

一般的な導入では、ネットワーク要素またはデバイスが、パフォーマンス管理システムのコレクターとして機能する2つの宛先サーバーに重複データをストリーミングします。2 つのコレクターにデータをストリーミングすると、冗長性が得られます。パフォーマンス管理システムのコレクターがデータを要求する方法と、デバイスがデータをストリーミングする方法の図については、 図 1 を参照してください。デバイスは、コマンドラインインターフェイス(CLI)、NETCONFによる設定、またはgRPCサブスクリプション呼び出しを使用して、データを収集およびエクスポートするためのセンサーをプロビジョニングします。コレクターは、テレメトリサブスクリプションを開始してデータを要求します。データは1回のみ要求され、定期的にストリーミングされます。

図1:パフォーマンス管理のためのテレメトリストリーミングTelemetry Streaming for Performance Management

Junosテレメトリのその他の用途には、ネットワーク要素と、ネットワーク全体のトラフィック制御パスの作成を自動化するNorthstar Controllerなどの外部コントローラ間の運用状態の同期をサポートするリアルタイムデータの提供が含まれます。NorthStar Controllerは、ラベルスイッチパス(LSP)統計など、特定のネットワーク要素に関するテレメトリデータをサブスクライブできます。