Μη σταματάτε στο πρώτο σφάλμα.
Το πρώτο σφάλμα που βρίσκετε σχεδόν ποτέ δεν είναι το μόνο. Η μέθοδός μας για να ξεμπλέξετε μια κατάρρευση με πολλές αιτίες: κατατάξτε τις αιτίες κατά συνεισφορά και όχι κατά ένταση, διαβάστε πρωτογενείς πηγές σε επίπεδο πυρήνα αντί για dashboards, ξεφλουδίστε ένα σφάλμα τη φορά, και αντιμετωπίστε κάθε σύμπτωμα που επιστρέφει ως ολοκαίνουργια διάγνωση.
Σε αυτό το άρθρο 6 ενότητες
- Σε μια κατάρρευση με πολλά σφάλματα, αρκετά σφάλματα φορούν το ίδιο σύμπτωμα ταυτόχρονα. Η διόρθωση του πιο δυνατού μοιάζει με πρόοδο και δεν αλλάζει σχεδόν τίποτα.
- Η μέθοδος: κατατάξτε τις αιτίες κατά συνεισφορά, όχι κατά ένταση. Διορθώστε με αυτή τη σειρά. Μετρήστε ξανά στο όριο που απέτυχε μετά από κάθε αλλαγή.
- Όταν μια διόρθωση κρατάει και το σύμπτωμα επιστρέφει, μην ξαναεφαρμόσετε τη διόρθωση. Ξαναδιαγνώστε από την αρχή. Ίδιο σύμπτωμα δεν σημαίνει ίδια αιτία.
- Και η ανάκαμψη έχει σειρά: σταματήστε πρώτα το άμεσο έναυσμα, αποδείξτε την κατάσταση πριν από κάθε καταστροφική κίνηση, κρατήστε κάθε βήμα αναστρέψιμο.
Το site σας καταρρέει. Κάποιος βρίσκει ένα εύλογο σφάλμα, το διορθώνει και κηρύσσει νίκη. Το site μένει κάτω, ή επανέρχεται και ξανακαταρρέει στο επόμενο έναυσμα. Η διόρθωση σταμάτησε στο πρώτο σφάλμα, και στις χειρότερες μέρες υπάρχουν τέσσερα ακόμα πίσω του. Αυτή είναι η πειθαρχία που δεν σταματά.
Κανόνας ένα: κατατάξτε κατά συνεισφορά, όχι κατά ένταση
Το πιο δυνατό σύμπτωμα είναι απαίσιο κλειδί ταξινόμησης. Παράδειγμα: ο πυρήνας ουρλιάζει για disk I/O contention, αλλά η μηχανή της αλυσιδωτής κατάρρευσης είναι ένας κολλημένος resolver που κρατάει κάθε worker, και ο μεγαλύτερος συνεχιζόμενος μοχλός είναι μια καταιγίδα session files που καμία πρώτη θεωρία δεν περιλάμβανε. Κατατάξτε τις αιτίες με βάση το πόσο της κατάρρευσης τους ανήκει, και διορθώστε με αυτή τη σειρά.
- Disk I/O contention (το δυνατό σύμπτωμα)
- Το job που όλοι υποψιάζονται
- Ο resolver που κανείς δεν υποψιάζεται
- Ο resolver: η μηχανή
- Η καταιγίδα των sessions: ο μεγαλύτερος μοχλός
- Το job: πραγματικό, όχι ο μοχλός
Κανόνας δύο: διαβάστε πρωτογενείς πηγές, όχι dashboards
Τα dashboards συνοψίζουν. Οι πυρήνες καταθέτουν. Όταν τα επίπεδα διαφωνούν, κερδίζει ο πυρήνας. Το κανονικό πρώτο πέρασμα σε οποιοδήποτε κολλημένο Linux box είναι η ίδια σύντομη λίστα κάθε φορά, και μετά ένας ευρετικός κανόνας που αξίζει να κορνιζωθεί: περιθώριο παρόν και site κάτω σημαίνει σφάλμα εφαρμογής ή εξάρτησης, όχι χωρητικότητας. Ένας δίσκος σε κλάσματα του τοις εκατό χρήσης ενώ οι workers κρέμονται είναι lock contention, όχι I/O, ό,τι κι αν λέει το γράφημα.
# the canonical first pass on a wedged Linux box
dmesg -T | tail -50 # OOM kills, hung tasks, hardware complaints
journalctl --list-boots # did this box reboot when you think it did?
last -x reboot | head # corroborate the reboot story
cat /etc/resolv.conf # who does this box think answers DNS?
iostat -x 5 3 # is the disk actually busy, or just blamed?
cat /proc/<pid>/stack # where exactly is that worker stuck?
strace -p <pid> -c -f # a few seconds: is it even making syscalls?Δέκα λεπτά πρωτογενών πηγών νικούν ένα απόγευμα αρχαιολογίας σε dashboards.
Κανόνας τρία: ξεφλουδίστε ένα σφάλμα τη φορά
Μία αλλαγή, και μετά μέτρηση ξανά στο όριο που απέτυχε, πριν αγγίξετε το επόμενο επίπεδο. Η πειθαρχία μοιάζει αργή και είναι το ταχύτερο διαθέσιμο, γιατί δύο ταυτόχρονες αλλαγές που αλληλεπιδρούν δεν σας λένε τίποτα για καμία από τις δύο. Η επαλήθευση είναι ανά επίπεδο: διορθώστε τον resolver, αποδείξτε την επίλυση ονομάτων στο box· καθαρίστε την καταιγίδα, αποδείξτε τις καταστάσεις των workers· μετά ανεβείτε.
Κανόνας τέσσερα: δυσπιστήστε στη στιγμή του «το διορθώσαμε»
Όταν μια διόρθωση κρατάει και το σύμπτωμα επιστρέφει ώρες αργότερα, το αντανακλαστικό είναι να ξαναεφαρμόσετε τη διόρθωση πιο δυνατά. Μετρήστε ξανά αντί γι' αυτό. Η ερώτηση που πρέπει να κάνετε είναι η απλή: πώς ξέρετε ότι κάνει I/O; Λίγα δευτερόλεπτα strace που πιάνουν μηδέν system calls σημαίνουν ότι οι workers είναι μπλοκαρισμένοι στον πυρήνα πάνω σε ένα lock, δεν κάνουν I/O καθόλου, και έτσι βρίσκεται ο πραγματικός μοχλός αντί να καλυφθεί. Όταν ένα σύμπτωμα επιστρέφει μετά από γνήσια διόρθωση, είναι διαφορετικό σφάλμα που φοράει τα ίδια ρούχα.
Κανόνες πέντε έως επτά: και η ανάκαμψη έχει σειρά
Σταματήστε το άμεσο έναυσμα πριν αγγίξετε την αιτία.
Αν ένα poll του monitoring είναι αυτό που κρασάρει ένα cluster, σταματήστε πρώτα το poll, ανακτήστε θέση, αφαιρέστε την αιτία, και μόνο τότε εφαρμόστε την προγραμματισμένη αλλαγή σε ένα υγιές cluster.
Αποδείξτε την κατάσταση πριν από κάθε καταστροφική κίνηση.
Ένα volume που σημαίνεται ως κατεστραμμένο παίρνει έναν read-only έλεγχο ακεραιότητας πριν κανείς καθαρίσει μια σημαία ή απλώσει το χέρι σε restore. Η ίδια η ανάκαμψη έχει παγίδες. Μάθετέ τες πριν πατήσετε.
Κρατήστε κάθε βήμα αναστρέψιμο.
Backup πριν αγγίξετε. Μετακινήστε στην άκρη, μη διαγράφετε. Reload, όχι restart, υπό φορτίο. Η κίνηση πανικού που δεν αναιρείται δεν είναι ποτέ η κίνηση.
Κανόνας οκτώ: κλείστε την τρύπα για όλους
Κάθε νέο μοτίβο αποτυχίας γίνεται επώνυμος προκαταρκτικός έλεγχος στη διαμόρφωση αναφοράς. Η μέθοδος δεν είναι μόνο ο τρόπος που ξεμπλέκεται ένα κακό πρωινό. Είναι ο τρόπος που το ίδιο πρωινό εμποδίζεται να επαναληφθεί οπουδήποτε αλλού.
Ευθείες απαντήσεις
Γιατί το πρόβλημα του server μου επιστρέφει μετά από κάθε διόρθωση;+
Γιατί το περιστατικό έχει περισσότερες από μία αιτίες και κάθε διόρθωση αντιμετώπισε μία. Όταν μια διόρθωση κρατάει και το σύμπτωμα επιστρέφει, ξαναδιαγνώστε από τις πρώτες αρχές. Ίδιο σύμπτωμα δεν σημαίνει ίδια αιτία.
Πώς βρίσκω την πραγματική ρίζα του υψηλού load στον server;+
Πρωτογενείς πηγές πρώτα: dmesg για OOM και hung tasks, iostat για να ελέγξετε αν ο δίσκος είναι πραγματικά απασχολημένος, ένα process stack ή λίγα δευτερόλεπτα tracing για να δείτε πού κολλάνε οι workers. Κατατάξτε όσα βρείτε κατά συνεισφορά στην κατάρρευση, όχι κατά το πόσο δυνατά φαίνονται.
Τι σημαίνει όταν το load είναι υψηλό αλλά ο δίσκος αδρανής;+
Συνήθως lock contention ή κολλημένη εξάρτηση, όχι χωρητικότητα. Περιθώριο παρόν ενώ το site είναι κάτω δείχνει σφάλμα εφαρμογής ή εξάρτησης, και η προσθήκη πόρων δεν αλλάζει τίποτα.
Να κάνω restart μια υπηρεσία που κρασάρει για να τη διορθώσω;+
Όχι όσο το έναυσμα είναι ακόμα ζωντανό. Αν κάτι τη σκοτώνει επανειλημμένα, ένα restart ξανατρέχει το crash. Σταματήστε πρώτα το άμεσο έναυσμα, μετά αφαιρέστε την αιτία, μετά κάντε restart σε υγιή κατάσταση.
Ποια είναι μια καλή μέθοδος post-mortem περιστατικού;+
Καταγράψτε κάθε σφάλμα που συνεισέφερε, όχι μόνο το πρώτο. Κατατάξτε κατά συνεισφορά. Σημειώστε το σημάδι που εξέθεσε το καθένα. Και μετατρέψτε κάθε τρύπα σε μόνιμο προκαταρκτικό έλεγχο ώστε να μην ευθυγραμμιστεί ξανά. Αν ένα post-mortem έχει ακριβώς μία αιτία για μια ολική κατάρρευση, διαβάστε το δύο φορές.
Δεύτερη γνώμη για ένα επίμονο περιστατικό;
Αν συνεχίζει να επιστρέφει, έχει περισσότερες αιτίες απ' όσες βρήκε η τελευταία αναφορά. Φέρτε μας το ιστορικό των συμπτωμάτων, εμείς φέρνουμε τη μέθοδο.
Μιλήστε με έναν μηχανικόΦτάσατε στο τέλος.
Βάλτε την ανάγνωση σε εφαρμογή
Τι τρέχετε;
Πείτε μας για τον φόρτο εργασίας, την κίνηση και τις απαιτήσεις ανάκαμψης. Ξεκινήστε από το εργαλείο διαμόρφωσης server ή συζητήστε τις λεπτομέρειες με έναν μηχανικό.
Γραμμένο από τους μηχανικούς που χτίζουν και λειτουργούν την υποδομή που περιγράφει.Μιλήστε με έναν μηχανικό