In der vorherigen Analyse hatten ich mir die Nginx Access Logs angeschaut. Nun komme ich zum dritten Teil dieser Reihe. Heute betrachte ich die Error Logs. Error Logs sind hilfreich, wenn es darum geht einen groben Überblick über bestehende Probleme zu gewinnen. Wenn man an größeren Projekten arbeitet, dann verliert man schnell den Überblick über Fehler und den Status von Fehlern. Eine konsolidierte Übersicht über die Fehler würde helfen. Man könnte Fehler kategorisieren und sie nach Priorität abarbeiten. Beispielsweise die am Häufigsten erscheinenden Fehler als erstes beheben.
Es gibt bereits Analyselösungen, die diese Logs verarbeiten und in Analysen darstellen. Ich möchte diese jedoch nicht nutzen, sondern will eine einfache, lokale und transparente Lösung. Ich habe solch eine konsolidierte Sicht mit Jupyter Notebook erstellt, und möchte ein paar Analysen teilen.
In dieser Analyse werden die Logs vom bereits bekannten Zeitraum betrachtet. Ich habe ursprünglich vor gehabt, Altair für die Visualisierung zu nutzen, weil ich damit gute Erfahrungen in Kibana hatte. Altair nutzt Vega, die Visualisierungsbibliothek, die auch Kibana nutzt. Ich war nicht so ganz zufrieden mit dem Ergebnis und habe das dann verworfen.
Der erste Graph ist die absolute Anzahl der Fehlermeldungen.
Es werden täglich im Median 350 Fehlermeldungen in Nginx geworfen. Die Fehlermeldungen teilen sich auf in verschiedene Kategorien und ich wollte den täglichen Anteil der verschiedenen Kategorien betrachten. Es gibt den „Fehlerlevel“, was angibt, in was für einer Kategorie sich der Fehler befindet.
Ein Großteil der Fehlermeldungen waren tatsächlich „Error“ Meldungen. Wie verteilen sich die Fehler auf die verschiedenen Domains? Dafür kann man den Anteil der Hosts betrachten.
Im Datensatz ist auch meine Domain Sokra.Tech enthalten, weil beide Webseiten auf der selben Maschine laufen. Man kann mithilfe des Jupyter Notebooks sehr einfach auch einzelne Domains filtern und diese gesondert betrachten.
Bei den HTTP Methoden kommen die Fehler mehrheitlich von den POST Abfragen. Mal schauen, welche Ressourcen so alles angefragt werden…
Okey, hier ist sind klare Sieger sichtbar: die /.git/HEAD Datei und xmlrpc.php von WordPress. Öffentlich aufrufbare Git-Verzeichnisse sind ein Sicherheitsrisiko. Ebenfalls ist bekannt, dass die xmlrpc Datei von WordPress ein Einfallstor für viele Angriffe ist. In meinen Webserver wird der Zugang zu diesen beiden Verzeichnissen und Dateien blockiert.
Nun ist es auch interessant, die tatsächlichen Nachrichten der Fehlermeldungen zu sehen. Das kann man in dem folgenden Graphen betrachten.
Tatsächlich ist ein Großteil der Fehlermeldungen eine „access forbidden by rule“ und „directory index forbidden“ Nachricht. Die kann man vernachlässigen, weil hier kein wirklicher Fehler vorhanden ist. Die eigentlich interessanten Nachrichten sind die blauen Felder. Dort verstecken sich die PHP Fehler. Ich habe mir diese Fehler angeschaut. Es waren tatsächlich auch keine kritischen Fehler. Irgendwie bin ich doch erleichtert.
Damit will ich meine Analyse zu Nginx Logs abschließen. Die Access Logs sind zwar nicht so kritisch für die Instandhaltung, doch Error Logs müssen regelmäßig geprüft. Auf Proxer werden keine Access Logs, dafür aber Error Logs angelegt. In einer weiteren Analyse will ich dieses Tool auf die Proxer Error Logs anwenden und schauen, was da los ist.