Telemetryで具体的にどうやってデータを取るのか？

Telemetryでデータをやり取りするための構造

Telemetry≠プロトコル

別記事で解説した通り、Telemetryは、プロトコルの名前ではない。
NE（NetworkElement）から情報を取得するためには以下３要素をユーザで選択して事前準備する必要がある。

Encoding：送信する側のデータのフォーマットを規定する
（後述する通信プロトコルでデータを送信する時にデータを変換するルール）
Transport：データを送信するためのプロトコル
Data Model：NE装置から出力したいデータ情報を規定する

Encoding技術の代表例

GPB（Google Protocol Buffers）

GPB は Google が開発した構造データをシリアライズ（エンコーディング）するためのメカニズムになります（SNMP における ASN.1 BER 相当）。単純処理が得意な ASIC でも動作可能であり（勿論CPU によるシリアライズ･デシリアライズも可能）、SNMP が採用する ASN.1 BER と比べると処理負荷は軽減されています。言語非依存・プラットフォーム非依存で拡張性が高く、且つ、xml と比べてデータサイズが小さく、高速、シンプルである事も特徴になります。

Transport技術の代表例

gRPC（Google Remote Procedure Call）
gRPC はマルチプラットフォームに対応した RPC Framework であり、特徴は以下となります。
✓ ロードバランス、アプリレベルのフロー制御、Call キャンセリング機能
✓ 双方向ストリーム及びサーバプッシュ型に対応
✓ マルチプラットフォーム（複数言語に対応）
✓ ストリームコネクションの多重化
✓ オープンソース

これらの機能から、（gRPC を使用する事で）HTTP/2 をあたかも独立して動作する Transport Layer かのように活用する事が出来、その上で RPC（Remote Procedure Call）による情報取得が可能となります。また、元々は分散コンピュティング環境におけるコンポーネント同士のやり取りの効率化を目的としたプロトコルであったため、プロトコルとしての軽量化、レスポンスの迅速性が重視されています。
※ Micro-Service が注目されている昨今では、コンポーネント間の迅速なやり取りが非常に重要視されています。

Data Modelについて

データモデルは大別してOpenConfigとVendor Nativeの２つで選択可能。

OpenConfigの場合

マルチベンダー対応
(そもそもOpenConfigはベンダ依存んしない思想のため)

ベンダ独自実装部分の情報は取れない

Vender Nativeの場合

ベンダ独自実装部分の情報が取得可能
(OpenConfigで規定がないもの)

マルチベンダー非対応

NetOneより引用

Telemetryでは事前準備として”Encoding”,”Data Model”,”Transportプロトコル”を選択して規定する必要あり。
Data Modelはベンダ非依存のOpenConfigとベンダ依存のVender Nativeパターンがあり、一長一短。結局どこまで行っても標準化で完全にカバーすることはできない。