私の本番サーバーは米国東海岸に保管されており、サポートアプリの一部はヨーロッパのアムステルダムに保管されています。米国東海岸でも実行されているNagiosインスタンスがあり、いくつかのポートチェックとsshを介したいくつかのチェックを実行します。
問題は、ほぼ毎日、mtr(tracerouteとpingの組み合わせ)を使用したパケットドロップと、約1分間続くマイナーなサービスの問題を観察することです。私はこれらのmtr出力をアムステルダムのサービスプロバイダーに見せましたが、ICMPはルーターで最も優先度が低いため、ICMP(mtrで使用)はドロップを測定する信頼できる方法ではないと彼は言って問題を否定しました。したがって、ルーターはICMPをドロップできますが、TCPには問題ありません。
サービスプロバイダーに、サービスに実際に問題があり、修正する必要があることを証明するにはどうすればよいですか?これに適したツールとテクニックは何ですか?
パケット損失を明確に証明することは困難です。
これがあなたの目標である場合、私の推奨戦略は次のとおりです。
iptables
ルールを実装して、出入りするパケットの数をカウントしますiperf
を使用して、TCPテストを一定期間(300秒など)実行しますiptables
をダンプし、パケット数を比較しますiptables
を使用する代わりに、両方のホストでインターフェースのtx/rxパケット数を確認することもできます(例:ifconfig eth0
)-テストの開始時にメモを取り、転送テストを実行します(たとえば、SCPまたはFTPを使用)-次に、一方のホストから送信されたパケットがもう一方のホストで受信されたパケットと等しいかどうかを計算します。
他のテクニックはあなたに誤った情報を与えるでしょう。ホストと中間ルーターがICMP
を低い優先度で処理するか、まったく応答しない可能性があるのは事実です。多くの場合、UDP
パケットも優先度が低いものとして扱われるため、UDPストリームを使用した制御されたiperf
テストでは誤った結果が生じる可能性があります。また、実際に送信されたパケットと受信されたパケットをカウントしないTCP
テストでは、基盤となるオペレーティングシステムがパケット損失を処理するため、多くのことが明らかになることはありません。
たぶん、smokepingをインストールして、いくつかのサービスチェック(tcp、http、http、...)を実行してみてください。それはパケット損失の素晴らしいグラフを作ることができます。
私の職場では、 Wormly というサードパーティのネットワーク監視サービスを使用しています。
主にウェブサイトが稼働していることを確認するために使用しますが、特定のポートなどをチェックすることもできます。
基本的なアカウントを取得し、ICMPに問題がある場合は、TCP接続をテストするためにいくつかのセンサーを設定できます。
グラフが作成され、プロバイダーに表示できます。
テストは世界中のいくつかのタワーから行われ、サポートチームに特定のタワーをプライマリとして設定するように依頼することができます。 (私たちはシドニーを使用しているので、グラフは私たちの地域のより現実的なpingを示しています)
TCP応答に存在する必要がある特定のテキストまたは正規表現パターンを指定することもできます。これは、かなりクールです。