Συχνά σφάλματα του Apache2 με το HestiaCP; Οδηγός αυτοματοποιημένης παρακολούθησης και αντιμετώπισης προβλημάτων Monit (με πλήρη διαμόρφωση)

Συχνά σφάλματα του Apache2 ή αποτυχίες αυτόματης επανεκκίνησης του Monit σε περιβάλλοντα HestiaCP ; Αυτό το άρθρο παρέχει έναν πρακτικό οδηγό για την αποφυγή συνηθισμένων παγίδων κατά την παρακολούθηση του Apache2 με το Monit, αναλύοντας σε βάθος συνηθισμένα προβλήματα όπως η κακή ευθυγράμμιση της διαδρομής PID και το μπλοκάρισμα δικαιωμάτων, και προσφέροντας αρχεία διαμόρφωσης αυτοματισμού Monit παραγωγικού επιπέδου. Κατακτήστε τώρα τις τεχνικές συντήρησης διακομιστή υψηλής διαθεσιμότητας και επιτύχετε αυτόματη αποκατάσταση δεύτερου επιπέδου από αποτυχίες!

Οι παγίδες που αντιμετώπισα κατά τη χρήση του Monit για την παρακολούθηση του Apache2

Την περασμένη Παρασκευή, ο διακομιστής μού έδωσε μια ειδοποίηση Monit στη μέση της νύχτας.

Κοίταξα τον πίνακα με ζάλη και στη στήλη κατάστασης apache2 υπήρχε ένα κόκκινο Timeout.

Το σκέφτηκα λίγο. Μόλις πρόσθεσα την παρακολούθηση Monit στον διακομιστή κατά τη διάρκεια της ημέρας και αντέγραψα και επικόλλησα τη διαμόρφωση από ένα ηλεκτρονικό σεμινάριο. Δεν θα έπρεπε να υπάρχουν προβλήματα, σωστά;

Το επόμενο πρωί, ο χρόνος έληξε ξανά. Μετά την τρίτη φορά, η οθόνη απλώς εγκατέλειψε και ο πίνακας εμφάνισε την ένδειξη "Δεν παρακολουθείται".

ΕΓΩ...

Ομολογώ, δεν το πήρα στα σοβαρά στην αρχή. Παρακολούθηση Apache2; Μπορείς να βρεις άπειρες διαμορφώσεις προτύπων στο διαδίκτυο, απλώς αντιγράψε και επικόλλησε. Αλλά αυτή η διαδικασία επικόλλησης με έκανε πραγματικά έξαλλο.

Η βασική αιτία της σύγκρουσης μεταξύ της προεπιλεγμένης αρχιτεκτονικής του HestiaCP και των ports του Monit

Επιτρέψτε μου πρώτα να σας δείξω τη διαμόρφωση που μου προκάλεσε τόσο μεγάλο πρόβλημα, ώστε να δείτε αν είναι ακριβώς η ίδια με την έκδοση που έχετε δει.

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

Φαίνεται εντάξει, σωστά; Ελέγχει τη θύρα 80 και αν κολλήσει, κάνει επανεκκίνηση. Αν εξακολουθεί να κολλάει μετά από 5 επανεκκινήσεις, λήγει το χρονικό όριο.

Το πρόβλημα είναι ότι ο Apache2 σας δεν εκτελείται καν στη θύρα 80.

Αυτή είναι μια παγίδα του HestiaCP και η βασική αιτία που πολλοί άνθρωποι το χρησιμοποιούν. Η προεπιλεγμένη αρχιτεκτονική του HestiaCP είναι ένα αντίστροφο proxy του Nginx + Apache2, με το Nginx να καταλαμβάνει τις θύρες 80 και 443 μπροστά και το Apache2 να εκτελείται στην τοπική θύρα 8081 πίσω.

Αν ζητήσετε από τον Monit να ελέγξει αν ο Apache2 είναι ενεργός στη θύρα 80, είναι σαν να πηγαίνετε στα McDonald's για να βρείτε το KFC. Ο διακομιστής σας κοιτάζει με κενό βλέμμα και εσείς οι δύο κοιτάζεστε επίμονα. Στο τέλος, ο Monit διαπιστώνει ότι δεν λειτουργεί και ξεκινάει απεγνωσμένα την επανεκκίνηση.

Μετά την επανεκκίνηση, η θύρα εξακολουθεί να είναι 8081. Στη συνέχεια, το Monit προσπαθεί να ελέγξει τη θύρα 80, η οποία επίσης αποτυγχάνει, επομένως επανεκκινείται ξανά. Αυτός ο κύκλος επαναλαμβάνεται μέχρι το Monit να αποφασίσει ότι δεν μπορεί να επισκευαστεί και να λήξει το χρονικό όριο.

Όταν το συνάντησα για πρώτη φορά, έμεινα πραγματικά έκπληκτος. Εννέα στα δέκα tutorials που βρήκα στο διαδίκτυο χρησιμοποιούσαν τη θύρα 80. Αν τα ακολουθήσατε, το πρόβλημα δεν ήταν σε εσάς, αλλά στην ίδια την πηγή των πληροφοριών.

Ένα κατεστραμμένο αρχείο Apache2 PID προκάλεσε την εσφαλμένη αναγνώριση της διεργασίας από το Monit ως ανύπαρκτη.

Μετά την αλλαγή της θύρας από 80 σε 8081, το Monit θα πρέπει θεωρητικά να είναι σε θέση να την ανιχνεύσει, σωστά;

Ωστόσο, στην πραγματικότητα, εξακολουθεί να αναφέρει περιστασιακά το μήνυμα "Η εκτέλεση απέτυχε ".

Αφού πάλεψα για πολύ καιρό, τελικά ανακάλυψα ότι ο λόγος ήταν απλός: το αρχείο PID ήταν κατεστραμμένο.

Σκεφτείτε το, ο Monit επανεκκινούσε μανιωδώς τον Apache2, κάθε φορά που τον τερματιζόταν και τον επανεκκινούσε βίαια, πηγαινοερχόμενος αρκετές φορές. Κατά τη διάρκεια αυτής της διαδικασίας, το αρχείο /var/run/apache2/apache2.pid μπορεί να γίνει 0 bytes.

Με άλλα λόγια, το αρχείο εξακολουθεί να υπάρχει, αλλά είναι άδειο.

Όταν το Monit διαβάζει αυτό το αρχείο, δεν βρίσκει τίποτα. Δεν αναγνωρίζει τον Apache2 σας, ακόμα κι αν ο Apache2 σας λειτουργεί μια χαρά στο παρασκήνιο. Το Monit δεν πιστεύει ότι η διεργασία υπάρχει.

Όταν το είδα αυτό, έμεινα άφωνος για μια στιγμή.

Αυτό αποτελεί αδιέξοδο. Το Monit αποτυγχάνει να εντοπίσει την παρουσία του Apache 2, επανεκκινεί τον Apache2, καταστρέφει το αρχείο PID κατά τη διαδικασία επανεκκίνησης, αποτυγχάνει στην επόμενη ανίχνευση και επανεκκινείται. Αυτός ο κύκλος συνεχίζεται μέχρι να λήξει το χρονικό όριο.

Βήματα αντιμετώπισης προβλημάτων και επιδιόρθωσης για την παρακολούθηση Apache2 στο περιβάλλον HestiaCP

Για να είμαι ειλικρινής, η διαδικασία έρευνας δεν είναι περίπλοκη, αλλά πρέπει να ξέρετε προς ποια κατεύθυνση να ερευνήσετε.

Το πρώτο βήμα είναι να προσδιορίσετε σε ποια θύρα ακούει ο Apache2 σας. Απλώς πληκτρολογήστε μια εντολή στο τερματικό.

netstat -tulpn | grep apache2

Εναλλακτικά, μπορείτε να χρησιμοποιήσετε την εντολή `ss`. Το αποτέλεσμα είναι το ίδιο.

ss -tulpn | grep apache2

Θα δείτε ένα αποτέλεσμα παρόμοιο με αυτό.

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

Έχει επιβεβαιωθεί ότι είναι το 8081, όχι το 80. Αυτή είναι η ρίζα του προβλήματος.

Το δεύτερο βήμα είναι να επιδιορθώσετε το κατεστραμμένο αρχείο PID. Αυτό είναι πιο απλό.

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

Αρχικά, θέστε σε παύση την παρακολούθηση του Monit για να αποτρέψετε την παρεμβολή του ενώ διορθώνετε προβλήματα. Στη συνέχεια, επανεκκινήστε το Apache2 για να του επιτρέψετε να ξαναγράψει ένα καθαρό PID. Τέλος, χρησιμοποιήστε το `cat` για να ελέγξετε το περιεχόμενο του αρχείου. Θα πρέπει να περιέχει μια συμβολοσειρά αριθμών, όχι μια κενή συμβολοσειρά.

Μόλις ολοκληρωθεί αυτό το βήμα, το πρόβλημα ουσιαστικά λύνεται.

Συγκριτική Ανάλυση Παραδοσιακών Προσαρμοστικών και Επιθετικών Προστατευτικών Διαμορφώσεων Monit

Τα διαδικτυακά σεμινάρια σχετικά με τη διαμόρφωση του Apache2 με το Monit γενικά εμπίπτουν σε δύο κατηγορίες.

Ένας τύπος είναι ο "παραδοσιακός τύπος προσαρμογής", ο οποίος χρησιμοποιεί την εντολή `service` για τη διαχείριση υπηρεσιών και τον έλεγχο τοπικών θυρών χωρίς την προσθήκη πολλών περίπλοκων περιορισμών. Αυτή η διαμόρφωση μπορεί να χρησιμοποιηθεί στο HestiaCP απλώς αλλάζοντας τη θύρα και είναι σχετικά σταθερή.

Μια άλλη προσέγγιση είναι η μέθοδος "επιθετικής προστασίας", η οποία χρησιμοποιεί το systemctl για τη διαχείριση υπηρεσιών, προσθέτει περιορισμούς σε θυγατρικές διεργασίες και εφαρμόζει αυστηρότερη λογική ανίχνευσης. Φαίνεται εξαιρετική, αλλά έχει ένα μοιραίο ελάττωμα: η εντολή διακοπής που χρησιμοποιείται είναι `killall -9`.

Τι σημαίνει το `killall -9`; Σημαίνει να τερματίσετε βίαια τη συσκευή ανεξάρτητα από το τι κάνει. Αυτή η λειτουργία ωμής βίας μπορεί εύκολα να αφήσει πίσω της κατεστραμμένα αρχεία PID, το οποίο είναι το πρόβλημα που μόλις ανέφερα.

Η προσωπική μου εμπειρία είναι ότι ο περιορισμός του αριθμού των θυγατρικών διεργασιών σε μια επιθετική διαμόρφωση είναι πράγματι χρήσιμος. Όταν ο Apache2 σας κατακλύζεται από μια επίθεση CC, ο περιορισμός του αριθμού των θυγατρικών διεργασιών μπορεί να αποτρέψει την εξάντληση της μνήμης του διακομιστή. Ωστόσο, η προσέγγιση `killall -9` είναι πραγματικά άχρηστη.

Έτσι, στο τέλος έκανα συμβιβασμούς και συνδύασα τα πλεονεκτήματα και των δύο διαμορφώσεων.

Ρύθμιση βέλτιστων πρακτικών για το HestiaCP Apache2 Monit

Τροποποιήστε το αρχείο /etc/monit/conf.d/apache2 με το ακόλουθο περιεχόμενο.

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

Επιτρέψτε μου να εξηγήσω εν συντομία τη λογική πίσω από αυτές τις λίγες γραμμές διαμόρφωσης.

Γράψτε τη θύρα 8081 ώστε να ταιριάζει ακριβώς με την αρχιτεκτονική reverse proxy του HestiaCP. Σταματήστε να γράφετε ανόητα τη θύρα 80.

Χρησιμοποιήστε την εντολή `systemctl stop` αντί για την `killall -9` για να σταματήσετε το αρχείο PID, ώστε να μην το καταστρέψετε.

Έχει προστεθεί ένα όριο θυγατρικών διεργασιών: εάν ο αριθμός των θυγατρικών υπερβεί τα 120, η διεργασία θα επανεκκινηθεί μετά από δύο συνεχόμενους κύκλους για την αποτροπή επιθέσεων CC, αλλά δεν θα είναι πολύ επιθετική.

Η λογική για την ανίχνευση βλαβών έχει τροποποιηθεί ώστε να χρησιμοποιεί μια προσέγγιση "για 2 κύκλους", που σημαίνει ότι μια επανεκκίνηση ενεργοποιείται μόνο μετά από δύο διαδοχικές βλάβες, μειώνοντας τα ψευδώς θετικά. Η προηγούμενη διαμόρφωση, η οποία επανεκκινούσε μετά από μία μόνο ανίχνευση, ήταν ειλικρινά λίγο υπερβολικά ευαίσθητη.

Το τελικό όριο χρονικού ορίου χαλαρώνει σε 5 επανεκκινήσεις εντός 10 κύκλων, αφήνοντας επαρκή ανοχή σφαλμάτων.

HestiaCP Παρακολούθηση παρακολούθησηςΣύνοψη αντιμετώπισης προβλημάτων διαμόρφωσης και κοινοποίηση εμπειρίας

Αφού έκανα τις αλλαγές στη διαμόρφωση, παρακολούθησα το apache2 και ο πίνακας τελικά έδειξε μια πράσινη ένδειξη "OK".

Πώς να περιγράψω τα συναισθήματά μου εκείνη τη στιγμή; Ήταν σαν να πέρασα δύο μέρες παλεύοντας με ένα έντομο, μόνο και μόνο για να ανακαλύψω ότι η αιτία ήταν μια μόνο γραμμή διαμόρφωσης που ήταν λανθασμένη. Ήταν ταυτόχρονα απογοητευτικό και γελοίο.

Το Monit είναι από μόνο του κάτι καλό και η παρακολούθηση των δαιμόνων είναι κάτι που κάθε διακομιστής θα έπρεπε να κάνει. Αλλά το πρόβλημα είναι ότι πολλά διαδικτυακά σεμινάρια βασίζονται στην υπόθεση ότι «το Apache2 χρησιμοποιεί αποκλειστικά τη θύρα 80», ενώ το HestiaCP χρησιμοποιεί αντίστροφο proxy, πράγμα που σημαίνει ότι αυτή η υπόθεση δεν ισχύει.

Αν ακολουθήσετε τις οδηγίες, το πρόβλημα δεν είστε εσείς. Είναι ότι το σεμινάριο εφαρμόζεται σε διαφορετικό σενάριο από το δικό σας.

Επομένως, αν χρησιμοποιείτε επίσης το HestiaCP και ασχολείστε με το Monit για την παρακολούθηση του Apache2, απλώς θυμηθείτε δύο πράγματα: Αλλάξτε την θύρα σε 8081 και χρησιμοποιήστε την εντολή `systemctl` για να την σταματήσετε, όχι την `killall -9`. Αν κάνετε αυτά τα δύο πράγματα, θα πρέπει να μπορείτε να αποφύγετε περαιτέρω προβλήματα.

Αφού διαβάσατε μέχρι εδώ, αν το βρήκατε χρήσιμο, κάντε like και κοινοποιήστε το. Αν θέλετε να λαμβάνετε ενημερώσεις πρώτοι, μπορείτε επίσης να με ακολουθήσετε!

Σας ευχαριστώ που διαβάσατε το άρθρο μου. Τα λέμε την επόμενη φορά.