情報はTopicという属性で管理され、Publisher・SubscriberはTopicを指定することにより情報を送信・受信します。図6にTelemetryのパイプライン構成を示します。Telemetryパイプラインは下記の要素から構成されます。データの受け取り・利用をするアプリケーションPub/Subモデルの利点は失われますが、上記の構成以外にPublisherとSubscriberを直結する構成も可能です。以降でそれぞれの要素について解説します。PublisherPublisherはメッセージの発行者であり、下記の3つの要素から構成されます。監視対象機器とCollectorを繋ぐTransport部分Publisherからデータを受信するCollector監視対象機器に関する概念として、情報モデルと接続方式の分類についてご説明します。機器の情報モデルには、主にOpenConfig・ベンダネイティブの2種が存在します。OpenConfigはベンダニュートラルな利用を想定して標準化が進められているネットワークコンフィグのモデルであり、YANGに従い定義されています。ベンダネイティブは製品ごとに固有の情報モデルであり、一般的にOpenConfigよりも対応状況が良く、扱うことのできる情報も豊富な傾向があります。機器が発行する情報は、Sensor-Pathと呼ばれるデータパスにより予め指定されており、決められた間隔でメッセージを発行し、Collectorへと送信します。下記にSenrsor-Pathの例を示します。Sensor-PathはYANGのツリー構造に合わせて情報を取得するためのデータパスであり、SNMPにおけるOIDに近い概念です。“/junos/system/linecard/interface/”例のように、深いパスを指定することで取得する情報を細かく指定できます。OpenConfigとベンダネイティブでは同じ情報を取得する場合でも異なるパスを指定する必要があります。2021年8月時点の実装では、同じOpenConfigでもベンダにより対応状況が異なるため、各社のドキュメントを確認し取得するSensor-Pathを決める必要があります。次に接続方式の違いについてご説明します。Telemetryでは、情報を発行するPublisherと受け取るCollectorの接続方向により、Dial-InとDial-Outの接続方式が存在します。図7にそれぞれぞれの概念を示します。Dial-InはCollectorがPublisherに接続する手法です。利点としてはgRPCによる自動化を行っているネットワークの場合、機器に設定されたgNMIを利用して情報を取得できるため、Telemetry用追加設定の不要な点が挙げられます。Dial-OutはPublisherがCollectorに接続する手法です。利点としてはCollector側が監視するPublisherのリストを管理する必要がないためCollectorをステートレスに設計可能であり、Dial-Inに比べて規模性が高い点や、Publisher側にもACLによる制御が不要となる点が挙げられます。上記より、特別な理由がない場合は管理コストを考慮しDial-Outを採用することをお勧めします。gRPCによる運用自動化を行っているネットワークなどでは、Dial-InのTelemetryが容易に導入可能な場合もあります。2021年8月時点では、ベンダによりDial-In/Dial-Outの対応状況が異なるため、注意が必要です。次にTransport部分について説明します。Transportは監視対象デバイスとCollectorを繋ぐ転送の役割を持ちます。TransportはEncodingとEncapsulationの要素から成り立ちます。