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等が用いられる。