Είναι 2019 και δεν έχουμε ακόμα μια τυπική λύση για τη συγκέντρωση αρχείων καταγραφής στο Kubernetes. Σε αυτό το άρθρο, θα θέλαμε, χρησιμοποιώντας παραδείγματα από την πραγματική πρακτική, να μοιραστούμε τις αναζητήσεις μας, τα προβλήματα που αντιμετωπίσαμε και τις λύσεις τους.
Ωστόσο, πρώτα, θα κάνω μια κράτηση ότι διαφορετικοί πελάτες καταλαβαίνουν πολύ διαφορετικά πράγματα συλλέγοντας αρχεία καταγραφής:
- κάποιος θέλει να δει αρχεία καταγραφής ασφάλειας και ελέγχου.
- κάποιος - κεντρική καταγραφή ολόκληρης της υποδομής.
- και για κάποιους, αρκεί να συλλέγουν μόνο αρχεία καταγραφής εφαρμογών, εξαιρουμένων, για παράδειγμα, των εξισορροπητών.
Ακολουθεί η παρακάτω περικοπή σχετικά με το πώς εφαρμόσαμε διάφορες «λίστες επιθυμιών» και ποιες δυσκολίες αντιμετωπίσαμε.
Θεωρία: σχετικά με τα εργαλεία υλοτομίας
Υπόβαθρο για τα στοιχεία του συστήματος καταγραφής
Η καταγραφή έχει προχωρήσει πολύ, με αποτέλεσμα να έχουν αναπτυχθεί μεθοδολογίες συλλογής και ανάλυσης κορμών, κάτι που χρησιμοποιούμε σήμερα. Πίσω στη δεκαετία του 1950, ο Fortran εισήγαγε ένα ανάλογο τυπικών ροών εισόδου/εξόδου, το οποίο βοήθησε τον προγραμματιστή να διορθώσει το πρόγραμμά του. Αυτά ήταν τα πρώτα αρχεία καταγραφής υπολογιστών που έκαναν τη ζωή πιο εύκολη για τους προγραμματιστές εκείνης της εποχής. Σήμερα βλέπουμε σε αυτά το πρώτο στοιχείο του συστήματος καταγραφής - πηγή ή «παραγωγός» κορμών.
Η επιστήμη των υπολογιστών δεν έμεινε ακίνητη: εμφανίστηκαν δίκτυα υπολογιστών, τα πρώτα συμπλέγματα... Πολύπλοκα συστήματα αποτελούμενα από αρκετούς υπολογιστές άρχισαν να λειτουργούν. Τώρα οι διαχειριστές συστήματος αναγκάζονταν να συλλέγουν αρχεία καταγραφής από πολλά μηχανήματα και σε ειδικές περιπτώσεις μπορούσαν να προσθέσουν μηνύματα πυρήνα λειτουργικού συστήματος σε περίπτωση που χρειαζόταν να διερευνήσουν μια αποτυχία συστήματος. Για να περιγράψει τα κεντρικά συστήματα συλλογής κορμών, δημοσιεύτηκε στις αρχές της δεκαετίας του 2000 , το οποίο τυποποίησε το remote_syslog. Κάπως έτσι εμφανίστηκε ένα άλλο σημαντικό στοιχείο: συλλέκτης κορμών και την αποθήκευσή τους.
Με την αύξηση του όγκου των αρχείων καταγραφής και την ευρεία εισαγωγή τεχνολογιών Ιστού, προέκυψε το ερώτημα ποια αρχεία καταγραφής πρέπει να εμφανίζονται εύκολα στους χρήστες. Τα απλά εργαλεία κονσόλας (awk/sed/grep) έχουν αντικατασταθεί από πιο προηγμένα θεατές καταγραφής - τρίτο συστατικό.
Λόγω της αύξησης του όγκου των κορμών, κάτι άλλο έγινε σαφές: χρειάζονται κούτσουρα, αλλά όχι όλα. Και διαφορετικά κούτσουρα απαιτούν διαφορετικά επίπεδα διατήρησης: μερικά μπορεί να χαθούν σε μια μέρα, ενώ άλλα πρέπει να αποθηκευτούν για 5 χρόνια. Έτσι, ένα στοιχείο για το φιλτράρισμα και τη δρομολόγηση ροών δεδομένων προστέθηκε στο σύστημα καταγραφής - ας το ονομάσουμε φίλτρο.
Η αποθήκευση έχει επίσης κάνει ένα σημαντικό άλμα: από τα κανονικά αρχεία στις σχεσιακές βάσεις δεδομένων και, στη συνέχεια, στην αποθήκευση προσανατολισμένη στα έγγραφα (για παράδειγμα, Elasticsearch). Έτσι η αποθήκευση διαχωρίστηκε από τον συλλέκτη.
Τελικά, η ίδια η έννοια του ημερολογίου έχει επεκταθεί σε ένα είδος αφηρημένης ροής γεγονότων που θέλουμε να διατηρήσουμε για την ιστορία. Ή μάλλον, σε περίπτωση που χρειαστεί να διεξαγάγετε έρευνα ή να συντάξετε μια αναλυτική έκθεση...
Ως αποτέλεσμα, σε σχετικά σύντομο χρονικό διάστημα, η συλλογή αρχείων καταγραφής έχει εξελιχθεί σε ένα σημαντικό υποσύστημα, το οποίο μπορεί δικαίως να ονομαστεί μία από τις υποενότητες στα Μεγάλα Δεδομένα.
Αν κάποτε οι συνηθισμένες εκτυπώσεις ήταν αρκετές για ένα «σύστημα καταγραφής», τώρα η κατάσταση έχει αλλάξει πολύ.
Kubernetes και κούτσουρα
Όταν το Kubernetes ήρθε στην υποδομή, το ήδη υπάρχον πρόβλημα της συλλογής κορμών δεν το παρέκαμψε. Κατά κάποιο τρόπο, έγινε ακόμη πιο οδυνηρό: η διαχείριση της πλατφόρμας υποδομής δεν ήταν μόνο απλοποιημένη, αλλά και περίπλοκη ταυτόχρονα. Πολλές παλιές υπηρεσίες έχουν αρχίσει να μεταναστεύουν σε μικροϋπηρεσίες. Στο πλαίσιο των αρχείων καταγραφής, αυτό αντικατοπτρίζεται στον αυξανόμενο αριθμό των πηγών καταγραφής, στον ειδικό κύκλο ζωής τους και στην ανάγκη παρακολούθησης των σχέσεων όλων των στοιχείων του συστήματος μέσω αρχείων καταγραφής...
Κοιτάζοντας το μέλλον, μπορώ να δηλώσω ότι τώρα, δυστυχώς, δεν υπάρχει τυποποιημένη επιλογή καταγραφής για το Kubernetes που να συγκρίνεται ευνοϊκά με όλες τις άλλες. Τα πιο δημοφιλή προγράμματα στην κοινότητα είναι τα εξής:
- κάποιος ξετυλίγει τη στοίβα ΕΦΚ (Elasticsearch, Fluentd, Kibana);
- κάποιος δοκιμάζει το πρόσφατα κυκλοφόρησε ή χρήσεις ;
- μας (και ίσως όχι μόνο εμείς;...) Είμαι σε μεγάλο βαθμό ικανοποιημένος με τη δική μου εξέλιξη - ...
Κατά κανόνα, χρησιμοποιούμε τα ακόλουθα πακέτα σε συμπλέγματα K8s (για αυτο-φιλοξενούμενες λύσεις):
- ;
- .
Ωστόσο, δεν θα σταθώ σε οδηγίες για την εγκατάσταση και τη διαμόρφωσή τους. Αντίθετα, θα επικεντρωθώ στις ελλείψεις τους και σε πιο σφαιρικά συμπεράσματα για την κατάσταση με τα κούτσουρα γενικότερα.
Εξάσκηση με τα κούτσουρα στα K8s
«Καθημερινά κούτσουρα», πόσοι από εσάς είστε εκεί;..
Η κεντρική συλλογή κορμών από μια αρκετά μεγάλη υποδομή απαιτεί σημαντικούς πόρους, οι οποίοι θα δαπανηθούν για τη συλλογή, την αποθήκευση και την επεξεργασία των κορμών. Κατά τη λειτουργία διαφόρων έργων, αντιμετωπίσαμε διάφορες απαιτήσεις και λειτουργικά προβλήματα που προκύπτουν από αυτά.
Ας δοκιμάσουμε το ClickHouse
Ας δούμε έναν κεντρικό χώρο αποθήκευσης σε ένα έργο με μια εφαρμογή που δημιουργεί αρχεία καταγραφής αρκετά ενεργά: περισσότερες από 5000 γραμμές ανά δευτερόλεπτο. Ας αρχίσουμε να δουλεύουμε με τα αρχεία καταγραφής του, προσθέτοντάς τα στο ClickHouse.
Μόλις απαιτείται μέγιστος πραγματικός χρόνος, ο διακομιστής 4 πυρήνων με ClickHouse θα είναι ήδη υπερφορτωμένος στο υποσύστημα του δίσκου:
Αυτός ο τύπος φόρτωσης οφείλεται στο γεγονός ότι προσπαθούμε να γράψουμε στο ClickHouse όσο το δυνατόν γρηγορότερα. Και η βάση δεδομένων αντιδρά σε αυτό με αυξημένο φορτίο δίσκου, το οποίο μπορεί να προκαλέσει τα ακόλουθα σφάλματα:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Γεγονός είναι ότι στο ClickHouse (περιέχουν δεδομένα καταγραφής) έχουν τις δικές τους δυσκολίες κατά τις λειτουργίες εγγραφής. Τα δεδομένα που εισάγονται σε αυτά δημιουργούν ένα προσωρινό διαμέρισμα, το οποίο στη συνέχεια συγχωνεύεται με τον κύριο πίνακα. Ως αποτέλεσμα, η εγγραφή αποδεικνύεται πολύ απαιτητική στο δίσκο και υπόκειται επίσης στον περιορισμό που λάβαμε την παραπάνω ειδοποίηση: δεν μπορούν να συγχωνευτούν περισσότερες από 1 υποδιαιρέσεις σε 300 δευτερόλεπτο (στην πραγματικότητα, πρόκειται για 300 ένθετα ανά δευτερόλεπτο).
Για να αποφύγετε αυτή τη συμπεριφορά, σε όσο το δυνατόν μεγαλύτερα κομμάτια και όχι περισσότερο από 1 φορά κάθε 2 δευτερόλεπτα. Ωστόσο, η γραφή σε μεγάλες εκρήξεις υποδηλώνει ότι πρέπει να γράφουμε λιγότερο συχνά στο ClickHouse. Αυτό, με τη σειρά του, μπορεί να οδηγήσει σε υπερχείλιση buffer και απώλεια αρχείων καταγραφής. Η λύση είναι να αυξηθεί το buffer Fluentd, αλλά στη συνέχεια θα αυξηθεί και η κατανάλωση μνήμης.
Σημείωση: Μια άλλη προβληματική πτυχή της λύσης μας με το ClickHouse σχετίζεται με το γεγονός ότι η κατάτμηση στην περίπτωσή μας (loghouse) υλοποιείται μέσω εξωτερικών πινάκων που συνδέονται . Αυτό οδηγεί στο γεγονός ότι κατά τη δειγματοληψία μεγάλων χρονικών διαστημάτων, απαιτείται υπερβολική μνήμη RAM, καθώς το metable επαναλαμβάνεται σε όλα τα διαμερίσματα - ακόμη και εκείνα που προφανώς δεν περιέχουν τα απαραίτητα δεδομένα. Ωστόσο, τώρα αυτή η προσέγγιση μπορεί να κηρυχθεί με ασφάλεια παρωχημένη για τις τρέχουσες εκδόσεις του ClickHouse (γ ).
Ως αποτέλεσμα, γίνεται σαφές ότι δεν έχει κάθε έργο αρκετούς πόρους για τη συλλογή αρχείων καταγραφής σε πραγματικό χρόνο στο ClickHouse (ακριβέστερα, η διανομή τους δεν θα είναι κατάλληλη). Επιπλέον, θα χρειαστεί να χρησιμοποιήσετε συσσωρευτή, στο οποίο θα επανέλθουμε αργότερα. Η περίπτωση που περιγράφεται παραπάνω είναι πραγματική. Και τότε δεν μπορούσαμε να προσφέρουμε μια αξιόπιστη και σταθερή λύση που θα ταίριαζε στον πελάτη και θα μας επέτρεπε να συλλέγουμε κορμούς με ελάχιστη καθυστέρηση...
Τι γίνεται με το Elasticsearch;
Το Elasticsearch είναι γνωστό ότι χειρίζεται μεγάλο φόρτο εργασίας. Ας το δοκιμάσουμε στο ίδιο έργο. Τώρα το φορτίο μοιάζει με αυτό:
Το Elasticsearch μπόρεσε να αφομοιώσει τη ροή δεδομένων, ωστόσο, η εγγραφή τέτοιων τόμων σε αυτήν χρησιμοποιεί σε μεγάλο βαθμό τη CPU. Αυτό αποφασίζεται με την οργάνωση ενός cluster. Τεχνικά, αυτό δεν είναι πρόβλημα, αλλά αποδεικνύεται ότι μόνο για να λειτουργήσουμε το σύστημα συλλογής κορμών χρησιμοποιούμε ήδη περίπου 8 πυρήνες και έχουμε ένα πρόσθετο εξάρτημα υψηλής φόρτωσης στο σύστημα...
Κατώτατη γραμμή: αυτή η επιλογή μπορεί να δικαιολογηθεί, αλλά μόνο εάν το έργο είναι μεγάλο και η διαχείρισή του είναι έτοιμη να δαπανήσει σημαντικούς πόρους σε ένα κεντρικό σύστημα καταγραφής.
Τότε προκύπτει ένα φυσικό ερώτημα:
Τι κούτσουρα χρειάζονται πραγματικά;
Ας προσπαθήσουμε να αλλάξουμε την ίδια την προσέγγιση: τα αρχεία καταγραφής πρέπει ταυτόχρονα να είναι ενημερωτικά και όχι να καλύπτουν κάθε μία γεγονός στο σύστημα.
Ας πούμε ότι έχουμε ένα επιτυχημένο ηλεκτρονικό κατάστημα. Ποια αρχεία καταγραφής είναι σημαντικά; Η συλλογή όσο το δυνατόν περισσότερων πληροφοριών, για παράδειγμα, από μια πύλη πληρωμής, είναι μια εξαιρετική ιδέα. Ωστόσο, δεν είναι όλα τα αρχεία καταγραφής από την υπηρεσία κοπής εικόνων στον κατάλογο προϊόντων: αρκούν μόνο τα σφάλματα και η προηγμένη παρακολούθηση (για παράδειγμα, το ποσοστό των 500 σφαλμάτων που δημιουργεί αυτό το στοιχείο).
Καταλήξαμε λοιπόν στο συμπέρασμα ότι Η κεντρική καταγραφή δεν δικαιολογείται πάντα. Πολύ συχνά ο πελάτης θέλει να συγκεντρώσει όλα τα αρχεία καταγραφής σε ένα μέρος, αν και στην πραγματικότητα, από ολόκληρο το αρχείο καταγραφής, απαιτείται μόνο το 5% των μηνυμάτων που είναι κρίσιμα για την επιχείρηση υπό όρους:
- Μερικές φορές αρκεί να διαμορφώσετε, ας πούμε, μόνο το μέγεθος του αρχείου καταγραφής κοντέινερ και του συλλέκτη σφαλμάτων (για παράδειγμα, Sentry).
- Μια ειδοποίηση σφάλματος και ένα μεγάλο τοπικό αρχείο καταγραφής μπορεί συχνά να είναι αρκετά για τη διερεύνηση περιστατικών.
- Είχαμε έργα που αρκούνταν σε αποκλειστικά λειτουργικές δοκιμές και συστήματα συλλογής σφαλμάτων. Ο προγραμματιστής δεν χρειαζόταν αρχεία καταγραφής ως έχουν - είδαν τα πάντα από ίχνη σφαλμάτων.
Εικονογράφηση από τη ζωή
Μια άλλη ιστορία μπορεί να χρησιμεύσει ως καλό παράδειγμα. Λάβαμε ένα αίτημα από την ομάδα ασφαλείας ενός από τους πελάτες μας που χρησιμοποιούσε ήδη μια εμπορική λύση που είχε αναπτυχθεί πολύ πριν από την εισαγωγή του Kubernetes.
Ήταν απαραίτητο να «κάνουμε φίλους» του κεντρικού συστήματος συλλογής αρχείων καταγραφής με τον εταιρικό αισθητήρα ανίχνευσης προβλημάτων - QRadar. Αυτό το σύστημα μπορεί να λάβει αρχεία καταγραφής μέσω του πρωτοκόλλου syslog και να τα ανακτήσει από το FTP. Ωστόσο, δεν ήταν άμεσα δυνατή η ενσωμάτωσή του με την προσθήκη remote_syslog για fluentd (όπως αποδειχτηκε, ). Τα προβλήματα με τη ρύθμιση του QRadar αποδείχτηκαν στο πλευρό της ομάδας ασφαλείας του πελάτη.
Ως αποτέλεσμα, μέρος των αρχείων καταγραφής κρίσιμων για τις επιχειρήσεις μεταφορτώθηκε στο FTP QRadar και το άλλο μέρος ανακατευθύνθηκε μέσω απομακρυσμένου syslog απευθείας από τους κόμβους. Για αυτό μάλιστα γράψαμε - ίσως βοηθήσει κάποιον να λύσει ένα παρόμοιο πρόβλημα... Χάρη στο σχήμα που προέκυψε, ο ίδιος ο πελάτης έλαβε και ανέλυσε κρίσιμα αρχεία καταγραφής (χρησιμοποιώντας τα αγαπημένα του εργαλεία) και μπορέσαμε να μειώσουμε το κόστος του συστήματος καταγραφής, εξοικονομώντας μόνο τον προηγούμενο μήνα.
Ένα άλλο παράδειγμα είναι αρκετά ενδεικτικό του τι δεν πρέπει να κάνετε. Ένας από τους πελάτες μας για επεξεργασία του καθενός συμβάντα που προέρχονται από τον χρήστη, που έγιναν πολλαπλές γραμμές μη δομημένη παραγωγή πληροφορίες στο ημερολόγιο. Όπως μπορείτε να μαντέψετε, τέτοια αρχεία καταγραφής ήταν εξαιρετικά άβολα τόσο για ανάγνωση όσο και για αποθήκευση.
Κριτήρια για τα κούτσουρα
Τέτοια παραδείγματα οδηγούν στο συμπέρασμα ότι εκτός από την επιλογή ενός συστήματος συλλογής κορμών, πρέπει να το κάνετε σχεδιάστε επίσης τα ίδια τα κούτσουρα! Ποιες είναι οι απαιτήσεις εδώ;
- Τα αρχεία καταγραφής πρέπει να είναι σε μορφή αναγνώσιμη από μηχανή (για παράδειγμα, JSON).
- Τα αρχεία καταγραφής πρέπει να είναι συμπαγή και με δυνατότητα αλλαγής του βαθμού καταγραφής προκειμένου να εντοπιστούν τυχόν προβλήματα. Ταυτόχρονα, σε περιβάλλοντα παραγωγής θα πρέπει να εκτελείτε συστήματα με επίπεδο καταγραφής όπως προειδοποίηση ή Λάθος.
- Τα αρχεία καταγραφής πρέπει να είναι κανονικοποιημένα, δηλαδή, σε ένα αντικείμενο καταγραφής, όλες οι γραμμές πρέπει να έχουν τον ίδιο τύπο πεδίου.
Τα μη δομημένα αρχεία καταγραφής μπορεί να οδηγήσουν σε προβλήματα με τη φόρτωση αρχείων καταγραφής στο χώρο αποθήκευσης και την πλήρη διακοπή της επεξεργασίας τους. Ενδεικτικά, εδώ είναι ένα παράδειγμα με το σφάλμα 400, το οποίο σίγουρα έχουν συναντήσει πολλοί σε fluentd logs:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Το σφάλμα σημαίνει ότι στέλνετε ένα πεδίο του οποίου ο τύπος είναι ασταθής στο ευρετήριο με μια έτοιμη αντιστοίχιση. Το απλούστερο παράδειγμα είναι ένα πεδίο στο αρχείο καταγραφής nginx με μια μεταβλητή $upstream_status. Μπορεί να περιέχει είτε έναν αριθμό είτε μια συμβολοσειρά. Για παράδειγμα:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
Τα αρχεία καταγραφής δείχνουν ότι ο διακομιστής 10.100.0.10 απάντησε με σφάλμα 404 και το αίτημα στάλθηκε σε άλλο χώρο αποθήκευσης περιεχομένου. Ως αποτέλεσμα, η τιμή στα αρχεία καταγραφής έγινε ως εξής:
"upstream_response_time": "0.001, 0.007"
Αυτή η κατάσταση είναι τόσο συνηθισμένη που αξίζει ακόμη και μια ξεχωριστή .
Τι γίνεται με την αξιοπιστία;
Υπάρχουν φορές που όλα τα αρχεία καταγραφής χωρίς εξαίρεση είναι ζωτικής σημασίας. Και με αυτό, τα τυπικά σχήματα συλλογής αρχείων καταγραφής για τα K8 που προτείνονται/συζητήθηκαν παραπάνω έχουν προβλήματα.
Για παράδειγμα, το fluentd δεν μπορεί να συλλέξει κορμούς από κοντέινερ μικρής διάρκειας. Σε ένα από τα έργα μας, το κοντέινερ μετεγκατάστασης βάσης δεδομένων διήρκεσε λιγότερο από 4 δευτερόλεπτα και στη συνέχεια διαγράφηκε - σύμφωνα με τον αντίστοιχο σχολιασμό:
"helm.sh/hook-delete-policy": hook-succeeded
Εξαιτίας αυτού, το αρχείο καταγραφής εκτέλεσης μετεγκατάστασης δεν συμπεριλήφθηκε στην αποθήκευση. Η πολιτική μπορεί να βοηθήσει σε αυτή την περίπτωση. before-hook-creation.
Ένα άλλο παράδειγμα είναι η περιστροφή καταγραφής Docker. Ας πούμε ότι υπάρχει μια εφαρμογή που γράφει ενεργά στα αρχεία καταγραφής. Υπό κανονικές συνθήκες, καταφέρνουμε να επεξεργαστούμε όλα τα αρχεία καταγραφής, αλλά μόλις εμφανιστεί ένα πρόβλημα - για παράδειγμα, όπως περιγράφεται παραπάνω με λανθασμένη μορφή - η επεξεργασία σταματά και ο Docker περιστρέφει το αρχείο. Το αποτέλεσμα είναι ότι τα αρχεία καταγραφής κρίσιμων για τις επιχειρήσεις μπορεί να χαθούν.
Γι 'αυτό είναι σημαντικό να διαχωρίσετε τις ροές καταγραφής, ενσωματώνοντας την αποστολή των πιο πολύτιμων απευθείας στην εφαρμογή για να διασφαλιστεί η ασφάλειά τους. Επιπλέον, δεν θα ήταν περιττό να δημιουργηθούν μερικά «συσσωρευτής» κορμών, το οποίο μπορεί να επιβιώσει από τη σύντομη μη διαθεσιμότητα αποθήκευσης κατά την αποθήκευση κρίσιμων μηνυμάτων.
Τέλος, δεν πρέπει να το ξεχνάμε Είναι σημαντικό να παρακολουθείτε σωστά οποιοδήποτε υποσύστημα. Διαφορετικά, είναι εύκολο να βρεθείτε σε μια κατάσταση στην οποία το fluentd βρίσκεται σε κατάσταση CrashLoopBackOff και δεν στέλνει τίποτα, και αυτό υπόσχεται την απώλεια σημαντικών πληροφοριών.
Ευρήματα
Σε αυτό το άρθρο, δεν εξετάζουμε λύσεις SaaS όπως το Datadog. Πολλά από τα προβλήματα που περιγράφονται εδώ έχουν ήδη λυθεί με τον ένα ή τον άλλο τρόπο από εμπορικές εταιρείες που ειδικεύονται στη συλλογή κορμών, αλλά δεν μπορούν όλοι να χρησιμοποιήσουν το SaaS για διάφορους λόγους (τα κυριότερα είναι το κόστος και η συμμόρφωση με το 152-FZ).
Η κεντρική συλλογή αρχείων καταγραφής αρχικά μοιάζει με απλή εργασία, αλλά δεν είναι καθόλου. Είναι σημαντικό να θυμάστε ότι:
- Μόνο κρίσιμα στοιχεία πρέπει να καταγράφονται λεπτομερώς, ενώ η παρακολούθηση και η συλλογή σφαλμάτων μπορούν να διαμορφωθούν για άλλα συστήματα.
- Τα κούτσουρα στην παραγωγή πρέπει να διατηρούνται ελάχιστα, ώστε να μην προστίθεται περιττό φορτίο.
- Τα αρχεία καταγραφής πρέπει να είναι αναγνώσιμα από μηχανή, κανονικοποιημένα και αυστηρής μορφής.
- Τα πραγματικά κρίσιμα αρχεία καταγραφής θα πρέπει να αποστέλλονται σε ξεχωριστή ροή, η οποία θα πρέπει να διαχωρίζεται από τα κύρια.
- Αξίζει να σκεφτείτε έναν συσσωρευτή κορμών, ο οποίος μπορεί να σας γλιτώσει από εκρήξεις υψηλού φορτίου και να κάνει το φορτίο στο χώρο αποθήκευσης πιο ομοιόμορφο.
Αυτοί οι απλοί κανόνες, εάν εφαρμοστούν παντού, θα επέτρεπαν στα κυκλώματα που περιγράφηκαν παραπάνω να λειτουργήσουν - παρόλο που τους λείπουν σημαντικά εξαρτήματα (η μπαταρία). Εάν δεν τηρείτε τέτοιες αρχές, η εργασία θα οδηγήσει εύκολα εσάς και την υποδομή σε ένα άλλο εξαιρετικά φορτωμένο (και ταυτόχρονα αναποτελεσματικό) στοιχείο του συστήματος.
PS
Διαβάστε επίσης στο blog μας:
- «"?
- «"?
- «».
Πηγή: www.habr.com