Τα αρχεία καταγραφής είναι ένα σημαντικό μέρος του συστήματος, επιτρέποντάς σας να κατανοήσετε ότι λειτουργεί (ή δεν λειτουργεί) όπως αναμένεται. Υπό τις συνθήκες της αρχιτεκτονικής μικροϋπηρεσιών, η εργασία με κορμούς γίνεται ξεχωριστός κλάδος της Ειδικής Ολυμπιάδας. Υπάρχουν πολλά ζητήματα που πρέπει να αντιμετωπιστούν:
- πώς να γράψετε αρχεία καταγραφής από την εφαρμογή.
- πού να γράψω αρχεία καταγραφής?
- πώς να παραδίδετε αρχεία καταγραφής για αποθήκευση και επεξεργασία.
- πώς να επεξεργάζεστε και να αποθηκεύετε αρχεία καταγραφής.
Η χρήση επί του παρόντος δημοφιλών τεχνολογιών μεταφοράς εμπορευματοκιβωτίων προσθέτει άμμο πάνω από τη γκανιότα στον τομέα των επιλογών επίλυσης προβλημάτων.
Ακριβώς αυτό είναι η μεταγραφή της αναφοράς του Yuri Bushmelev "Χάρτης μιας τσουγκράνας στον τομέα της συλλογής και παράδοσης κορμών"
Ποιος νοιάζεται, παρακαλώ κάτω από τη γάτα.
Το όνομά μου είναι Yuri Bushmelev. Δουλεύω για τον Λαζάδα. Σήμερα θα μιλήσω για το πώς φτιάξαμε τα κούτσουρα μας, πώς τα μαζέψαμε και τι γράφουμε εκεί.
Από πού είμαστε; Ποιοι είμαστε? Η Lazada είναι ο #1 διαδικτυακός λιανοπωλητής σε έξι χώρες της Νοτιοανατολικής Ασίας. Όλες αυτές οι χώρες κατανέμονται μεταξύ των κέντρων δεδομένων. Τώρα υπάρχουν συνολικά 4 κέντρα δεδομένων. Γιατί είναι αυτό σημαντικό; Διότι κάποιες αποφάσεις οφείλονταν στο γεγονός ότι υπάρχει πολύ αδύναμος δεσμός μεταξύ των κέντρων. Έχουμε μια αρχιτεκτονική microservice. Με έκπληξη διαπίστωσα ότι έχουμε ήδη 80 μικροϋπηρεσίες. Όταν ξεκίνησα την εργασία με αρχεία καταγραφής, υπήρχαν μόνο 20. Επιπλέον, υπάρχει μια αρκετά μεγάλη κληρονομιά της PHP, την οποία πρέπει επίσης να ζήσω και να αντέξω. Όλα αυτά δημιουργούν για εμάς αυτή τη στιγμή περισσότερα από 6 εκατομμύρια μηνύματα ανά λεπτό για το σύστημα συνολικά. Περαιτέρω θα δείξω πώς προσπαθούμε να ζήσουμε με αυτό, και γιατί συμβαίνει αυτό.
Πρέπει να ζήσεις με αυτά τα 6 εκατομμύρια μηνύματα με κάποιο τρόπο. Τι να τους κάνουμε; Απαιτούνται 6 εκατομμύρια μηνύματα:
- αποστολή από την εφαρμογή
- αποδοχή για παράδοση
- παράδοση για ανάλυση και αποθήκευση.
- αναλύει
- αποθηκεύστε με κάποιο τρόπο.
Όταν υπήρχαν τρία εκατομμύρια μηνύματα, είχα περίπου την ίδια εμφάνιση. Γιατί ξεκινήσαμε με καμιά δεκάρα. Είναι σαφές ότι τα αρχεία καταγραφής εφαρμογών είναι γραμμένα εκεί. Για παράδειγμα, δεν μπόρεσε να συνδεθεί στη βάση δεδομένων, μπορούσε να συνδεθεί στη βάση δεδομένων, αλλά δεν μπορούσε να διαβάσει κάτι. Αλλά εκτός από αυτό, κάθε μικρουπηρεσία μας γράφει επίσης ένα αρχείο καταγραφής πρόσβασης. Κάθε αίτημα που φθάνει στη μικρουπηρεσία εμπίπτει στο αρχείο καταγραφής. Γιατί το κάνουμε αυτό; Οι προγραμματιστές θέλουν να μπορούν να ανιχνεύουν. Κάθε αρχείο καταγραφής πρόσβασης περιέχει το πεδίο traceid, σύμφωνα με το οποίο μια ειδική διεπαφή ξετυλίγει ολόκληρη την αλυσίδα και εμφανίζει όμορφα το ίχνος. Το ίχνος δείχνει πώς πήγε το αίτημα και αυτό βοηθά τους προγραμματιστές μας να αντιμετωπίσουν πιο γρήγορα τυχόν άγνωστα σκουπίδια.
Πώς να ζήσεις με αυτό; Τώρα θα περιγράψω εν συντομία το πεδίο των επιλογών - πώς επιλύεται γενικά αυτό το πρόβλημα. Πώς να λύσετε το πρόβλημα της συλλογής, μεταφοράς και αποθήκευσης κορμών.
Πώς να γράψετε από την εφαρμογή; Είναι σαφές ότι υπάρχουν διαφορετικοί τρόποι. Συγκεκριμένα, υπάρχει η βέλτιστη πρακτική, όπως μας λένε οι μοντέρνοι σύντροφοι. Υπάρχουν δύο είδη παλιού σχολείου, όπως έλεγαν οι παππούδες. Υπάρχουν και άλλοι τρόποι.
Με τη συλλογή των κορμών, η κατάσταση είναι περίπου η ίδια. Δεν υπάρχουν τόσες πολλές επιλογές για την επίλυση αυτού του συγκεκριμένου τμήματος. Υπάρχουν περισσότερα από αυτά, αλλά όχι τόσο πολλά ακόμα.
Αλλά με την παράδοση και την επακόλουθη ανάλυση, ο αριθμός των παραλλαγών αρχίζει να εκρήγνυται. Δεν θα περιγράψω κάθε επιλογή τώρα. Νομίζω ότι οι κύριες επιλογές είναι γνωστές σε όλους όσους ενδιαφέρθηκαν για το θέμα.
Θα σας δείξω πώς τα καταφέραμε στο Lazada και πώς ξεκίνησαν όλα.
Πριν από ένα χρόνο, ήρθα στο Lazada και με έστειλαν στο έργο log. Κάπως έτσι ήταν εκεί. Το αρχείο καταγραφής από την εφαρμογή γράφτηκε στα stdout και stderr. Όλα έγιναν με μοντέρνο τρόπο. Στη συνέχεια, όμως, οι προγραμματιστές το έριξαν έξω από τις τυπικές ροές και στη συνέχεια οι ειδικοί της υποδομής θα το καταλάβουν με κάποιο τρόπο. Μεταξύ ειδικών υποδομών και προγραμματιστών, υπάρχουν επίσης κυκλοφορητές που είπαν: "εεε... καλά, ας τα τυλίξουμε σε ένα αρχείο με ένα κέλυφος, και αυτό είναι". Και επειδή όλα αυτά είναι σε ένα δοχείο, το τύλιξαν ακριβώς στο ίδιο το δοχείο, χαρτογράφησαν τον κατάλογο μέσα και το έβαλαν εκεί. Νομίζω ότι είναι αρκετά προφανές σε όλους τι συνέβη.
Ας δούμε λίγο παρακάτω. Πώς παραδώσαμε αυτά τα αρχεία καταγραφής. Κάποιος επέλεξε το td-agent, το οποίο είναι στην πραγματικότητα άπταιστα αλλά όχι αρκετά άπταιστα. Εξακολουθώ να μην καταλαβαίνω τη σχέση αυτών των δύο έργων, αλλά φαίνεται να είναι περίπου το ίδιο πράγμα. Και αυτό το άπταιστα, γραμμένο σε Ruby, διάβασε αρχεία καταγραφής, τα ανέλυσε σε JSON χρησιμοποιώντας μερικές κανονικές εκφράσεις. Μετά τους έστειλαν στον Κάφκα. Επιπλέον, στο Kafka, είχαμε 4 ξεχωριστά θέματα για κάθε API. Γιατί 4; Επειδή υπάρχει live, υπάρχει σταδιοποίηση, και επειδή υπάρχει stdout και stderr. Οι προγραμματιστές τα παράγουν και οι εργαζόμενοι στις υποδομές πρέπει να τα δημιουργήσουν στον Κάφκα. Επιπλέον, ο Κάφκα ελεγχόταν από άλλο τμήμα. Επομένως, ήταν απαραίτητο να δημιουργηθεί ένα εισιτήριο ώστε να δημιουργήσουν 4 θέματα εκεί για κάθε api. Όλοι το ξέχασαν. Γενικά, ήταν σκουπίδια και σκουπίδια.
Τι κάναμε μετά με αυτό; Το στείλαμε στον κάφκα. Πιο πέρα από τον Κάφκα, τα μισά κούτσουρα πέταξαν στο Logstash. Τα άλλα μισά κούτσουρα μοιράστηκαν. Κάποιοι πέταξαν σε ένα Graylog, κάποιοι σε άλλο Graylog. Ως αποτέλεσμα, όλα αυτά πέταξαν σε ένα σύμπλεγμα Elasticsearch. Δηλαδή όλο αυτό το χάλι έπεσε στο τέλος εκεί. Δεν χρειάζεται να το κάνετε αυτό!
Έτσι φαίνεται όταν το δει κανείς από ψηλά. Δεν χρειάζεται να το κάνετε αυτό! Εδώ, οι προβληματικές περιοχές επισημαίνονται αμέσως με αριθμούς. Στην πραγματικότητα υπάρχουν περισσότερα από αυτά, αλλά 6 είναι πραγματικά προβληματικά, με τα οποία κάτι πρέπει να γίνει. Θα τα πω ξεχωριστά τώρα.
Εδώ (1,2,3) γράφουμε αρχεία και, κατά συνέπεια, υπάρχουν τρεις τσουγκράνες εδώ ταυτόχρονα.
Το πρώτο (1) είναι ότι πρέπει να τα γράψουμε κάπου. Δεν είναι πάντα επιθυμητό να δίνετε σε ένα API τη δυνατότητα να γράφει απευθείας σε ένα αρχείο. Είναι επιθυμητό το API να είναι απομονωμένο σε ένα κοντέινερ, και ακόμη καλύτερα, να είναι μόνο για ανάγνωση. Είμαι διαχειριστής συστήματος, επομένως έχω μια ελαφρώς εναλλακτική άποψη για αυτά τα πράγματα.
Το δεύτερο σημείο (2,3) είναι ότι έχουμε πολλά αιτήματα που έρχονται στο API. Το API εγγράφει πολλά δεδομένα σε ένα αρχείο. Τα αρχεία μεγαλώνουν. Πρέπει να τα περιστρέψουμε. Γιατί διαφορετικά δεν θα μπορείτε να αποθηκεύσετε κανένα δίσκο εκεί. Η περιστροφή τους είναι κακή επειδή ανακατευθύνονται μέσω του κελύφους σε έναν κατάλογο. Δεν υπάρχει περίπτωση να το περιστρέψουμε. Δεν μπορείτε να πείτε στην εφαρμογή να ανοίξει ξανά τις λαβές. Επειδή οι προγραμματιστές θα σας κοιτάξουν σαν ανόητο: «Τι περιγραφείς; Γενικά γράφουμε στο stdout. Οι τύποι της υποδομής έκαναν το copytruncate σε logrotate, το οποίο απλώς κάνει ένα αντίγραφο του αρχείου και κάνει trunk το πρωτότυπο. Κατά συνέπεια, μεταξύ αυτών των διαδικασιών αντιγραφής, συνήθως τελειώνει ο χώρος στο δίσκο.
(4) Είχαμε διαφορετικές μορφές σε διαφορετικά API. Ήταν ελαφρώς διαφορετικά, αλλά το regexp έπρεπε να γραφτεί διαφορετικά. Δεδομένου ότι όλα τα διαχειριζόταν η Puppet, υπήρχε ένα μεγάλο μάτσο τάξεων με τις δικές τους κατσαρίδες. Επιπλέον, ο td-agent τις περισσότερες φορές μπορούσε να τρώει τη μνήμη, να είναι ηλίθιος, να προσποιείται ότι δούλευε και να μην κάνει τίποτα. Εξωτερικά, ήταν αδύνατο να καταλάβουμε ότι δεν έκανε τίποτα. Στην καλύτερη περίπτωση, θα πέσει, και κάποιος θα τον σηκώσει αργότερα. Πιο συγκεκριμένα, θα πετάξει ένας συναγερμός και κάποιος θα πάει να τον σηκώσει με τα χέρια του.
(6) Και τα περισσότερα σκουπίδια και απορρίμματα - ήταν το elasticsearch. Γιατί ήταν παλιά έκδοση. Γιατί δεν είχαμε αφοσιωμένους δασκάλους εκείνη την εποχή. Είχαμε ετερογενή αρχεία καταγραφής των οποίων τα πεδία μπορούσαν να επικαλύπτονται. Διαφορετικά αρχεία καταγραφής διαφορετικών εφαρμογών θα μπορούσαν να γραφτούν με τα ίδια ονόματα πεδίων, αλλά ταυτόχρονα θα μπορούσαν να υπάρχουν διαφορετικά δεδομένα μέσα. Δηλαδή, ένα αρχείο καταγραφής συνοδεύεται από έναν ακέραιο σε ένα πεδίο, για παράδειγμα, επίπεδο. Ένα άλλο αρχείο καταγραφής συνοδεύεται από μια συμβολοσειρά στο πεδίο επιπέδου. Ελλείψει στατικής χαρτογράφησης, αποδεικνύεται ένα τόσο υπέροχο πράγμα. Αν μετά την περιστροφή του δείκτη έφτασε πρώτα ένα μήνυμα με συμβολοσειρά στο elasticsearch, τότε ζούμε κανονικά. Και αν το πρώτο έφτασε με Integer, τότε όλα τα επόμενα μηνύματα που έφτασαν με το String απλώς απορρίπτονται. Επειδή ο τύπος πεδίου δεν ταιριάζει.
Αρχίσαμε να κάνουμε αυτές τις ερωτήσεις. Αποφασίσαμε να μην αναζητήσουμε τους ένοχους.
Όμως κάτι πρέπει να γίνει! Το προφανές είναι ότι πρέπει να καθιερώσουμε πρότυπα. Είχαμε ήδη κάποια πρότυπα. Κάποια τα φέραμε λίγο αργότερα. Ευτυχώς, μια ενιαία μορφή αρχείου καταγραφής για όλα τα API είχε ήδη εγκριθεί εκείνη τη στιγμή. Είναι γραμμένο απευθείας στα πρότυπα αλληλεπίδρασης υπηρεσιών. Αντίστοιχα, όσοι θέλουν να λαμβάνουν αρχεία καταγραφής θα πρέπει να τα γράψουν σε αυτή τη μορφή. Εάν κάποιος δεν γράφει αρχεία καταγραφής σε αυτήν τη μορφή, τότε δεν εγγυόμαστε τίποτα.
Επιπλέον, θα ήθελα να υπάρχει ένα ενιαίο πρότυπο για τις μεθόδους καταγραφής, παράδοσης και συλλογής κορμών. Στην πραγματικότητα, πού να τα γράψετε και πώς να τα παραδώσετε. Η ιδανική κατάσταση είναι όταν τα έργα χρησιμοποιούν την ίδια βιβλιοθήκη. Υπάρχει μια ξεχωριστή βιβλιοθήκη καταγραφής για το Go, υπάρχει μια ξεχωριστή βιβλιοθήκη για την PHP. Όλοι όσοι έχουμε, όλοι πρέπει να τους χρησιμοποιούν. Αυτή τη στιγμή θα έλεγα ότι τα καταφέρνουμε κατά 80 τοις εκατό. Κάποιοι όμως συνεχίζουν να τρώνε κάκτους.
Και εκεί (στη διαφάνεια) το "SLA για παράδοση αρχείων καταγραφής" μόλις αρχίζει να εμφανίζεται. Δεν είναι ακόμα εκεί, αλλά το δουλεύουμε. Διότι είναι πολύ βολικό όταν το infra λέει ότι αν γράψετε σε τάδε μορφή σε τάδε μέρος και όχι περισσότερα από N μηνύματα ανά δευτερόλεπτο, τότε πιθανότατα θα το παραδώσουμε εκεί. Διώχνει πολλούς πονοκεφάλους. Αν υπάρχει SLA, τότε είναι απλά υπέροχο!
Πώς ξεκινήσαμε να λύνουμε το πρόβλημα; Η κύρια γκανιότα ήταν με το td-agent. Δεν ήταν σαφές πού πήγαιναν τα κούτσουρα μας. Παραδίδονται; Πάνε; Πού είναι τελικά; Ως εκ τούτου, αποφασίστηκε να αντικατασταθεί το td-agent με το πρώτο στοιχείο. Επιλογές για το με τι να το αντικαταστήσετε, περιέγραψα εν συντομία εδώ.
Fluentd. Πρώτον, τον συνάντησα σε μια προηγούμενη δουλειά, και έπεφτε περιοδικά εκεί. Δεύτερον, αυτό είναι το ίδιο, μόνο στο προφίλ.
filebeat. Πώς ήταν καλό για εμάς; Το γεγονός ότι είναι στο Go, και έχουμε μεγάλη εξειδίκευση στο Go. Αντίστοιχα, αν μη τι άλλο, θα μπορούσαμε με κάποιο τρόπο να το προσθέσουμε στον εαυτό μας. Γι' αυτό δεν το πήραμε. Για να μην υπάρχει καν ο πειρασμός να αρχίσετε να το ξαναγράφετε μόνοι σας.
Η προφανής λύση για το sysadmin είναι όλα τα είδη syslog σε αυτήν την ποσότητα (syslog-ng/rsyslog/nxlog).
Ή γράψτε κάτι δικό σας, αλλά το απορρίψαμε, όπως και το filebeat. Εάν γράψετε κάτι, τότε είναι καλύτερο να γράψετε κάτι χρήσιμο για τις επιχειρήσεις. Για να παραδώσετε κορμούς, είναι καλύτερο να πάρετε κάτι έτοιμο.
Επομένως, η επιλογή κατέληξε στην επιλογή μεταξύ syslog-ng και rsyslog. Έσκυψα προς το rsyslog απλώς και μόνο επειδή είχαμε ήδη μαθήματα για το rsyslog στο Puppet και δεν βρήκα προφανή διαφορά μεταξύ τους. Τι είναι το syslog, τι είναι το syslog. Ναι, κάποια τεκμηρίωση είναι χειρότερη, κάποια καλύτερη. Ξέρει αυτόν τον τρόπο και το κάνει διαφορετικά.
Και λίγα για το rsyslog. Πρώτον, είναι ωραίο γιατί έχει πολλές ενότητες. Διαθέτει ένα αναγνώσιμο από τον άνθρωπο RainerScript (σύγχρονη γλώσσα διαμόρφωσης). Ένα φοβερό μπόνους είναι ότι μπορούσαμε να μιμηθούν τη συμπεριφορά του td-agent με τα τυπικά εργαλεία του και τίποτα δεν έχει αλλάξει για τις εφαρμογές. Δηλαδή αλλάζουμε το td-agent σε rsyslog και δεν αγγίζουμε όλα τα άλλα ακόμα. Και αμέσως παίρνουμε μια παράδοση εργασίας. Στη συνέχεια, το mmnormalize είναι το ωραίο πράγμα για το rsyslog. Σας επιτρέπει να αναλύετε αρχεία καταγραφής, αλλά όχι με το Grok και το regexp. Δημιουργεί ένα αφηρημένο συντακτικό δέντρο. Αναλύει τα αρχεία καταγραφής σχεδόν με τον ίδιο τρόπο που ένας μεταγλωττιστής αναλύει τον πηγαίο κώδικα. Αυτό σας επιτρέπει να εργάζεστε πολύ γρήγορα, να τρώτε λίγο CPU και, γενικά, είναι απλά ένα πολύ ωραίο πράγμα. Υπάρχουν ένα σωρό άλλα μπόνους. Δεν θα σταθώ σε αυτά.
Το rsyslog έχει πολύ περισσότερα μειονεκτήματα. Είναι περίπου τα ίδια με τα μπόνους. Τα κύρια προβλήματα είναι ότι πρέπει να μπορείτε να το μαγειρέψετε και πρέπει να επιλέξετε μια έκδοση.
Αποφασίσαμε να γράφουμε αρχεία καταγραφής σε μια υποδοχή unix. Και όχι στο /dev/log, επειδή εκεί έχουμε ένα χάος από αρχεία καταγραφής συστήματος, υπάρχει το journald σε αυτήν τη γραμμή. Ας γράψουμε λοιπόν σε μια προσαρμοσμένη πρίζα. Θα το επισυνάψουμε σε ένα ξεχωριστό σύνολο κανόνων. Ας μην ανακατευτούμε σε τίποτα. Όλα θα είναι διαφανή και κατανοητά. Έτσι κάναμε στην πραγματικότητα. Ο κατάλογος με αυτές τις υποδοχές είναι τυποποιημένος και προωθείται σε όλα τα κοντέινερ. Τα δοχεία μπορούν να δουν την πρίζα που χρειάζονται, να ανοίξουν και να γράψουν σε αυτήν.
Γιατί όχι ένα αρχείο; Γιατί όλοι έχουν διαβάσει , το οποίο προσπάθησε να προωθήσει το αρχείο στο docker και διαπίστωσε ότι μετά την επανεκκίνηση του rsyslog, η περιγραφή του αρχείου αλλάζει και το docker χάνει αυτό το αρχείο. Κρατά κάτι άλλο ανοιχτό, αλλά όχι την ίδια πρίζα που γράφουν. Αποφασίσαμε να παρακάμψουμε αυτό το πρόβλημα και, ταυτόχρονα, να παρακάμψουμε το πρόβλημα αποκλεισμού.
Το Rsyslog κάνει τις ενέργειες που υποδεικνύονται στη διαφάνεια και στέλνει αρχεία καταγραφής είτε στο ρελέ είτε στον Κάφκα. Ο Κάφκα ακολουθεί τον παλιό δρόμο. Rayleigh - Προσπάθησα να χρησιμοποιήσω καθαρό rsyslog για να παραδώσω αρχεία καταγραφής. Χωρίς ουρά μηνυμάτων, χρησιμοποιώντας τυπικά εργαλεία rsyslog. Βασικά, λειτουργεί.
Αλλά υπάρχουν αποχρώσεις σχετικά με το πώς να τα γεμίσετε αργότερα σε αυτό το μέρος (Logstash/Graylog/ES). Αυτό το τμήμα (rsyslog-rsyslog) χρησιμοποιείται μεταξύ κέντρων δεδομένων. Εδώ είναι ένας συμπιεσμένος σύνδεσμος tcp, ο οποίος σας επιτρέπει να εξοικονομήσετε εύρος ζώνης και, κατά συνέπεια, να αυξήσετε κατά κάποιο τρόπο την πιθανότητα να λάβουμε κάποια αρχεία καταγραφής από άλλο κέντρο δεδομένων όταν το κανάλι γεμίσει. Γιατί έχουμε την Ινδονησία, όπου όλα είναι άσχημα. Εκεί βρίσκεται το μόνιμο πρόβλημα.
Σκεφτήκαμε πώς παρακολουθούμε πραγματικά, με ποια πιθανότητα τα αρχεία καταγραφής που καταγράψαμε από την εφαρμογή φτάνουν σε αυτό το τέλος; Αποφασίσαμε να ξεκινήσουμε τις μετρήσεις. Το Rsyslog έχει τη δική του ενότητα συλλογής στατιστικών στοιχείων, η οποία έχει κάποιου είδους μετρητές. Για παράδειγμα, μπορεί να σας δείξει το μέγεθος της ουράς ή πόσα μηνύματα εισήλθαν για μια τέτοια ενέργεια. Μπορείτε ήδη να πάρετε κάτι από αυτά. Επιπλέον, διαθέτει προσαρμοσμένους μετρητές που μπορείτε να διαμορφώσετε και θα σας δείξει, για παράδειγμα, τον αριθμό των μηνυμάτων που έχει καταγράψει κάποιο API. Στη συνέχεια, έγραψα το rsyslog_exporter στην Python, και τα στείλαμε όλα στον Προμηθέα και σχεδιάσαμε. Θέλαμε πολύ τις μετρήσεις του Graylog, αλλά μέχρι στιγμής δεν είχαμε χρόνο να τις ρυθμίσουμε.
Ποια είναι τα προβλήματα; Το πρόβλημα προέκυψε με το γεγονός ότι ανακαλύψαμε (ΞΑΦΝΙΚΑ!) ότι τα Live API μας γράφουν 50 χιλιάδες μηνύματα ανά δευτερόλεπτο. Αυτό είναι μόνο Live API χωρίς σταδιοποίηση. Και η Graylog μας δείχνει μόνο 12 χιλιάδες μηνύματα ανά δευτερόλεπτο. Και προέκυψε ένα εύλογο ερώτημα, πού είναι τα απομεινάρια; Από το οποίο καταλήξαμε στο συμπέρασμα ότι η Graylog απλά δεν μπορεί να αντεπεξέλθει. Κοιτάξαμε και, πράγματι, η Graylog με το Elasticsearch δεν κατέκτησε αυτή τη ροή.
Στη συνέχεια, άλλες ανακαλύψεις που κάναμε στην πορεία.
Οι εγγραφές στην υποδοχή είναι μπλοκαρισμένες. Πώς συνέβη? Όταν χρησιμοποίησα το rsyslog για παράδοση, κάποια στιγμή σπάσαμε το κανάλι μεταξύ των data centers. Η παράδοση ανέβηκε σε ένα μέρος, η παράδοση ανέβηκε σε άλλο μέρος. Όλα αυτά έχουν καταλήξει σε ένα μηχάνημα με API που γράφουν στην υποδοχή rsyslog. Υπήρχε μια ουρά. Στη συνέχεια γέμισε η ουρά εγγραφής στην υποδοχή unix, η οποία από προεπιλογή είναι 128 πακέτα. Και το επόμενο write() στα μπλοκ της εφαρμογής. Όταν κοιτάξαμε τη βιβλιοθήκη που χρησιμοποιούμε στις εφαρμογές Go, γράφτηκε εκεί ότι η εγγραφή στην υποδοχή πραγματοποιείται σε λειτουργία μη αποκλεισμού. Ήμασταν σίγουροι ότι τίποτα δεν είχε μπλοκαριστεί. Γιατί έχουμε διαβάσει που έγραψε για αυτό. Υπάρχει όμως μια στιγμή. Υπήρχε επίσης ένας άπειρος βρόχος γύρω από αυτήν την κλήση, στην οποία γινόταν μια συνεχής προσπάθεια να σπρώξει ένα μήνυμα στην υποδοχή. Δεν τον προσέξαμε. Έπρεπε να ξαναγράψω τη βιβλιοθήκη. Από τότε, έχει αλλάξει αρκετές φορές, αλλά τώρα έχουμε απαλλαγεί από κλειδαριές σε όλα τα υποσυστήματα. Επομένως, μπορείτε να σταματήσετε το rsyslog και τίποτα δεν θα πέσει.
Είναι απαραίτητο να παρακολουθείτε το μέγεθος των ουρών, κάτι που βοηθά να μην πατήσετε αυτή τη γκανιότα. Πρώτον, μπορούμε να παρακολουθούμε πότε αρχίζουμε να χάνουμε μηνύματα. Δεύτερον, μπορούμε να παρακολουθούμε ότι βασικά έχουμε προβλήματα με την παράδοση.
Και μια άλλη δυσάρεστη στιγμή - η ενίσχυση κατά 10 φορές σε μια αρχιτεκτονική microservice είναι πολύ εύκολη. Δεν έχουμε τόσα πολλά εισερχόμενα αιτήματα, αλλά λόγω του γραφήματος κατά μήκος του οποίου εκτελούνται περαιτέρω αυτά τα μηνύματα, λόγω των αρχείων καταγραφής πρόσβασης, στην πραγματικότητα αυξάνουμε το φορτίο στα αρχεία καταγραφής κατά περίπου δέκα φορές. Δυστυχώς, δεν πρόλαβα να υπολογίσω τα ακριβή νούμερα, αλλά οι μικροϋπηρεσίες είναι αυτό που είναι. Αυτό πρέπει να ληφθεί υπόψη. Αποδεικνύεται ότι αυτή τη στιγμή το υποσύστημα συλλογής κορμών είναι το πιο φορτωμένο στο Lazada.
Πώς να λύσετε το πρόβλημα elasticsearch; Εάν πρέπει να λάβετε γρήγορα αρχεία καταγραφής σε ένα μέρος, ώστε να μην τρέχετε σε όλα τα μηχανήματα και να τα συλλέγετε εκεί, χρησιμοποιήστε την αποθήκευση αρχείων. Αυτό είναι εγγυημένο ότι θα λειτουργήσει. Γίνεται από οποιονδήποτε διακομιστή. Απλά πρέπει να κολλήσεις δίσκους εκεί και να βάλεις syslog. Μετά από αυτό, είναι εγγυημένο ότι θα έχετε όλα τα αρχεία καταγραφής σε ένα μέρος. Στη συνέχεια, θα μπορείτε να ρυθμίσετε αργά το elasticsearch, το graylog ή κάτι άλλο. Αλλά θα έχετε ήδη όλα τα αρχεία καταγραφής και, επιπλέον, μπορείτε να τα αποθηκεύσετε, εφόσον υπάρχουν αρκετές συστοιχίες δίσκων.
Την εποχή της αναφοράς μου, το σχέδιο άρχισε να μοιάζει με αυτό. Πρακτικά σταματήσαμε να γράφουμε στο αρχείο. Τώρα, πιθανότατα, θα απενεργοποιήσουμε τα υπολείμματα. Σε τοπικά μηχανήματα που εκτελούν το API, θα σταματήσουμε να γράφουμε σε αρχεία. Πρώτον, υπάρχει αποθήκευση αρχείων, η οποία λειτουργεί πολύ καλά. Δεύτερον, αυτά τα μηχανήματα εξαντλούνται συνεχώς από χώρο, πρέπει να το παρακολουθείτε συνεχώς.
Αυτό το μέρος με το Logstash και το Graylog, εκτινάσσεται πραγματικά στα ύψη. Επομένως, πρέπει να το ξεφορτωθείτε. Πρέπει να διαλέξεις ένα.
Αποφασίσαμε να ρίξουμε το Logstash και το Kibana. Γιατί έχουμε τμήμα ασφαλείας. Ποια είναι η σύνδεση; Η σύνδεση είναι ότι το Kibana χωρίς X-Pack και χωρίς Shield δεν σας επιτρέπει να διαφοροποιήσετε τα δικαιώματα πρόσβασης στα αρχεία καταγραφής. Ως εκ τούτου, πήραν το Graylog. Τα έχει όλα. Δεν μου αρέσει, αλλά λειτουργεί. Αγοράσαμε νέο υλικό, εγκαταστήσαμε ένα νέο Graylog εκεί και μετακινήσαμε όλα τα αρχεία καταγραφής με αυστηρές μορφές σε ένα ξεχωριστό Graylog. Έχουμε λύσει οργανωτικά το πρόβλημα με διαφορετικούς τύπους των ίδιων πεδίων.
Τι ακριβώς περιλαμβάνει το νέο Graylog. Απλώς γράψαμε τα πάντα στο docker. Πήραμε ένα σωρό διακομιστές, παρουσιάσαμε τρεις περιπτώσεις Kafka, 7 διακομιστές Graylog έκδοση 2.3 (επειδή ήθελα την έκδοση 5 του Elasticsearch). Όλα αυτά προέκυψαν από επιδρομές από τον σκληρό δίσκο. Είδαμε ρυθμό ευρετηρίασης έως και 100 χιλιάδες μηνύματα ανά δευτερόλεπτο. Είδαμε τον αριθμό ότι 140 terabytes δεδομένων την εβδομάδα.
Και πάλι τσουγκράνα! Έρχονται δύο εκπτώσεις. Έχουμε ξεπεράσει τις 6 εκατομμύρια δημοσιεύσεις. Εμείς οι Graylog δεν έχουμε χρόνο να μασήσουμε. Κάπως πρέπει να επιβιώσεις ξανά.
Έτσι επιβιώσαμε. Προστέθηκαν μερικοί ακόμη διακομιστές και SSD. Αυτή τη στιγμή ζούμε έτσι. Τώρα μασάμε ήδη 160 χιλιάδες μηνύματα ανά δευτερόλεπτο. Δεν έχουμε φτάσει ακόμα το όριο, οπότε δεν είναι σαφές πόσο μπορούμε ρεαλιστικά να βγάλουμε από αυτό.
Αυτά είναι τα σχέδιά μας για το μέλλον. Από αυτά, πραγματικά, το πιο σημαντικό είναι πιθανώς η υψηλή διαθεσιμότητα. Δεν το έχουμε ακόμα. Πολλά αυτοκίνητα είναι στημένα με τον ίδιο τρόπο, αλλά μέχρι στιγμής όλα περνούν από ένα αυτοκίνητο. Είναι απαραίτητο να αφιερώσετε χρόνο για να δημιουργήσετε ένα failover μεταξύ τους.
Συλλέξτε μετρήσεις από τη Graylog.
Κάντε ένα όριο ρυθμού, ώστε να έχουμε ένα τρελό API που δεν μας σκοτώνει το εύρος ζώνης και οτιδήποτε άλλο.
Και τέλος, υπογράψτε κάποιο είδος SLA με προγραμματιστές για να μπορούμε να εξυπηρετήσουμε τόσο πολύ. Αν γράψεις περισσότερα, τότε συγνώμη.
Και γράψτε τεκμηρίωση.
Εν συντομία, τα αποτελέσματα όλων αυτών που ζήσαμε. Πρώτον, τα πρότυπα. Δεύτερον, το syslog είναι τούρτα. Τρίτον, το rsyslog λειτουργεί ακριβώς όπως είναι γραμμένο στη διαφάνεια. Και πάμε στις ερωτήσεις.
ερωτήσεις.
Ερώτηση: Γιατί αποφάσισαν να μην πάρουν ... (filebeat;)
Απάντηση: Χρειάζεται εγγραφή σε αρχείο. Πραγματικά δεν ήθελα. Όταν το API σας γράφει χιλιάδες μηνύματα ανά δευτερόλεπτο, ακόμα κι αν κάνετε εναλλαγή μία φορά την ώρα, αυτό δεν αποτελεί επιλογή. Μπορείτε να γράψετε στο σωλήνα. Στο οποίο οι προγραμματιστές με ρώτησαν: "Τι θα συμβεί αν πέσει η διαδικασία στην οποία γράφουμε"; Απλώς δεν βρήκα τι να τους απαντήσω και είπα: «Λοιπόν, εντάξει, ας μην το κάνουμε αυτό».
Ερώτηση: Γιατί δεν γράφετε απλώς αρχεία καταγραφής στο HDFS;
ΑπάντησηΑ: Αυτό είναι το επόμενο στάδιο. Το σκεφτήκαμε από την αρχή, αλλά επειδή δεν υπάρχουν πόροι για να το αντιμετωπίσουμε αυτή τη στιγμή, κρέμεται από τη μακροπρόθεσμη λύση μας.
Ερώτηση: Μια μορφή στήλης θα ήταν πιο κατάλληλη.
Απάντηση: Καταλαβαίνω. Είμαστε «υπέρ» και με τα δύο χέρια.
Ερώτηση: Γράφεις στο rsyslog. Τόσο το TCP όσο και το UDP είναι διαθέσιμα εκεί. Αλλά αν UDP, τότε πώς εγγυάστε την παράδοση;
ΑπάντησηΑ: Υπάρχουν δύο σημεία. Πρώτον, λέω αμέσως σε όλους ότι δεν εγγυόμαστε την παράδοση των κορμών. Γιατί όταν έρχονται οι προγραμματιστές και λένε: «Ας αρχίσουμε να γράφουμε εκεί οικονομικά στοιχεία και θα μας τα βάλετε κάπου σε περίπτωση που συμβεί κάτι», τους απαντάμε, «Τέλεια! Ας αρχίσουμε να μπλοκάρουμε την εγγραφή στην πρίζα, και να το κάνουμε στις συναλλαγές, ώστε να μας το βάλετε εγγυημένα στην πρίζα και να βεβαιωθείτε ότι το λάβαμε από την άλλη πλευρά. Και αυτή τη στιγμή όλοι γίνονται αμέσως περιττοί. Και αν όχι, τότε τι ερωτήσεις έχουμε; Εάν δεν θέλετε να εγγυηθείτε την εγγραφή στην πρίζα, τότε γιατί να εγγυηθούμε την παράδοση; Κάνουμε την καλύτερη δυνατή προσπάθεια. Προσπαθούμε πραγματικά να προσφέρουμε όσο το δυνατόν περισσότερα και όσο το δυνατόν καλύτερα, αλλά δεν δίνουμε 100% εγγύηση. Επομένως, δεν χρειάζεται να γράψετε εκεί οικονομικά στοιχεία. Υπάρχουν βάσεις δεδομένων συναλλαγών για αυτό.
Ερώτηση: Όταν το API δημιουργεί κάποιο μήνυμα στο αρχείο καταγραφής και μεταφέρει τον έλεγχο σε microservices, αντιμετωπίσατε το πρόβλημα ότι τα μηνύματα από διαφορετικές μικροϋπηρεσίες φτάνουν με λάθος σειρά; Εξαιτίας αυτού, δημιουργείται σύγχυση.
ΑπάντησηΑ: Είναι φυσιολογικό να έρχονται με διαφορετική σειρά. Πρέπει να είσαι έτοιμος για αυτό. Επειδή οποιαδήποτε παράδοση δικτύου δεν εγγυάται την παραγγελία σας ή πρέπει να δαπανήσετε ειδικούς πόρους για αυτό. Αν πάρουμε αποθηκευτικούς χώρους αρχείων, τότε κάθε API αποθηκεύει αρχεία καταγραφής στο δικό του αρχείο. Αντίθετα, το rsyslog τα αποσυνθέτει σε καταλόγους εκεί. Κάθε API έχει τα δικά του αρχεία καταγραφής εκεί, όπου μπορείτε να πάτε και να δείτε και, στη συνέχεια, μπορείτε να τα συγκρίνετε χρησιμοποιώντας τη χρονική σήμανση σε αυτό το αρχείο καταγραφής. Εάν πάνε να ψάξουν στο Graylog, τότε εκεί θα ταξινομηθούν κατά χρονική σήμανση. Όλα θα πάνε καλά εκεί.
Ερώτηση: Η χρονική σήμανση μπορεί να διαφέρει κατά χιλιοστά του δευτερολέπτου.
Απάντηση: Η χρονική σήμανση δημιουργείται από το ίδιο το API. Αυτό, στην πραγματικότητα, είναι το όλο θέμα. Έχουμε NTP. Το API δημιουργεί μια χρονική σήμανση ήδη στο ίδιο το μήνυμα. Δεν προστίθεται από το rsyslog.
Ερώτηση: Η αλληλεπίδραση μεταξύ των κέντρων δεδομένων δεν είναι πολύ σαφής. Στο πλαίσιο του κέντρου δεδομένων, είναι σαφές πώς συλλέχθηκαν και επεξεργάστηκαν τα αρχεία καταγραφής. Πώς είναι η αλληλεπίδραση μεταξύ των κέντρων δεδομένων; Ή μήπως κάθε κέντρο δεδομένων ζει τη δική του ζωή;
Απάντηση: Σχεδόν. Έχουμε κάθε χώρα που βρίσκεται σε ένα κέντρο δεδομένων. Επί του παρόντος δεν έχουμε εξάπλωση ώστε μια χώρα να τοποθετείται σε διαφορετικά κέντρα δεδομένων. Επομένως, δεν χρειάζεται να τα συνδυάσετε. Μέσα σε κάθε κέντρο υπάρχει ένα Log Relay. Αυτός είναι ένας διακομιστής Rsyslog. Μάλιστα δύο μηχανές διαχείρισης. Τοποθετούνται με τον ίδιο τρόπο. Αλλά προς το παρόν, η κίνηση περνάει από ένα από αυτά. Καταγράφει τα πάντα συγκεντρωτικά. Έχει ουρά δίσκου για παν ενδεχόμενο. Πατάει τα κούτσουρα και τα στέλνει στο κεντρικό κέντρο δεδομένων (Σιγκαπούρη), όπου περαιτέρω είναι ήδη δηλητηριασμένα στο Graylog. Και κάθε κέντρο δεδομένων έχει τη δική του αποθήκευση αρχείων. Σε περίπτωση που χάσουμε τη σύνδεση, έχουμε όλα τα αρχεία καταγραφής εκεί. Θα μείνουν εκεί. Θα αποθηκευτούν εκεί.
Ερώτηση: Παίρνετε κορμούς από εκεί σε μη φυσιολογικές καταστάσεις;
Απάντηση: Μπορείτε να πάτε εκεί (στο χώρο αποθήκευσης αρχείων) και να κοιτάξετε.
Ερώτηση: Πώς παρακολουθείτε ότι δεν χάνετε αρχεία καταγραφής;
Απάντηση: Στην πραγματικότητα τα χάνουμε, και το παρακολουθούμε. Η παρακολούθηση ξεκίνησε πριν από ένα μήνα. Η βιβλιοθήκη που χρησιμοποιούν τα Go API έχει μετρήσεις. Μπορεί να μετρήσει πόσες φορές δεν κατάφερε να γράψει στην πρίζα. Εκεί αυτή τη στιγμή υπάρχει μια δύσκολη ευρετική. Υπάρχει ένα buffer εκεί. Προσπαθεί να γράψει ένα μήνυμα από αυτό στην υποδοχή. Εάν το buffer ξεχειλίσει, αρχίζει να τα ρίχνει. Και μετράει πόσα τα έριξε. Αν αρχίσουν να ξεχειλίζουν οι μετρητές εκεί, θα το μάθουμε. Έρχονται τώρα και στο prometheus, και μπορείτε να δείτε τα γραφήματα στα Grafana. Μπορείτε να ρυθμίσετε ειδοποιήσεις. Αλλά δεν είναι ακόμη σαφές σε ποιον να τα στείλουν.
Ερώτηση: Στο elasticsearch, αποθηκεύετε αρχεία καταγραφής με πλεονασμό. Πόσα αντίγραφα έχετε;
Απάντηση: Ένα αντίγραφο.
Ερώτηση: Είναι μόνο μία γραμμή;
Απάντηση: Αυτό είναι το κύριο και το αντίγραφο. Τα δεδομένα αποθηκεύονται εις διπλούν.
Ερώτηση: Προσαρμόσατε με κάποιο τρόπο το μέγεθος του buffer rsyslog;
Απάντηση: Γράφουμε datagrams σε μια προσαρμοσμένη υποδοχή unix. Αυτό μας επιβάλλει αμέσως έναν περιορισμό 128 kilobyte. Δεν μπορούμε να γράψουμε περισσότερα σε αυτό. Το έχουμε γράψει αυτό στο πρότυπο. Όποιος θέλει να μπει στο χώρο αποθήκευσης, γράφει 128 kilobyte. Οι βιβλιοθήκες, επιπλέον, κόβουν, και βάζουν σημαία ότι το μήνυμα κόβεται. Έχουμε ένα ειδικό πεδίο στο πρότυπο του ίδιου του μηνύματος, το οποίο δείχνει αν κόπηκε κατά την εγγραφή ή όχι. Έχουμε λοιπόν την ευκαιρία να παρακολουθήσουμε αυτή τη στιγμή.
Ερώτηση: Γράφεις σπασμένα JSON;
Απάντηση: Το σπασμένο JSON θα απορριφθεί είτε κατά τη διάρκεια της αναμετάδοσης επειδή το πακέτο είναι πολύ μεγάλο. Διαφορετικά, το Graylog θα απορριφθεί, επειδή δεν θα μπορεί να αναλύσει το JSON. Αλλά υπάρχουν αποχρώσεις εδώ που πρέπει να διορθωθούν και συνδέονται κυρίως με το rsyslog. Έχω ήδη συμπληρώσει μερικά τεύχη εκεί, τα οποία πρέπει να δουλέψουν ακόμα.
Ερώτηση: Γιατί ο Κάφκα; Έχετε δοκιμάσει το RabbitMQ; Το Graylog δεν αθροίζεται κάτω από τέτοια φορτία;
Απάντηση: Δεν βγαίνει με τη Graylog. Και η Graylog παίρνει μορφή. Είναι πραγματικά προβληματικό για αυτόν. Είναι κάτι τέτοιο. Και, στην πραγματικότητα, δεν χρειάζεται. Προτιμώ να γράφω από το rsyslog απευθείας στο elasticsearch και μετά να βλέπω το Kibana. Πρέπει όμως να διευθετήσουμε το θέμα με τους φύλακες. Αυτή είναι μια πιθανή παραλλαγή της ανάπτυξής μας όταν πετάμε το Graylog και χρησιμοποιούμε το Kibana. Το Logstash δεν θα έχει νόημα. Γιατί το ίδιο μπορώ να κάνω και με το rsyslog. Και έχει μια ενότητα για εγγραφή στο elasticsearch. Με το Graylog προσπαθούμε να ζήσουμε κάπως. Το τσιμπήσαμε κιόλας λίγο. Αλλά υπάρχει ακόμα περιθώριο βελτίωσης.
Σχετικά με τον Κάφκα. Έτσι έγινε ιστορικά. Όταν έφτασα, ήταν ήδη εκεί και είχαν ήδη γραφτεί αρχεία καταγραφής. Απλώς αυξήσαμε το σύμπλεγμα μας και μετακινήσαμε κούτσουρα σε αυτό. Τον διαχειριζόμαστε, ξέρουμε πώς νιώθει. Όσο για το RabbitMQ... έχουμε πρόβλημα με το RabbitMQ. Και το RabbitMQ αναπτύσσεται για εμάς. Το έχουμε στην παραγωγή και υπήρχαν προβλήματα με αυτό. Τώρα, πριν από την πώληση, θα σαμανιζόταν και θα άρχιζε να δουλεύει κανονικά. Αλλά πριν από αυτό, δεν ήμουν έτοιμος να το κυκλοφορήσω στην παραγωγή. Υπάρχει ακόμα ένα σημείο. Το Graylog μπορεί να διαβάσει την έκδοση AMQP 0.9 και το rsyslog μπορεί να γράψει την έκδοση AMQP 1.0. Και δεν υπάρχει ούτε μία λύση που να μπορεί να κάνει και τα δύο στη μέση. Υπάρχει είτε το ένα είτε το άλλο. Προς το παρόν λοιπόν μόνο ο Κάφκα. Υπάρχουν όμως και αποχρώσεις. Επειδή το omkafka της έκδοσης του rsyslog που χρησιμοποιούμε μπορεί να χάσει ολόκληρο το buffer μηνυμάτων που πήρε από το rsyslog. Αρκεί να το αντέξουμε.
Ερώτηση: Χρησιμοποιείς τον Κάφκα επειδή τον είχες; Δεν χρησιμοποιείται για κανέναν άλλο σκοπό;
Απάντηση: Kafka, που χρησιμοποιήθηκε από την ομάδα Data Science. Αυτό είναι ένα εντελώς ξεχωριστό έργο, για το οποίο, δυστυχώς, δεν μπορώ να πω τίποτα. Δεν ξέρω. Διευθύνθηκε από την ομάδα Data Science. Όταν ξεκίνησαν τα κούτσουρα, αποφάσισαν να το χρησιμοποιήσουν, για να μην βάλουν το δικό τους. Τώρα έχουμε ενημερώσει το Graylog και έχουμε χάσει τη συμβατότητα, επειδή υπάρχει μια παλιά έκδοση του Kafka. Έπρεπε να φτιάξουμε το δικό μας. Ταυτόχρονα, απαλλαγήκαμε από αυτά τα τέσσερα θέματα για κάθε API. Φτιάξαμε ένα φαρδύ τοπ για όλους ζωντανά, ένα φαρδύ φαρδύ τοπ για όλα τα σκηνικά και απλά τραβάμε τα πάντα εκεί. Η Graylog τα βγάζει όλα αυτά παράλληλα.
Ερώτηση: Γιατί χρειαζόμαστε αυτόν τον σαμανισμό με τις πρίζες; Έχετε δοκιμάσει να χρησιμοποιήσετε το πρόγραμμα οδήγησης καταγραφής syslog για κοντέινερ.
Απάντηση: Την ώρα που κάναμε αυτή την ερώτηση είχαμε τεταμένες σχέσεις με τον λιμενεργάτη. Ήταν docker 1.0 ή 0.9. Ο ίδιος ο Ντόκερ ήταν περίεργος. Δεύτερον, αν βάλετε και κούτσουρα σε αυτό ... Έχω μια μη επαληθευμένη υποψία ότι περνάει όλα τα αρχεία καταγραφής μέσα από τον εαυτό του, μέσω του δαίμονα docker. Εάν έχουμε ένα API που θα τρελαθεί, τότε τα υπόλοιπα API θα αντιμετωπίσουν το γεγονός ότι δεν μπορούν να στείλουν stdout και stderr. Δεν ξέρω πού θα οδηγήσει αυτό. Έχω μια υποψία στο επίπεδο της αίσθησης ότι δεν είναι απαραίτητο να χρησιμοποιήσετε το πρόγραμμα οδήγησης docker syslog σε αυτό το μέρος. Το τμήμα λειτουργικών δοκιμών μας έχει το δικό του σύμπλεγμα Graylog με αρχεία καταγραφής. Χρησιμοποιούν προγράμματα οδήγησης καταγραφής docker και όλα φαίνεται να είναι καλά εκεί. Αμέσως όμως γράφουν GELF στην Graylog. Τη στιγμή που ξεκινήσαμε όλο αυτό, το χρειαζόμασταν για να δουλέψουμε. Ίσως αργότερα, όταν έρθει κάποιος και πει ότι δουλεύει κανονικά εδώ και εκατό χρόνια, να προσπαθήσουμε.
Ερώτηση: Παραδίδετε μεταξύ κέντρων δεδομένων χρησιμοποιώντας το rsyslog. Γιατί όχι στον Κάφκα;
Απάντηση: Το κάνουμε αυτό, και έτσι είναι στην πραγματικότητα. Για δύο λόγους. Εάν το κανάλι είναι τελείως νεκρό, τότε όλα τα κούτσουρα μας, ακόμη και σε συμπιεσμένη μορφή, δεν θα περάσουν μέσα από αυτό. Και ο κάφκα τους επιτρέπει απλώς να χάσουν στη διαδικασία. Με αυτόν τον τρόπο, απαλλαγούμε από το κόλλημα αυτών των κορμών. Απλώς χρησιμοποιούμε τον Κάφκα σε αυτήν την περίπτωση απευθείας. Εάν έχουμε ένα καλό κανάλι και θέλουμε να το ελευθερώσουμε, τότε χρησιμοποιούμε το rsyslog τους. Αλλά στην πραγματικότητα, μπορείτε να το ρυθμίσετε έτσι ώστε να ρίχνει ό,τι δεν πέρασε. Αυτή τη στιγμή απλώς χρησιμοποιούμε την παράδοση rsyslog απευθείας κάπου, κάπου Κάφκα.
Πηγή: www.habr.com