Die Überwachung der Netzwerkkonnektivität ist ein wichtiger Bestandteil der Serververwaltung. Wenige Tools wie ping, Route verfolgen sind einfach zu verwenden und bieten wertvolle Informationen. Heute zeige ich Ihnen ein weiteres leistungsstarkes Diagnosetool namens MTR, das die Funktionen von traceroute kombiniert und ping Programme. MTR steht für My Traceroute - Damit können Sie die Netzwerkverbindung zwischen dem Host und dem Remote-Server untersuchen. Es stellt auch die Latenz- und Leistungsänderungen im Laufe der Zeit bereit. Im Gegensatz zu traceroute und ping , MTR ist nicht standardmäßig enthalten. Sie müssen es installieren:
So installieren Sie MTR:
Auf Ubuntu/Debian:
sudo apt-get install mtr
Auf CentOS/Redhat/Fedora:
Wenn Sie Redhat verwenden und keine Yum-Updates erhalten, befolgen Sie die Anweisungen zum Konfigurieren von Yum für die Verwendung von CentOS Repo auf einem RedHat-System.
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!
Wie man MTR verwendet
Sobald es erfolgreich installiert ist, können Sie es verwenden, indem Sie Folgendes eingeben:
mtr google.com
Es gibt zwei Modi, einen Grafikschnittstellenmodus und einen textbasierten Modus (ncurses ). Der Standardmodus ist der Modus der grafischen Benutzeroberfläche.
So starten Sie MTR im Textmodus
Um den textbasierten Modus festzulegen, müssen Sie den folgenden Befehl verwenden. Der Befehl öffnet eine textbasierte Benutzeroberfläche mit ncurses , die kontinuierlich im interaktiven Modus ausgeführt wird.
mtr --curses google.com
Die Pakete (ICMP) durchlaufen eine Reihe von „Hops“ (Router oder Knoten) und erreichen das Ziel. Die Ausgabe kann Traceroute sehr ähnlich sehen, aber der große Vorteil gegenüber Traceroute besteht darin, dass die Ausgabe ständig mit der aktuellen Roundtrip-Zeit aktualisiert wird.
Erstellung eines Berichts mit MTR
Der folgende Befehl wird ausgegeben, um den Bericht zu generieren, anstatt im interaktiven Modus ausgeführt zu werden. Standardmäßig sendet MTR 10 Pakete an den Zielhost und braucht eine Weile, um die Netzwerkstatistiken auszudrucken. Sie können die Nr. ändern. von Paketen durch Angabe der Option –report-cycles=[number-of-packets]. Dieser Modus liefert ausreichend Daten in einem nützlichen Format.
mtr --report google.com or mtr --report --report-cycles=12 google.com
So vermeiden Sie Reverse-DNS
Während der Netzwerkverfolgung findet MTR den Hostnamen jeder Hoffnung (Router/Knoten) mithilfe von Reverse-DNS-Lookup. Wenn Sie eine umgekehrte DNS-Suche vermeiden möchten, verwenden Sie einfach die Option –no-dns:
mtr --no-dns google.com
MTR-Ausgabe verstehen
Über den Pfad zwischen dem Host und dem Remote-Server hinaus liefert MTR in der siebten Spalte wertvolle Statistiken zur Dauerhaftigkeit dieser Verbindung, wie in der folgenden Ausgabe zu sehen ist.
Loss % – Zeigt den Prozentsatz des Paketverlusts bei jedem Hop an.
Snt – Zeigt die Anzahl der gesendeten Pakete an.
Last – Latenz des letzten gesendeten Pakets.
Avg – Durchschnittliche Latenz aller Pakete.
Best – Beste (kürzeste) Roundtrip-Zeit für ein Paket zu diesem Host.
Wrst – Schlechteste (längste) Roundtrip-Zeit für ein Paket zu diesem Host.
StDev – Standardabweichung der Latenzen zu jedem Host.
Last, Avg, Best und Wrst werden alle in Millisekunden gemessen. Je höher die Standardabweichung, desto uneinheitlicher waren die Latenzmessungen.
Betrachten Sie beispielsweise ein Beispiel, um den obigen Satz zu verstehen:Von den 10 an das Ziel gesendeten Paketen können einige Pakete eine niedrige Latenz von 25 ms haben, während wenige eine hohe von 350 ms haben würden. Nachdem die Latenzen der 10 gesendeten Pakete gemittelt wurden, sieht der Durchschnitt normal aus, repräsentiert die Daten jedoch möglicherweise nicht sehr gut. Wenn also die Standardabweichung hoch ist, sehen Sie sich die besten und schlechtesten Spalten für Latenzmessungen an, um sicherzustellen, dass der Durchschnitt die tatsächliche Latenz gut darstellt und nicht das Ergebnis zu großer Schwankungen ist.
Analyse von MTR-Berichten
Zielhost nicht erreichbar
Wenn der Zielhost nicht richtig konfiguriert ist oder Firewallregeln so konfiguriert wurden, dass die ICMP-Pakete verworfen werden, sehen Sie es so, als könnten die Pakete das Ziel nicht erreichen, wie unten gezeigt. Aber es erreicht das Ziel.
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
Verifizierung von Paketverlust
Der Dienstanbieter befolgt eine gängige Praxis zur Begrenzung des ICMP-Verkehrs. Dies könnte sich als Paketverlust zeigen, obwohl eigentlich kein Verlust vorliegt. Sie können überprüfen, ob der Verlust echt ist oder auf eine Ratenbegrenzung zurückzuführen ist, indem Sie die Spalte Verlust % des nächsten Hops überprüfen. Beispielsweise zeigt im folgenden Bericht der nächste Hop von 100 % Verlust 0,0 %. Es ist also sicher, dass der Verlust auf die ICMP-Ratenbegrenzung und nicht auf den tatsächlichen Verlust zurückzuführen ist.
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
Zeitüberschreitungs- und Rückroutenproblem
Wenn einer der Hops ??? anzeigt in der Ausgabe, kann es entweder am Problem im Rückweg liegen oder alternativ hätten die Router das ICMP-Paket verworfen. Unten bei Hop 6 sehen Sie ??? . Dies kann einen der oben genannten Gründe haben.
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
Schlussfolgerung
MTR ist eine große Hilfe bei der Fehlersuche in einem internen Netzwerk oder bei Netzwerkproblemen. Mithilfe von MTR-Berichten können Sie feststellen, welche Router/Hosts auf dem Weg zum Remote-Host oder eine bestimmte Domäne das Problem verursachen.