Telemetryに入門したので、まとめる。
Telemetryとは
超ざっくり言ってしまうと、SNMPの後継とされる技術
SNMPではサーバ側からデータ送信を要求（Pull）していたが、Telemetryではノード側から自動的にデータ送信を行う（Push）。またデータはGPB（Google Protocol Buffer）形式やJSON形式で出力され、今どきのDBや可視化ツールを用いて処理することができる。
Telemetry＝新しいプロトコル？ → No!
Telemetryはプロトコルの名前ではない。
Push型で様々なデータを出力し、それを活用するソリューション全体を指す言葉と考えた方がよい。
Telemetryシステムのコンポーネント
Telemetryを利用するには、システムに以下の要素が存在しなくてはならない。
（これが全てではなく、最低限。他の要素も存在しうる）
ノード
当然のことだが、データを送信するノードがTelemetryに対応しなくてはならない。
ノードが「Telemetryに対応」とは、以下の全てを実装していることを示す。
データモデル
出力可能なデータはYANGモデルで定義されている必要がある。業界標準を目指すOpenConfigに準拠したデータモデルと、ベンダ依存のデータモデルが存在する。
当然OpenConfigの方が便利に思えるが、各ベンダのH/Wに依存したデータ等はベンダモデルでしか表現できないため、全てをOpenConfigだけで賄えるわけではない-
トランスポート
データの送信には以下のいずれかのプロトコルを用いる。Cisco開発者曰く、UDPは送信は早いがdatagramサイズに制限があるため、TCPかgRPCがよいとのこと。- TCP
- UDP
- gRPC
-
エンコーディング
送信するデータのフォーマット。GPBを用いる場合は、受信側（コレクタ）でデコードが必要。- GPB：データはバイナリで送信
- GPB-KV：key-value形式のテキストで送信
- JSON：全てテキストで送信
コレクタ
ノードとトランスポートセッションを確立し、データを受信・デコードし、データストアに送信する。現時点（2019年3月）では、ベンダ毎に異なるコレクタを用いるのが一般的。
データストア
コレクタから受信したデータを格納する。Telemetry専用のソフトウェアがあるわけではなく、InfluxDBやElasticsearchといった時系列DBが用いられる。
ダッシュボード
データストアのデータを図表にするなど人間が見やすい形に表現する。Grafana、Kinaba等が用いられる。