Häufige Abstürze von Apache2 mit HestiaCP? Monit-Leitfaden für automatisierte Überwachung und Fehlerbehebung (mit vollständiger Konfiguration)

Häufige Apache2-Abstürze oder Probleme mit dem automatischen Neustart von Monit in HestiaCP- Umgebungen? Dieser Artikel bietet eine praktische Anleitung, um typische Fehler bei der Überwachung von Apache2 mit Monit zu vermeiden. Er analysiert häufige Probleme wie fehlerhafte PID-Pfade und blockierte Berechtigungen und stellt produktionsreife Monit-Automatisierungskonfigurationsdateien bereit. Meistern Sie jetzt Techniken zur Wartung hochverfügbarer Server und erreichen Sie die automatische Wiederherstellung nach Ausfällen!

Die Fallstricke, auf die ich bei der Verwendung von Monit zur Überwachung von Apache2 gestoßen bin

Letzten Freitag erhielt ich mitten in der Nacht eine Monit-Warnung vom Server.

Benommen blickte ich auf das Bedienfeld, und in der Spalte „apache2 status“ stand ein roter Timeout.

Ich habe kurz darüber nachgedacht. Ich habe Monit Monitoring tagsüber auf dem Server installiert und die Konfiguration aus einem Online-Tutorial kopiert. Da sollte es doch keine Probleme geben, oder?

Am nächsten Morgen trat erneut eine Zeitüberschreitung auf. Nach dem dritten Mal gab der Monitor einfach auf, und auf dem Bedienfeld wurde „Nicht überwacht“ angezeigt.

ICH...

Ich gebe zu, anfangs habe ich es nicht ernst genommen. Apache2-Monitoring? Man findet online haufenweise Konfigurationsvorlagen, einfach kopieren und einfügen. Aber dieses Einfügen hat mich echt wütend gemacht.

Die Hauptursache des Konflikts zwischen der Standardarchitektur von HestiaCP und den Monit-Ports

Ich zeige Ihnen zunächst die Konfiguration, die mir so viele Probleme bereitet hat, damit Sie sehen können, ob sie genau mit der Version übereinstimmt, die Sie gesehen haben.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

Es scheint alles in Ordnung zu sein, oder? Es prüft Port 80, und wenn es abstürzt, startet es neu. Stürzt es nach fünf Neustarts immer noch ab, tritt ein Timeout auf.

Das Problem ist, dass Ihr Apache2 gar nicht auf Port 80 läuft.

Dies ist eine Schwachstelle von HestiaCP und die Hauptursache dafür, dass viele Nutzer darauf hereinfallen. Die Standardarchitektur von HestiaCP ist ein Reverse-Proxy aus Nginx und Apache2, wobei Nginx die Ports 80 und 443 belegt und Apache2 auf dem lokalen Port 8081 läuft.

Wenn man Monit bittet, die Verfügbarkeit von Apache2 auf Port 80 zu prüfen, ist das, als würde man bei McDonald's nach KFC suchen. Der Server schaut einen ratlos an, und man steht ratlos da. Schließlich stellt Monit fest, dass der Server nicht erreichbar ist, und versucht ihn hektisch neu zu starten.

Nach dem Neustart ist der Port weiterhin 8081. Monit versucht daraufhin, Port 80 zu testen, was ebenfalls fehlschlägt, sodass es erneut neu startet. Dieser Zyklus wiederholt sich, bis Monit feststellt, dass es nicht mehr repariert werden kann und einen Timeout auslöst.

Als ich das zum ersten Mal sah, war ich wirklich verblüfft. Neun von zehn Anleitungen, die ich online fand, verwendeten Port 80. Wenn man ihnen gefolgt war, lag das Problem nicht bei einem selbst, sondern an der Informationsquelle.

Eine beschädigte Apache2-PID-Datei führte dazu, dass Monit den Prozess fälschlicherweise als nicht existent identifizierte.

Nach der Änderung des Ports von 80 auf 8081 sollte Monit dies theoretisch erkennen können, oder?

In der Realität wird jedoch gelegentlich immer noch die Fehlermeldung „Ausführung fehlgeschlagen “ angezeigt.

Nach langem Herumprobieren entdeckte ich schließlich, dass der Grund ganz einfach war: Die PID-Datei war beschädigt.

Man stelle sich vor: Monit startete Apache2 ständig neu, beendete und startete es jedes Mal zwangsweise neu, und das mehrmals hintereinander. Dabei konnte die Datei `/var/run/apache2/apache2.pid` auf 0 Byte anwachsen.

Anders ausgedrückt: Die Datei ist noch vorhanden, aber sie ist leer.

Wenn Monit diese Datei liest, findet es nichts. Es erkennt Ihren Apache2-Server nicht, obwohl dieser im Hintergrund einwandfrei läuft; Monit geht davon aus, dass der Prozess nicht existiert.

Als ich das sah, war ich einen Moment lang sprachlos.

Dies ist eine Sackgasse. Monit kann die Apache-2-Instanz nicht erkennen, startet Apache2 neu, beschädigt dabei die PID-Datei, schlägt bei der nächsten Erkennung fehl und startet erneut. Dieser Zyklus wiederholt sich, bis ein Timeout auftritt.

Schritte zur Fehlerbehebung und Reparatur für die Apache2-Überwachung in einer HestiaCP-Umgebung

Ehrlich gesagt ist der Ermittlungsprozess nicht kompliziert, aber man muss wissen, in welche Richtung man ermitteln soll.

Im ersten Schritt muss ermittelt werden, auf welchem ​​Port Ihr Apache2-Server lauscht. Geben Sie dazu einfach einen Befehl im Terminal ein.

netstat -tulpn | grep apache2

Alternativ können Sie den Befehl `ss` verwenden; der Effekt ist derselbe.

ss -tulpn | grep apache2

Sie werden eine ähnliche Ausgabe sehen.

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

Es ist bestätigt, dass es 8081 ist, nicht 80. Das ist die Wurzel des Problems.

Der zweite Schritt besteht darin, die beschädigte PID-Datei zu reparieren. Das ist einfacher.

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

Pausieren Sie zunächst die Monit-Überwachung, um Störungen während der Fehlerbehebung zu vermeiden. Starten Sie anschließend Apache2 neu, damit eine neue Prozess-ID (PID) vergeben wird. Überprüfen Sie abschließend den Dateiinhalt mit `cat`; er sollte eine Zahlenfolge und keine leere Zeichenkette enthalten.

Sobald dieser Schritt abgeschlossen ist, ist das Problem im Grunde gelöst.

Vergleichende Analyse der traditionellen adaptiven und aggressiven Schutzkonfigurationen von Monit

Online-Tutorials zur Konfiguration von Apache2 mit Monit lassen sich im Allgemeinen in zwei Kategorien einteilen.

Eine Variante ist die „traditionelle Anpassungsmethode“, die den Befehl `service` verwendet, um Dienste zu verwalten und lokale Ports zu überprüfen, ohne dabei zu viele komplizierte Einschränkungen einzuführen. Diese Konfiguration kann unter HestiaCP durch einfaches Ändern des Ports verwendet werden und ist relativ stabil.

Ein anderer Ansatz ist die Methode des „aggressiven Schutzes“, die systemctl zur Verwaltung von Diensten nutzt, Einschränkungen für untergeordnete Prozesse hinzufügt und eine strengere Erkennungslogik verwendet. Das klingt vielversprechend, hat aber einen fatalen Fehler: Der verwendete Stoppbefehl lautet `killall -9`.

Was bedeutet `killall -9`? Es bedeutet, das Gerät unabhängig von seinen aktuellen Aktivitäten zwangsweise zu beenden. Diese radikale Vorgehensweise kann leicht beschädigte PID-Dateien hinterlassen, was das eben erwähnte Problem darstellt.

Meine Erfahrung zeigt, dass die Begrenzung der Anzahl von Kindprozessen in einer aggressiven Konfiguration durchaus sinnvoll ist. Wenn Ihr Apache2-Server durch einen CC-Angriff überlastet wird, kann die Begrenzung der Kindprozesse verhindern, dass der Speicher des Servers erschöpft ist. Die Methode `killall -9` ist jedoch völlig unbrauchbar.

Am Ende habe ich also einen Kompromiss gefunden und die Vorteile beider Konfigurationen kombiniert.

HestiaCP Apache2 Monit Best Practice Konfiguration

Ändern Sie die Datei /etc/monit/conf.d/apache2 mit folgendem Inhalt.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

Ich möchte Ihnen kurz die Logik hinter diesen wenigen Konfigurationszeilen erläutern.

Schreiben Sie Port 8081, um die Reverse-Proxy-Architektur von HestiaCP exakt abzubilden; hören Sie auf, fälschlicherweise Port 80 zu schreiben.

Verwenden Sie den Befehl `systemctl stop` anstelle von `killall -9`, um die PID-Datei zu stoppen und sie nicht zu beschädigen.

Es wurde eine Begrenzung der Kindprozesse hinzugefügt: Wenn die Anzahl der Kindprozesse 120 überschreitet, wird der Prozess nach zwei aufeinanderfolgenden Zyklen neu gestartet, um CC-Angriffe zu verhindern. Dies ist jedoch nicht zu aggressiv.

Die Logik zur Fehlererkennung wurde so angepasst, dass sie nach zwei aufeinanderfolgenden Fehlern einen Neustart auslöst. Dadurch werden Fehlalarme reduziert. Die vorherige Konfiguration, die bereits nach einem einzigen Fehler einen Neustart durchführte, war ehrlich gesagt etwas überempfindlich.

Der endgültige Timeout-Schwellenwert wurde auf 5 Neustarts innerhalb von 10 Zyklen gelockert, wodurch eine ausreichende Fehlertoleranz gewährleistet wird.

HestiaCP Monit-ÜberwachungZusammenfassung der Fehlerbehebung bei der Konfiguration und Erfahrungsaustausch

Nachdem ich die Konfigurationsänderungen vorgenommen hatte, überwachte ich apache2, und im Panel wurde schließlich ein grünes „OK“-Indikator angezeigt.

Wie soll ich meine damaligen Gefühle beschreiben? Es war, als hätte ich zwei Tage lang mit einem Fehler gekämpft, nur um dann festzustellen, dass die Ursache eine einzige fehlerhafte Konfigurationszeile war. Es war gleichermaßen frustrierend und lächerlich.

Monit ist an sich eine gute Sache, und die Überwachung von Serverdiensten sollte auf jedem Server erfolgen. Das Problem ist jedoch, dass viele Online-Tutorials von der Annahme ausgehen, dass „Apache2 ausschließlich Port 80 verwendet“, während HestiaCP einen Reverse-Proxy nutzt, weshalb diese Annahme nicht zutrifft.

Wenn Sie die Anweisungen befolgen, liegt das Problem nicht an Ihnen; es liegt daran, dass das Tutorial für ein anderes Szenario als Ihres gilt.

Wenn Sie also auch HestiaCP verwenden und mit Monit Apache2 überwachen, beachten Sie bitte Folgendes: Ändern Sie den Port auf 8081 und verwenden Sie zum Stoppen den Befehl `systemctl`, nicht `killall -9`. Wenn Sie diese beiden Schritte befolgen, sollten Sie weitere Probleme vermeiden können.

Da du bis hierher gelesen hast: Wenn dir der Beitrag gefallen hat, teile ihn bitte. Wenn du als Erster über Neuigkeiten informiert werden möchtest, kannst du mir auch folgen!

Vielen Dank fürs Lesen meines Artikels. Bis zum nächsten Mal.