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