TCP/UDPやgRPC、NETCONFなどを選択可能SNMPはUDPによる通信のみを採用していましたが、Telemetryではメッセージをどのような形式で記述し、どのような通信形式で送るかを決めることができます。取得したい情報の性質や、運用で既に採用しているプロトコルなどを考慮しながら決めることをお勧めします。CollectorはPublisherが発行したメッセージを受信する役割を持ちます。2021年8月時点の主なCollector実装を下記の表にご紹介します。-上記でご紹介したベンダ純正実装は、単体のCollectorではなくSubscriberとしての可視化や自動化の機能を備えています。Collectorごとに特徴や存在する機能が異なるため、例えばPublisherのグループ化やKafkaとの連携など、必要な機能を考慮し選定することをお勧めします。Queueが該当します。Pub/Sub・SQSなどが挙げられます。一般的な実装では、クラスタリングやミラーリングなど、冗長化を行う仕組みを持つことが多いです。Queue的な役割を示します。Publisherが発行するメッセージにはTopicとデータが含まれています。Brokerは受信したメッセージをTopicごとのキューに格納した後、Subscriberからの購読に応じてメッセージを送信します。SubscriberSubscriberはメッセージの受信者であり、データを受け取り利用する要素です。Subscriberはユースケースごとに様々な機能・パイプラインを持ちます。Com内にて実施した検証についてご紹介します。Comの社内ネットワーク環境において検証を実施しました。図9に構成図の一部を示します。検証ではPublisher/Subscriberをそれぞれ多重化し、Brokerに収容しています。監視対象の機器はArista・Cisco・Juniperと、Whiteboxな伝送装置に搭載されたSONiCの4ベンダを採用しています。Cloudと連携が行えることも検証しました。図10、図11にそれぞれから取得した実際のデータをJSON形式で示します。図10はArista機器で発行し、ockafkaを通じ取得したデータの例です。図の通り、データは単発のJSON型となっています。図11はその他の機器から取得したデータの例です。図の通り、Juniper/TelegrafではネストされたJSON型になっており、SONiC、gNMIcはJSON型の中にリストが含まれています。Cisco/Pipelineでは複数のJSON型がリストに含まれる形式であることがわかります。このようなデータは直接InfluxDBに取り込むことができないため、整形処理が必要となります。LogstashやTelegrafといったコレクタには整形機能が存在しますが、デバッグが難しい、複雑な条件分岐を書きにくいなど、汎用性に問題がありました。そこで、今回の検証ではデータ整形機を作成し対応しました。図12にデータ整形機を含めたフローを示します。作成したデータ整形機は、まずKafkaから生データが含まれるTopicを購読し、データを取得します。Scriptで整形した後、Kafkaに対して取得したものとは異なるTopicでメッセージを発行します。これにより、Subscriberがデータ整形機の発行したTopicを指定することで、整形後のデータを取得できるようにしています。図13に、実際に取得したデータをGrafanaで可視化した例を示します。今回の検証では、TelemetryとSNMPで、Interfaceの受信したTraffic量の可視化を行いました。Telemetryは1000ms(Junosのみ2000ms)、SNMPでは負荷を考慮し、一般的に1分以上の間隔で取得することが多いですが、今回はPrometheusが取得可能であった15秒間隔でデータを採り、比較しています。図13ではマイクロバーストの検知を想定しバーストトラフィックを生成しております。結果の通り、Telemetryではリアルタイムで複数のスパイクが観測されますが、SNMPでは、Pollingによる遅延が入った後、なだらかな山となり可視化が行われていることが読み取れます。Com内での検証を通じて得られた知見と期待されるユースケースをご紹介します。導入時に考慮すべき点として、下記3点が挙げられます。パラメータを指定する必要があります。マルチベンダ環境における効率的な管理のため、例えばNetbox・Zabbix等でデバイス情報を管理しているネットワークでは、それらの情報と組み合わせ、ベンダごとに設定を切り替える仕組みを開発することで、管理コストを下げることが期待できます。データの保持期間と粒度Telemetryはms単位での情報取得が可能であるため、取得した大量のデータを長期にわたって保持することが現実的ではありません。そのため、Telemetry導入の際にはデータの保持期間や保持する時間的な粒度などの事前検討が必要となります。障害発生後の切り分け(1日-2日以内の詳細なデータが必要)の2種が想定されます。1、2どちらのユースケースでも、詳細なデータは1日-2日のみ保持し、それを過ぎたものはデータを時間単位などで集約して保持すれば良いと考えます。監視基盤の性能2.の内容とも関連しますが、Telemetryを導入する際にはネットワーク規模と取得データと量・保持期間に従い、事前に監視基盤のメモリやストレージ等のリソースを計算しておく必要があり、導入前の検証が必須となります。Telemetryに期待されるユースケースこれまでの結果より、現時点のユースケースとして下記の3点を考えています。組み合わせ他の監視技術との連携1.については、OpenConfigでの実装が追いついていない部分もベンダネイティブなSensor-Pathにより情報を取得でき、またベンダごとの独自機能や純正Collectorの利用が可能です。Happened等)を利用できるなどの利点が存在します。2.については、共有のgNMIを利用して監視・自動化が可能である利点を生かし、Telemetryにより振る舞いを監視し、閾値や機械学習ベースでのコンフィグ変更・自己治癒などの利用が考えられます。3.については、例えばTelemetryのStatisticをxFlowのリアルタイムなフローと組み合わせ利用する、SyslogアラートをトリガーとしTelemetryのState・Statisticを保存するなど、高精細な情報を生かす手法が考えられます。どの用途についても、今後OpenConfig対応の充実やCollector・Dial-Out対応などの統一により、マルチベンダ対応が進むことにより、より利用しやすい技術となると期待しています。Comでの技術検証を通じ、Telemetryの下記3点の特徴を検証しました。SNMPと比較し低負荷な設計によるリアルタイムな情報取得OpenConfigによるベンダフリーな情報取得Pub/Subモデルの導入が容易な設計による高い規模性2021年8月時点の実装では、リアルタイムな情報取得はms単位での情報取得・低負荷なプロトコル設計等により期待通りの強みがありますが、マルチベンダ性に課題があるというのが検証から得られた所感です。OpenConfigの対応状況やCollectorの統一については、これからますます実装が進むと予想されるため、今後の発展に期待しています。今回の検証で用いた各機器のコンフィグ例を共有します。お手元での検証にご利用ください。Comは明示的・黙示的を問わず一切の保証をせず、何ら責任を負いません。Arista本体側はgNMI設定か専用デーモンを立ち上げるかの2択。4.22以降ではgNMI設定が推奨されている。OpenConfigの場合はTerminAttrをOpenConfigに読みかえる。ockafaka(Dockerでの立ち上げ例)手順は公式リポジトリを参照。openconfigbeat(Dockerでの立ち上げ例)手順は公式リポジトリを参照。Applications)設定IOS-XR標準のマネジメントVRF以外でTelemetryを扱う場合に必要。Pipeline手順は公式リポジトリを参照。20.2R1以降でDial-Outにも対応しているが、対応するOSSのCollector実装が存在しないため未検証。TelegrafJuniper公式のCollector実装であるjtimonも存在するが、Kafkaとの連携機能が存在しないため本検証ではTelegrafのモジュールを採用。svcを実行し、待ち受けポートを確認しておく。手順は公式ページ参照。エンジニアが社内の取り組みを紹介するブログです。2014引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。