Junos Telemetry Interface について
Junos Telemetry Interface(JTI)は、ジュニパーネットワークスが開発したテレメトリフレームワークです。Junosデバイスから外部コレクタに運用データをエクスポートすることで、リアルタイムの監視が可能になります。このトピックでは、JTI で使用されるモデル駆動型テレメトリ、テレメトリ モード、トランスポート プロトコル、テレメトリ センサー、センサー パス、およびデータ モデルの概念について説明します。
ネットワークテレメトリ
ネットワークテレメトリとは、ネットワークデバイスからデータを収集、送信、分析するプロセスです。このデータには、トラフィックパターン、デバイスのステータス、エラー率、およびネットワークの健全性と動作に関するインサイトを提供するその他のメトリックに関する情報を含めることができます。このデータを使用して、有用なインサイトを引き出し、この情報を適用して、ネットワークパフォーマンスとセキュリティを効果的に監視および管理できます。ネットワーク管理者は、テレメトリデータを使用して、ネットワークの問題のトラブルシューティング、異常の検出、ネットワーク全体のリソース利用の最適化を行うことができます。ネットワークテレメトリの主なメリットの1つは、ネットワークの運用をリアルタイムで可視化できることです。
ネットワークテレメトリは、ネットワークセキュリティを強化する上でも重要な役割を果たします。テレメトリデータを分析することで、セキュリティチームはサイバー攻撃やその他のセキュリティ上の脅威を示す可能性のある異常なパターンを特定できます。これにより、潜在的なセキュリティインシデントの迅速な検出と対応が可能になり、ネットワークとそのデータを保護することができます。
Junos Telemetry Interface
Junos Telemetry Interface(JTI)は、テレメトリデータをストリーミングするために開発されたジュニパーのテレメトリソリューションです。JTIは拡張性が高く、ネットワーク内の複数のデバイスをリモートで監視できます。また、トラブルシューティングの改善、プロアクティブなネットワーク管理、運用コストの削減にも役立ちます。
Junos Telemetry Interfaceは、さまざまなネットワークシナリオに適用できます。
- パフォーマンス監視: インターフェイス使用率、遅延、パケット損失などの主要なメトリックを監視して、最適なネットワークパフォーマンスを確保します。
- セキュリティ監視: セキュリティイベントを追跡し、トラフィックパターンを分析し、潜在的なセキュリティ上の脅威を特定します。
- アプリケーションパフォーマンス管理: ネットワークデータとアプリケーションデータを関連付けることで、アプリケーションパフォーマンスに関するインサイトが得られます。
- ネットワーク容量計画: 履歴データとリアルタイムデータを分析して、潜在的なボトルネックを特定し、将来の容量ニーズに備えた計画を立てます。
JTIのその他のアプリケーションには、ネットワーク要素と外部コントローラ(NorthStar Controller、ジュニパーのMist、Juniper Apstraなど)間の運用状態の同期をサポートするリアルタイムデータの提供などがあります。Northstar Controller は、ネットワーク全体のトラフィック エンジニアリング パスの作成を自動化し、ラベル スイッチ パス(LSP)統計情報など、特定のネットワーク要素に関するテレメトリ データにサブスクライブします。Apstraは、ネットワークからのテレメトリデータを監視および分析する方法を定義できるIBA(インテントベース分析)をサポートするマルチベンダー自動化ツールです。Juniper Mist Premium Analyticsは、ITネットワーク、セキュリティ、事業部門の各ユーザーに、エンドツーエンドのネットワーク可観測性とビジネスインテリジェンスを提供する、クラウドベースのサブスクリプションサービスです。
モデル駆動型テレメトリ
Junos Telemetry Interface は、MDT(モデル駆動型テレメトリ)アーキテクチャを採用しています。モデル駆動型ネットワークテレメトリシステムは、データモデルを活用してネットワークデバイスからのテレメトリデータを定義および収集する、ネットワーク監視への高度なアプローチです。このシステムでは、収集またはストリーミングするデータの構造とタイプを指定するために、YANG(Yet Another Next Generation)言語を使用してデータモデルが定義されることがよくあります。
ジュニパーは現在、2つの異なるデータモデルをサポートしています。
-
ジュニパーのネイティブデータモデル
-
OpenConfig データ モデル
どちらのモデルも YANG を使用して、ストリーミングするデータ構造とデータ タイプを指定します。詳細については、「 データ モデル」を参照してください。
適切なデータモデルの選択は、具体的なニーズによって異なります。OpenConfig とネイティブ センサーの両方を同時にサブスクライブできます。
以下の手順に従って、モデル駆動型テレメトリ ソリューションを設定します。
- データコレクターを設定する: データを収集してエンコードするようにネットワークデバイスを構成します。詳細については、「 テレメトリ データ コレクター」を参照してください。
- トランスポートプロトコルを確立する: データ転送に適したトランスポートプロトコルを選択して構成します。詳細については、 テレメトリプロトコルを参照してください。
- センサーの構成: センサー プロファイルは、データを監視およびストリーミングするためのシステム リソースのパラメーターを定義します。各センサープロファイルを監視するために有効にできるシステムリソースは 1 つだけです。監視するシステム リソースごとに異なるセンサー プロファイルを構成します。ただし、同じシステム リソースを監視するように複数のセンサーを設定することはできます。詳細については、「 センサーとセンサー パス」を参照してください。
- サブスクリプションの作成: 監視する必要があるデータストリームのサブスクリプションを設定します。テレメトリセッションは、デバイスと受信者のどちらがサブスクリプションを開始するように設定されているかに応じて、ダイヤルインモードまたはダイヤルアウトモードで確立できます。詳細については、「 テレメトリ モード」を参照してください。
センサーとセンサー経路
テレメトリセンサーは、テレメトリソリューションの重要なコンポーネントです。さまざまな物理的、環境的、および性能パラメータを測定し、それらを信号に変換して、gNMIまたはUDP接続を介してコレクターに送信し、リモート監視と分析を行います。例としては、温度センサー、インターフェースセンサー、流量センサーなどがあります。テレメトリ センサー パスは、データ モデル内の特定のルートで、多くの場合 YANG を使用して定義され、ネットワーク デバイスから収集およびストリーミングされる正確なデータを指定します。ジュニパーは、OpenConfigとネイティブセンサーの両方をサポートしています。Openconfig センサーは、主にカウンターベースまたは状態ベースのメトリックを追跡し、ネイティブ センサーは、これらのセンサーが詳細なデバイス データにアクセスできるため、イベント駆動型メトリックの追跡に効果的です。Openconfig ベースのセンサー パスを構成してベンダーに依存しない形式でセンサー情報を取得したり、ネイティブ センサー パスを構成してジュニパー独自の情報をネイティブ形式で取得したりできます。詳細については、「 センサー パスの探索」を参照してください。
テレメトリデータコレクター
テレメトリコレクターは、テレメトリデータのデータ収集、処理、送信、保存を実行する特殊なツールまたはソフトウェアです。これは、テレメトリデータを生成するJunosデバイスと、それを保存、分析、視覚化するバックエンドシステムとの間の仲介役です。
データコレクタの機能:
- データ収集:コレクターは、gRPC、gNMI、またはUDP接続を介してジュニパーデバイスからテレメトリデータを受信します。
- データ処理: コレクターは、収集されたデータを集計および正規化して処理し、不要な情報を除外し、メトリックを集計し、初期分析を実行します。この処理により、データ量を減らし、最も重要なメトリックに焦点を当てることができます。
- データ伝送:信頼性の高いデータ伝送と低遅延を保証します。
- データストレージ:処理されたデータは、その後、さらなる分析、視覚化、および保存のために、さまざまなバックエンドシステムにエクスポートされます。長期的な分析や履歴比較のためにデータレイクに保存することができます。コレクターは複数のデータ形式とプロトコルをサポートしているため、さまざまな監視および分析ツールと互換性があります。分析されたデータは、インタラクティブなダッシュボードとレポートを通じて表示され、ネットワーク管理者に実用的な洞察を提供することができます。
テレメトリモード
Junos Telemetry Interface は、次の 2 つのモードでテレメトリ セッションをサポートします。
ジュニパーのデバイスは、ダイヤルインモードとダイヤルアウトモードの両方で動作できます。Juniperデバイスは、ネットワークのトポロジーに基づいて、どちらのモードでも設定できます。どちらのモードでも同じデータモデルを使用し、同じテレメトリデータをネットワーク経由でストリーミングします。2つのモードの違いは、コレクターとジュニパーデバイスのどちらが接続を開始して維持するかによって異なります。
JTIは、gRPC(gNMIの有無にかかわらず)とUDPのどちらを使用しているかに関係なく、主にストリーミングテレメトリ用の「ダイヤルアウト」システムです。ただし、一部の限定的なダイヤルイン機能をサポートします。
JTI におけるジュニパーの gRPC サポートは、主にダイヤルアウトです。デバイスは gRPC クライアントとして機能し、コレクターは gRPC サーバーです。ダイヤルイン(デバイスに接続するコレクター)は、gNMI テレメトリ ストリーミングの標準の JTI 機能ではありません。ただし、オンデマンド要求(たとえば、データを取得するための 1 回限りの「取得」操作)にはダイヤルイン方式で gNMI を使用できますが、これは永続的なテレメトリ サブスクリプションとは異なります。ストリーミング テレメトリの場合、JTI の gRPC は通常、デバイスによって開始されます。
サブスクリプションの種類
JTIはさまざまなサブスクリプションモードをサポートしており、特定のニーズや条件に基づいてカスタマイズされたデータ収集を可能にします。サブスクリプションモードはデバイス上で構成され、データストリームの動作を決定します。サブスクリプション モードの実装は、ダイヤルアウト接続とダイヤルイン接続のどちらを使用しているかによって異なります。ストリーミング間隔によって、デバイスとコレクター間のテレメトリデータ送信の頻度が決まります。データの収集とストリーミングは、特定の条件が満たされたとき、またはテレメトリデータの収集とストリーミングを開始するイベントが発生したときにトリガーされます。これらのトリガーにより、特定の基準が満たされたときにデータが収集されます。たとえば、パケット損失が検出された場合、テレメトリデータを収集してストリーミングできます。ダイヤルイン テレメトリとダイヤルアウト テレメトリはどちらも、次のサブスクリプション モードをサポートしています。
- 1 回: これは、テレメトリ データに対する 1 回限りの要求です。このモードは、サブスクライブされたデータの現在の状態のスナップショットが必要な場合に構成できます。ダイヤルイン接続とダイヤルアウト接続の両方でサポートされていますが、主にダイヤルイン接続で使用されます。デバイスはデータをコレクターに一度送信し、ダイヤルアウト接続のために停止します。コレクターは、ONCEモードの「サブスクライブ」RPCを介してダイヤルイン接続を要求します。ダイヤルアウト接続では、センサーとサブスクリプションを 1 回だけトリガーするように構成する必要がありますが、これは一般的なシナリオではありません。ダイヤルイン接続では、これは "Get" RPC に似ていますが、サブスクリプションとして構成されています。
- ポーリング: テレメトリ データを定期的にオンデマンドで取得します。この構成は、特定の間隔でセンサーを監視するのに適しています。POLL はダイヤルイン シナリオでサポートされており、コレクターはデバイスの gNMI サーバへの接続を開始します。JTI のストリーミングはデバイス主導型であるため、一般的なダイヤルアウト ストリーミング モードではありません。デバイスが gNMI サーバを実行する必要があります。コレクターは POLL でサブスクライブし、必要に応じてポーリングします。
- ストリーム: この継続的なサブスクリプションは、構成されたトリガーが発生したときにデータを継続的にストリーミングします。
手記： すべてのセンサー(OpenConfigまたはネイティブ)がすべてのモードをサポートしているわけではありません。
この形式のサブスクリプションには、次の 3 つのサブモードがあります。
- ON_CHANGE: デバイスは、監視対象データが変更されたとき(たとえば、インターフェイスカウンターが増加したり、状態が反転したりするなど)にのみアップデートを送信します。このモードは、時間駆動型ではなく、イベント駆動型のメトリックに適しています。ネイティブ センサーは、イベント駆動型メトリックのコンテキストで Openconfig センサーよりも優れています。
- 見本： テレメトリの更新は、設定された間隔に基づき、一定の間隔でストリーミングされます。このモードは、パケット数や転送バイト数など、時間の経過とともにサンプリングされるメトリックに適しています。
- TARGET_DEFINED:デバイスは、監視対象のセンサーまたはリソースに基づいて最適なモード(SAMPLEまたはON_CHANGE)を決定します。ジュニパーの実装では、センサーでON_CHANGEが明示的にサポートされていない限り、デフォルトでSAMPLEになることがあります。
- 手記： 設定パスのTARGET_DEFINEDサブスクリプション要求は、ON_CHANGE要求としてのみ扱われます。
ネットワークに適したテレメトリ設定を決定する
テレメトリモードの設定に関するガイドラインネットワーク トポロジに適したテレメトリ センサー、接続方法 (ダイヤルインまたはダイヤルアウト)、およびサブスクリプション モードを選択する前に、次のガイドラインを考慮してください。
- OpenConfigセンサーとサブスクリプションモードSAMPLEの組み合わせは、標準化された定期的な監視(マルチベンダーダッシュボードなど)に最適です。
- ネイティブセンサーとON_CHANGEサブスクリプションモードの組み合わせは、ジュニパー固有のイベントドリブンインサイト(ハードウェアのトラブルシューティングなど)に適しています。
ネットワークに適したテレメトリ セッションを決定するために、次の情報は、ダイヤルイン テレメトリ モードとダイヤルアウト テレメトリ モードの比較をまとめたものです。
ダイヤルインとダイヤルアウト
-
ダイヤルイン(gNMI を使用した gRPC)は、いずれかのセンサータイプ(Openconfig またはネイティブ)からスナップショットを取得します。
例:コレクターは、gRPCを介してgNMIを使用して、OpenConfigの統計情報(
/interfaces)またはネイティブのPFEの統計情報(/junos/system/linecard)を取得します。 -
ダイヤルアウト(gNMIまたはUDPを備えたgRPC)はアップデートをストリーミングし、gNMI/gRPCは構造を優先し、UDPはネイティブのシンプルさに適合します。
例:デバイスは、gRPC上のgNMIまたはUDP上のネイティブファイアウォールカウンターを介して、OpenConfig BGP統計をストリーミングします。
テレメトリプロトコル
Junos Telemetry Interface は、gNMI および UDP プロトコルをサポートしており、ジュニパーのデバイスからテレメトリデータを収集して、データコレクタにストリーミングします。
gRPC ネットワーク管理インターフェイス(gNMI)
gNMI は、ネットワーク デバイスの設定と監視を行う gRPC をベースにしたプロトコルです。ネットワークオペレータは、デバイス構成データを取得および変更し、ネットワークデバイスからのリアルタイムテレメトリデータをサブスクライブできます。gNMIは、テレメトリ更新用に、ONCE、POLL、STREAMなどのサブスクリプションモードをサポートしています。gNMIは、プロトコルバッファ(protobuf)などのデータ符号化形式を使用し、TLSを使用して安全な通信を確保します。詳細については、 gNMI サービス および gNMI を使用したテレメトリ データのサブスクライブを参照してください。
ユーザー・データグラム・プロトコル(UDP)
UDP 経由のテレメトリ データのストリーミングは、ダイヤルアウト メカニズムに基づいています。センサー パスは CLI を使用して構成され、デバイスは構成されたセンサー パスのデータを UDP 経由でコレクターの宛先アドレスに送信します。宛先アドレスはCLIで設定します。ネイティブ センサーから UDP 経由でテレメトリをストリーミングしている間、データは protobuf 形式で UDP 経由でコレクターに送信されます。UDPは、ステートレスデータのエクスポートに適しています。詳細については、「 UDP 経由のテレメトリ データのストリーミング」を参照してください。
データモデル
Junos Telemetry Interfaceのデータモデルは、YANG(Yet Another Next Generation)を使用して、ネットワークデバイスから収集されるテレメトリデータの構造を定義します。YANGは、ネットワークデバイスの設定、運用状態データ、リモートプロシージャコール(RPC)を定義するためにJTI(Junos Telemetry Interface)で使用される、スタンダードベースの拡張可能なデータモデリング言語です。JTIでは、YANGモジュールにより、ネイティブまたはOpenConfigデータモデルを使用して、インターフェイス統計などのテレメトリデータを収集およびエクスポートするためのセンサーのプロビジョニングが可能になります。YANG 規格は、 RFC 6020 および RFC 7950 で定義されています。
ジュニパーネットワークスは、Junosデバイス向けのYANGモジュールを公開しています。これは 、ジュニパーのGitHubリポジトリ からダウンロードするか、デバイス上で生成することができます。
OpenConfig ワーキング グループは、OpenConfig データ モデルを定義します。これは、ネットワークを構成および管理するためのベンダーに依存しないデータモデルです。OpenConfig データ モデルは、ユニバーサル キー/値形式の GPB(Google Protocol Buffers)メッセージとしてデータを生成します。JTIでは、OpenConfigモデルを活用して、ベンダーに依存しない幅広いネットワークの全体像を把握できます。Openconfig センサー パスは、Openconfig データ モデルに基づいてセンサーからセンサー情報を取得するために使用されます。OpenConfig リソース パスの詳細な探索については、 Junos YANG データ モデル エクスプローラーを参照してください。
ジュニパーネイティブデータモデルは、ジュニパーが開発したオープンで拡張可能なフレームワークです。このモデルは、ジュニパーのデバイス固有の機能に関するテレメトリデータをストリーミングするために使用されます。これらには、インターフェイス統計、ルーティング情報、セキュリティメトリックなどが含まれます。さらに、ネイティブモデルでは、エンタープライズ固有のセンサーを定義できます。ジュニパーまたはエンタープライズ固有のセンサーからの情報にアクセスするには、ジュニパーのネイティブセンサーを購読してください。ネイティブ センサー パスは、ネイティブ データ モデルに基づいてセンサーからセンサー情報を取得するために使用されます。ジュニパーのネイティブセンサー向けYANGモジュールは、ジュニパーのTelemetry GitHub リポジトリで入手できます。
センサー経路の探索
テレメトリ センサー パスは、監視する必要があるデータ ポイントまたはメトリックへの階層パスを記述します。 必要なセンサー データをストリーミングし、センサーをアクティブ化して、関連するセンサー パスを識別します。JTIは、Openconfigセンサーパスとネイティブセンサーパスの両方をサポートしています。
-
OpenConfig センサー パス
Openconfig センサーからのデータ収集を構成するには、サブスクリプションとセンサー パス(例:
/interfaces/interface/state/counters)を定義し、データ コレクターをセットアップして、ジュニパーネットワークスのサポート ページから Junos Telemetry Interface プロトコル バッファー ファイルをダウンロードします。コレクターでキャプチャされたデータをキャプチャしてデコードします。 -
ネイティブ センサー パス
ネイティブセンサーパスは、Junos OS(
/junos/system/line card/interface/など)に固有であり、デバイス固有のメトリックへのジュニパー最適化のきめ細かいアクセスを提供します。ネイティブセンサーからのデータ収集を設定するには、Junos CLIを使用して、特定のデータを収集するためのネイティブセンサーをプロビジョニングします。gRPC または UDP を使用してデータをストリーミングするようにテレメトリ インターフェイスを構成します。プロトコル バッファーのファイルを使用して、コレクターでストリーミング データをデコードします。
どちらのパスタイプも、JSONやXMLなどの形式でのデータの構造化出力を可能にし、効率的な監視と分析のための外部コレクターとの互換性を確保します。
センサー パス エクスプローラー
ジュニパーネットワークスの Junos YANGデータモデルエクスプローラ は、サポートされているすべてのリソースパス、それに対応するリーフ、それらをサポートするデバイスプラットフォームを表示するためのオンラインツールです。これにより、さまざまなOpenConfigとネイティブデータモデルの属性を調査または比較できます。ソフトウェアのリリース番号または製品に基づくフィルター オプションを使用して、各プラットフォーム上のリソース パスとセンサーのリストを表示します。
テレメトリ センサー パスの選択
モデル駆動型テレメトリ システムでは、データ モデルのコンテナー階層内の任意のレベルで終了するようにセンサー パスを構成できます。必要なテレメトリ情報に基づいて、広範なデータセットを取得するようにセンサー パスを構成するか、特定のセンサーのターゲット情報を非常に具体的に取得できます。たとえば、センサーパスは、ルーター上のすべてのインターフェイス統計情報を含むコンテナを指す場合もあれば、特定のインターフェイスのパケット損失などの単一のメトリックに焦点を当てたより詳細な場合もあります。
たとえば、(OpenConfig データ モデルを使用して )デバイスで生成されたアラームに関するテレメトリ データを受信するには、必要なセンサー データの粒度に基づいて、以下のリソース パスのいずれかを設定できます。
/system/alarms/alarm/id:このパスは、アラームIDのみを取得します。/system/alarms/alarm/config:このパスは、詳細なアラーム情報を取得します。
正しいセンサーパスを設定することで、効率的なテレメトリシステムが保証されます。各リソース・パスは、システム・リソースのデータ・ストリーミングをグローバルに、つまりシステム全体に使用可能にします。各リソースパスを変更して、論理インターフェイスまたは物理インターフェイスを指定できます。リソースパス「/interfaces/interface/config」はグローバルな物理インターフェイスレベルで設定可能な項目のリストを取得しますが、パス「/interfaces/interface/config/name」はインターフェイスの名前を指定し、デバイスはインターフェイスのタイプに応じてこのリーフの許容値を制限する場合があります。
センサー経路を選択するための重要なガイドライン
-
ユーザーは、センサーを構成するときに、常に完全かつ直接的なリソース パスを提供する必要があります。「
/components/component/」などの 部分的なリソースパスを指定すると、構成が不完全になり、エラーが発生する可能性があります。このようなリソースパスは、その階層で使用可能なすべてのオプションを表示する必要があるため、デバイスを圧倒します。これを防ぐには、常に完全なリソース パスを検証して使用し、正確で効率的なセンサー構成を確保します。手記：「/」(ルート)および「/junos/」でのサブスクリプションとセンサー構成の作成は許可されていません。表 1:センサー パスの例 センサー パスの良い例 センサー パスの悪い例 /interfaces/interface/subinterfaces/subinterface/state/counters/out-pkts/interfaces/interface -
論理および物理パケット転送エンジン インターフェイス センサーは、一貫性のない一部のリーフをコレクターに報告します。例えば、ストリームドパスを生成するサブスクライブされたパス
/interfaces/ 115 interface/、キー名のリーフparent_ae_nameとinit_time(リーフ名にアンダースコアがある)/junos/system/linecard/interface/logical/ usage/を報告します。サブスクライブされたパス/interfaces/interface/state/ストリームパスを生成します/ junos/system/linecard/interface/queue/キー名のリーフparent-ae-nameとinit\u0002time(リーフ名にハイフンが含まれる)を報告します。
センサー データのカプセル化形式
Junos Telemetry Interface では、2 種類の方法でプロトコル バッファー(gpb)形式でデータをエクスポートできます。このセクションでは、UDP を使用してネイティブ センサーからエクスポートされるデータの形式について説明します。データはUDPヘッダーにカプセル化され、UDPヘッダーはIPv4ペイロードでカプセル化されます。このJunos Telemetry Interfaceモデルは、分散アーキテクチャに基づいており、設定されたセンサーによって生成されたデータは、コントロールプレーンをバイパスしてデータプレーンから直接エクスポートされるため、これらのリソースを節約して他の必要な機能を実行させることができます。
ネイティブ センサーは、UDP を使用してソースに近いデータをエクスポートします。物理インターフェイスの統計情報、ファイアウォールフィルターカウンターの統計情報、ラベルスイッチパス(LSP)の統計情報など、さまざまなタイプのテレメトリデータをエクスポートできます。センサーは、有効になるとすぐにデータの出力を開始します。
センサー データは、 TelemetryStream という名前の 1 つの構造化プロトコル バッファー メッセージとして表されます。以下に示すメッセージまたは .proto ファイルには、ラインカード、パケット転送エンジン、ルーティングエンジンなど、データソースを識別するいくつかの属性が含まれています。構成されたセンサーの名前も含まれます。センサーを構成する方法の詳細については、「 センサー パスの探索」を参照してください。サポートされているネイティブセンサーの一覧については、 センサー(Junos Telemetry Interface)を参照してください。
また、ストリーミング サーバーまたはコレクターでサポートされているすべてのセンサーの .proto ファイルもダウンロードする必要があります。Web ブラウザから、ジュニパーネットワークス ページの [すべての Junos プラットフォーム] ソフトウェアのダウンロード URL に移動します。 https://www.juniper.net/support/downloads/。 Junos OS プラットフォームの名前とリリース番号を選択したら、[ ツール ] セクションに移動して Junos Telemetry Interface データ モデル ファイル パッケージをダウンロードします。ストリーミングサーバーの設定の詳細については、 ストリーミングサーバー(Junos Telemetry Interface)を参照してください。
ネイティブ プロトコル バッファー (protobuf) メッセージ構造
コレクターにストリーミングされる情報は、 TelemetryStream の最上位のメッセージ構造 (telemetry_top.proto ファイル) を使用して送信されます。このメッセージには、ストリーミングされているセンサー データのメタデータ (たとえば、センサー パス、データが送信されるシステム、データが送信されるノードなど) が含まれています。実際のセンサー データは、最上位メッセージの拡張機能として送信されます。センサー データ用に別の proto ファイルが送信されます。 telemetry_top.proto ファイルとセンサー proto ファイルは、コレクターでセンサー データをデコードするために使用されます。
telemetry_top.protoファイルの構造
message TelemetryStream {
required string system_id = 1
[(telemetry_options).is_key = true];
optional uint32 component_id = 2
[(telemetry_options).is_key = true];
optional string sensor_name = 4
[(telemetry_options).is_key = true];
….
optional EnterpriseSensors enterprise = 101;
}
message EnterpriseSensors {
extensions 1 to max;
}
extend EnterpriseSensors {
// re-use IANA assigned numbers
optional JuniperNetworksSensors juniperNetworks = 2636;
}
message JuniperNetworksSensors {
extensions 1 to max; → ends with the extension message
}
このファイルは、 extension メッセージで終わります。
センサープロトファイルの構造
このファイルは、 extension メッセージで始まります。
extend JuniperNetworksSensors { → begins with the extension message
optional Port jnpr_interface_ext = 3;
}
message Port {
repeated InterfaceInfos interface_stats = 1;
}
message InterfaceInfos {
required string if_name = 1
[(telemetry_options).is_key = true];
optional uint64 init_time = 2;
…..
}
TelemetryStream メッセージには、さまざまな種類のデータを伝送するオプションの入れ子構造も含まれています。入れ子になった構造体は、次のようなプライベートに定義されたセンサー データを伝送することもできますEnterpriseSensors. 以下の例を参照してください。
//
// This file defines the top level message used for all Juniper
// Telemetry packets encoded to the protocol buffer format.
// The top level message is TelemetryStream.
//
import "google/protobuf/descriptor.proto";
extend google.protobuf.FieldOptions {
optional TelemetryFieldOptions telemetry_options = 1024;
}
message TelemetryFieldOptions {
optional bool is_key = 1;
optional bool is_timestamp = 2;
optional bool is_counter = 3;
optional bool is_gauge = 4;
}
message TelemetryStream {
// router name or export 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 increasesing 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];
// major version
optional uint32 version_major = 7;
// minor version
optional uint32 version_minor = 8;
optional IETFSensors ietf = 100;
optional EnterpriseSensors enterprise = 101;
}
message IETFSensors {
extensions 1 to max;
}
message EnterpriseSensors {
extensions 1 to max;
}
extend EnterpriseSensors {
// re-use IANA assigned numbers
optional JuniperNetworksSensors juniperNetworks = 2636;
}
message JuniperNetworksSensors {
extensions 1 to max;
}
ジュニパーネットワークスなどの個々の企業が、エンタープライズセンサーによって生成された属性を定義し、維持しています。各企業には、一意の属性識別子が割り当てられます。現在の慣習では、各属性にIANAが割り当てたエンタープライズMIB識別子を使用します。ジュニパーネットワークスの場合、この割り当てられた識別子は2636です。
推奨: 特定のメッセージ・タイプがエクスポートおよび受信されたことを確認するには、gpb メッセージの TelemetryStream.enterprise.juniperNetworks でこれらの属性を確認します。
セマンティクスや対応するスキーマなど、センサー データによって収集される各要素の説明については、 表 2 を参照してください。
| 要素タイプ |
形容 |
|---|---|
| カウンター |
単調に増加する符号なし整数。最大値に達すると、ゼロから開始します。 |
| ゲージ |
符号なしの 32 ビットまたは 64 ビット整数で、値を増減できます。この要素で表されるデータの例としては、キューの深さや温度など、特定のリソースの瞬時値があります。 |
| 率 |
カウンターやゲージなどの基本メトリックが変化するレート。この要素タイプでは、測定単位(ビット/秒など)と、レートが収集される間隔が明示的に定義されます。 |
| 平均 |
基本メトリックの複数のサンプルの平均。 例えば、平均キュー項目数 データ・エレメントは、キュー項目数のいくつかのエレメントを平均して計算されます。この要素タイプでは、平均の計算に使用する測定値の数と、測定間の時間間隔を定義することを強くお勧めします。それ以外の場合は、この平均値を計算する平均を明示的に定義する必要があります。 |
| 峰 |
基本メトリックの複数のサンプルの最大値。たとえば、 ピーク キューの深さ 要素は、キューの深さの複数の測定値を比較し、最大値を選択することによって計算されます。このデータ要素タイプでは、ピーク値の計算に使用する測定値の数と、測定間の時間間隔を定義することを強くお勧めします。それ以外の場合は、このピーク値の定義方法を明示的に定義します。また、この値がクリアされず、全期間の全体的な最大値を表しているかどうかも知っておく必要があります。 |
各データ要素タイプには、要素のサブセットも含まれます。例えば、データ要素 Counter と Gauge には、 rate、 average、および peak 測定のサブセットが含まれます。
サポートされているデータ型
GetRequest は、コレクター クライアントがテレメトリ データを受信するために Get RPC を開始すると送信されます。GetRequest内で指定されるのは、ターゲットがコレクタにデータを返すために必要なデータ要素(データ型を含む)です。データ型は、データを配信する形式を指定する変数です。
表 3 は、Junos Telemetry Interface(JTI)でサポートされているデータ タイプを示しています。指定されていない限り、このデータ型は、リモートプロシージャコール(gRPC)サービス、gRPCネットワーク管理インターフェイス(gNMI)サービス、またはUDPを使用したJTIデータエクスポートでサポートされています。
| 種類 |
価値 |
形容 |
|---|---|---|
| 糸 |
|
文字列値。 |
| int64 |
|
整数値。 |
| uint64 |
|
符号なし整数値。 |
| ブール |
|
Bool 値。 |
| 浮く |
|
浮動小数点値。
手記：
このデータ型は非推奨です。このデータ型の代わりに |
| 複 |
|
double 値は 64 ビット浮動小数点値です。 |
| 10進数64 |
|
Decimal64 でエンコードされた値。gNMI サービスでのみサポートされます。decimal64 を使用して、固定精度の 10 進数をエンコードします。値は一連の数字として表され、精度は数字セット内の小数点以下の桁数を指定します。例えば： message Decimal64 {
int64 digits = 1; // Set of digits.
uint32 precision = 2; // Number of digits following the decimal point.
手記：
このデータ型は非推奨です。このデータ型の代わりに |
| スカラー配列 |
|
混合型のスカラー配列値。混合データ型 (string、int64、uint64、bool float、または decimal64) の値の同種配列。gNMI サービスでのみサポートされます。 |
| 型 | 、値 | 、記述 |
|---|---|---|
| IEEEフロート32 | 2 進数、長さ = 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 データ型は「byte」です。gNMI 応答で、float_val形式のデバイスがデバイスから誤って受信され、コンプライアンス違反エラーが表示されました。bytes_val形式でデータを返すように変更が加えられました。4 バイト (浮動小数点値を表す) は、ネットワーク バイト オーダーで送信されます。値を解釈する前に、必ずホストバイト順に並べ替えてください。
|
データ型の詳細については、 github と http://www.openconfig.net/ を参照してください。
JTIを使用したパフォーマンス監視
Junos Telemetry Interface の主要機能の 1 つにパフォーマンスの監視があります。パフォーマンス管理システムへデータをストリーミングすると、ネットワーク管理者は、リンクとノードの使用率の傾向を測定し、ネットワークの輻輳などの問題をリアルタイムでトラブルシューティングできます。
一般的な展開では、ネットワーク要素(デバイス)は、パフォーマンス管理システムのコレクターとして機能する 2 つの宛先サーバーに重複データをストリーミングします。2 つのコレクターにデータをストリーミングすると、冗長性が確保されます。 図 1 に、パフォーマンス管理システムのコレクターがデータを要求する方法と、デバイスがデータをストリーミングする方法の図を参照してください。デバイスは、CLI(コマンドライン インターフェイス)、NETCONF による設定、または gRPC サブスクリプション コールを使用してデータを収集およびエクスポートするためのセンサーをプロビジョニングします。コレクターは、テレメトリのサブスクリプションを開始することでデータを要求します。データは一度だけ要求され、定期的にストリーミングされます。
のためのテレメトリストリーミング
Junos OS リリース 18.1R1 以降、syslog データをネットワーク テレメトリ コレクター システムにストリーミングできる新しいセンサーが利用可能になりました。 /junos/events/ センサーと、 reporting-rate 0 のエクスポート プロファイルを使用して、イベント データを統計データと共にテレメトリ収集システムにストリーミングできるようになりました。
Junos Telemetry Interface のその他のアプリケーションには、ネットワーク要素と外部コントローラ(ネットワーク全体のトラフィック制御パスの作成を自動化する Northstar Controller など)間の運用状態の同期をサポートするリアルタイム データの提供などがあります。NorthStar Controllerは、ラベルスイッチパス(LSP)統計など、特定のネットワーク要素に関するテレメトリデータをサブスクライブできます。