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

第5章： 複数の種類のネットワークテレメトリを併用する

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

第4章の内容を踏まえ、ここでは、多種多様なデータ点が組み合わさることで、ネットワークだけでなく環境全体をより明確に把握できる方法について探っていく。 この章では、引き続きネットワークデータに焦点を絞る。第4章で単一のデータ要素が持つ力と価値について説得力のある議論を展開した後、複数の要素が絡む問題がそれほど優れているのか疑問に思うかもしれない。その点について、BBCシリーズ『シャーロック』から、私たちのお気に入りの「マインド・パレス」の場面を引用しよう。

マイクロフト：「ああ、シャーロック。偶然について、我々はどのように言っているか？」

シャーロック：「宇宙がそこまで怠惰なことはめったにない。」

『三つの印』、シャーロック 2014年

偶然の一致と同様に、宇宙はそれほど怠惰なものではない。つまり、類似性を持つ時間枠内で発生した2つ（あるいはそれ以上）のメトリックが、単なる偶然であることはめったにないのだ。 単一のドメインからのメトリックだけでは、障害について知るべきすべて――原因、調査すべき箇所、あるいは修復方法――を常に教えてくれるわけではない。本章では、2つ以上のネットワークテレメトリ要素が、インフラを最高のパフォーマンスに戻すために必要な答えと洞察を提供する、（一般的ではないにせよ現実的な）事例をいくつか紹介する。

ユースケース1：実データより合成データの方が優れている場合

問題があることはほぼ確信しているものの、それを証明するデータが不足していることがある。証明に使えるデータは分かっているが、それはシステム上のユーザが実行していない特定のアクションによって生成される特定のデータに依存している。なぜなら、ユーザは監視エンジニアにとって有益なことではなく、自分たちがやりたいことをわがままに主張するからだ。

しかし、その場限りのメトリック（例：SNMP経由のパケットエラー）を超えて見ようとする人にとって、解決策がある。それが「合成トランザクション」だ。 合成トランザクションの基本的な考え方はこうだ。自動化されたシステムが、1か所（または複数か所）から定期的に1つ（または複数）のアクションを実行する。そのアクションによって、対象システムのパフォーマンスが把握できる。このパターンと繰り返しにより、ユーザがそのシステム部分を積極的に利用していない時でも、パフォーマンスメトリックを収集できる。複数の場所からテストを行うことで、サイト全体で遅延・ダウン・不安定な状態にあるのか、それとも特定の場所から、あるいは特定の経路経由で接続しているユーザに限った問題なのかを特定できる。

なぜこれが重要なのか？ 第一に、ネットワークメトリックやトラフィックデータだけでは通常、パフォーマンスは把握できないが、合成テストならその実態を明らかにできるからだ。

これらを踏まえると、当社のマルチメトリクス解決策は、以下の図のような形になるだろう。

メトリック 1：パケットエラー（SNMP経由）

図5-1では、特定のインタフェースにおけるパケットエラーが示されており、これはインタフェース自体に何らかの問題があることをアラートしている。しかし、これは他の誰かの体験に影響を与えているのだろうか？

図 5-1. 単一の IP におけるパケット エラー（この図の拡大版を見る）