ネットワーク接続の監視は、サーバー管理の重要な部分です。 pingのようないくつかのツール traceroute 使い方は簡単で、貴重な情報を提供します。今日は、 tracerouteの機能を組み合わせたMTRと呼ばれる別の強力な診断ツールを紹介します。 およびping プログラム。 MTRはMy Traceroute -の略です これにより、ホストとリモートサーバー間のネットワーク接続を調査できます。また、時間の経過に伴う遅延とパフォーマンスの変化も提供します。 tracerouteとは異なり およびping 、MTRはデフォルトでは付属していません。インストールする必要があります：
MTRのインストール方法：
Ubuntu / Debianの場合：
sudo apt-get install mtr
CentOS / Redhat / Fedoraの場合：
Redhatを使用していて、yumの更新を取得しない場合は、RedhatシステムでCentOSリポジトリを使用するようにyumを構成する方法に従ってください。
yum install mtr Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile ---> Package mtr.x86_64 2:0.75-5.el6 will be installed --> Finished Dependency Resolution ... ... Installed: mtr.x86_64 2:0.75-5.el6 Complete!
MTRの使用方法
正常にインストールされたら、次のように入力して使用を開始できます。
mtr google.com
グラフィカルインターフェースモードとテキストベースモードの2つのモードがあります（ ncurses ）。デフォルトのモードはグラフィカルインターフェイスモードです。
テキストモードでMTRを起動する方法
テキストベースのモードを指定するには、以下のコマンドを使用する必要があります。このコマンドは、 ncursesを使用してテキストベースのユーザーインターフェースを開きます 、インタラクティブモードで継続的に実行されます。
mtr --curses google.com
パケット（ICMP）は、一連の「ホップ」（ルーターまたはノード）を通過して宛先に到達します。出力はtracerouteと非常によく似ていますが、tracerouteに対する大きな利点は、出力が現在のラウンドトリップ時間で常に更新されることです。
MTRを使用してレポートを生成する方法
インタラクティブモードで実行する代わりに、レポートを生成するために以下のコマンドが発行されます。デフォルトでは、MTRはターゲットホストに10パケットを送信し、ネットワーク統計を出力するのに時間がかかります。番号を変更できます。オプション–report-cycles=[number-of-packets]を指定してパケットの数を増やします。このモードは、有用な形式で十分なデータを提供します。
mtr --report google.com or mtr --report --report-cycles=12 google.com
逆引きDNSを回避する方法
ネットワークトレース中に、MTRは逆引きDNSルックアップを使用して各希望のホスト名（ルーター/ノード）を見つけます。 DNSの逆引き参照を避けたい場合は、–no-dnsオプションを使用してください：
mtr --no-dns google.com
MTR出力を理解する
MTRは、ホストとリモートサーバー間のパスを超えて、以下の出力に示すように、7番目の列にその接続の耐久性に関する貴重な統計を提供します。
Loss％–各ホップでのパケット損失の割合を示します。
Snt –送信されたパケットの数を示します。
Last –最後に送信されたパケットの遅延。
Avg –すべての平均遅延パケット。
ベスト–このホストへのパケットのベスト（最短）ラウンドトリップ時間。
ワースト–このホストへのパケットのワースト（最長）ラウンドトリップ時間。
StDev–標準偏差各ホストへの遅延の割合。
最後に、Avg、Best、およびWrstはすべてミリ秒単位で測定されます。標準偏差が高いほど、レイテンシの測定値に一貫性がありませんでした。
たとえば、上記の文を理解するために考えてみましょう。宛先に送信された10個のパケットのうち、一部のパケットは25ミリ秒の低遅延である可能性がありますが、350ミリ秒の高遅延を持つパケットはほとんどありません。送信された10個のパケットの遅延を平均した後、平均は正常に見えますが、実際にはデータをうまく表していない可能性があります。したがって、標準偏差が高い場合は、レイテンシ測定の最良の列と最悪の列を調べて、平均が実際のレイテンシを適切に表しており、変動が大きすぎる結果ではないことを確認してください。
MTRレポートの分析
宛先ホストに到達できません
宛先ホストが適切に構成されていないか、ファイアウォールルールがICMPパケットをドロップするように構成されている場合、以下に示すように、パケットが宛先に到達できなかったように見えます。しかし、それは目的地に到達します。
8. 10.118.225.253 0.0% 10 19.0 19.0 18.9 19.2 0.1 9. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
パケット損失を確認する方法
サービスプロバイダーは、ICMPトラフィックを制限するという一般的な方法に従います。これは、実際には損失がない場合に、パケット損失として表示される可能性があります。ネクストホップのLoss％列をチェックすることにより、損失が実際のものであるか、レート制限によるものであるかを確認できます。たとえば、以下のレポートでは、100％の損失のネクストホップは0.0％を示しています。したがって、損失はICMPレート制限によるものであり、実際の損失によるものではないことは確かです。
5. 10.161.18.5 0.0% 5 14.7 14.5 14.4 14.7 0.1 6. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 7. 10.255.222.34 0.0% 5 14.1 14.0 13.9 14.2 0.2
タイムアウトとリターンルートの問題
ホップのいずれかが???を示している場合 出力では、リターンパスの問題が原因であるか、ルーターがICMPパケットを破棄した可能性があります。以下のホップ6で、 ???を見ることができます。 。これは、上記の理由のいずれかが原因である可能性があります。
5. 10.161.18.5 0.0% 5 14.7 14.5 14.4 14.7 0.1 6. ??? 100.0 5 0.0 0.0 0.0 0.0 0.0 7. 10.255.222.34 0.0% 5 14.1 14.0 13.9 14.2 0.2
結論
MTRは、内部ネットワークのトラブルシューティングやネットワークの問題が発生した場合に非常に役立ちます。 MTRレポートを使用すると、リモートホストまたは特定のドメインに向かう途中のどのルーター/ホストが問題の原因であるかを把握できます。