最新ネットワーク・テレメトリー実践ガイド (Japanese Edition)

第4章 テレメトリの個別活用

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

第3章の最後に述べたように、収集されたデータの管理方法（第2章）と可観測性ソフトウェアとのやり取り方法（第3章）について解説したところで、ここでは具体的なユースケースと実世界でのアプリケーションを探っていく。 これにより、読者の皆様が自身の実装の基盤となる具体的な例を得られ、それぞれの環境でデータを有効活用できるようになることを願っている。

この探求の道筋——詳細な実世界の例——は、本書の残りの部分でも継続される。第4章、第5章、第6章の違いは、それぞれの章で焦点を当てる範囲が、個々の要素から複数の要素へ、そして（ほぼ）アプリケーションスタック全体へと広がっていく点にある。

データの形態

まずは、個々のデータ点が、ネットワーク、インフラ、環境を理解する上でどのように役立つかから始めよう。これらのデータは通常、4つの異なる形態のいずれかをとっている。これらを単に教条的に説明するわけではない。むしろ、これらの説明は、後に続くユースケースの基礎となるものだ。

メトリック

メトリックの目的は、特定の時点における要素、システム、またはデバイスの測定値を提供することだ。これらは監視の黎明期から存在しており、¹ 宇宙の熱的死が訪れるまで、他のあらゆる種類のテレメトリよりも長く存続すると予測されている。

メトリックは、システムが稼働中かダウンしているか、容量がいっぱいか（そうでない場合は残り容量はいくらか）、さらには何かが「燃え上がっている」こと（その場合、どれほど激しく燃えているか）に至るまで、あらゆる情報を伝えるために使われる。

誇張した表現はさておき、システムから単一の値——数値、ステータス（稼働中／停止中／HELP!）、あるいはそれらに対応するコード——が返ってくる時はいつでも、それはメトリックだ。

メトリック自体は興味深いものだが、相対的なコンテキスト、多くの場合履歴と照らし合わせて考える必要がある。確かに、このインタフェースで1.7GBのトラフィックを通している。これは多いのか？

唯一の答えは「場合による」だ。インタフェースの容量や時間枠といった明白な要素（図4-1参照）だけでなく、このシステムにとっての「通常」がどのような状態かにも依存する。もしこのインタフェースのトラフィックが通常1時間あたり10〜50MBの範囲にあり、それが1.7GBという数値まで急増したのなら、それは注目に値する。

図4-1. Nano Banana（およびAviとLeonの両親）が作成したコンテンツを改変したもの

トラフィック

トラフィックのテレメトリは、メトリックに「方向性」という追加のコンテキストを与える。関連するデータセットについて、その発信元は何か、宛先は何か、そしてデータはどのような経路を通っているのか。

トラフィックデータの目的は、「顧客によるコストはいくらか？」（および「この地域やこのリファラーからの顧客によるコストはいくらか？」）といった質問に答えること、あるいは「現在DDoS攻撃を受けているか？」といった、より根本的な疑問に答えることにある。

パフォーマンス

パフォーマンス・テレメトリは、システム、要素、またはデバイスへの影響、すなわちそれ自体への影響、あるいは関連するシステム、要素、および／またはデバイスへの影響を明らかにする。パフォーマンスデータは通常、ping、traceroute、TCPまたはUDPテスト、あるいはレイヤー4以上のエンドポイントやアプリケーションのトランザクションテストといった、合成データ（実際のユーザートラフィックではない）から得られる。 ...