Σήμερα, εκτός από τον μονολιθικό κώδικα, στο έργο μας λειτουργούν δεκάδες microservices. Κάθε ένα από αυτά απαιτεί παρακολούθηση. Είναι προβληματικό να γίνει αυτό σε τέτοιους τόμους από μηχανικούς DevOps. Έχουμε αναπτύξει ένα σύστημα παρακολούθησης που λειτουργεί ως υπηρεσία για προγραμματιστές. Μπορούν να γράψουν ανεξάρτητα μετρήσεις στο σύστημα παρακολούθησης, να τις χρησιμοποιήσουν, να δημιουργήσουν πίνακες εργαλείων με βάση αυτές, να επισυνάψουν ειδοποιήσεις σε αυτές που θα ενεργοποιηθούν όταν συμπληρωθούν οι τιμές κατωφλίου. Με μηχανικούς DevOps - μόνο υποδομή και τεκμηρίωση.
Αυτή η ανάρτηση είναι μια μεταγραφή της ομιλίας μου από εμάς στο RIT++. Πολλοί μας ζήτησαν να κάνουμε εκδόσεις κειμένου των αναφορών από εκεί. Εάν έχετε πάει σε ένα συνέδριο ή παρακολουθήσατε ένα βίντεο, δεν θα βρείτε τίποτα νέο. Και σε όλους τους άλλους - καλώς ήρθατε κάτω από τη γάτα. Θα σας πω πώς καταλήξαμε σε ένα τέτοιο σύστημα, πώς λειτουργεί και πώς σκοπεύουμε να το ενημερώσουμε.
Παρελθόν: σχέδια και σχέδια
Πώς καταλήξαμε στο υπάρχον σύστημα παρακολούθησης; Για να απαντήσετε σε αυτήν την ερώτηση, πρέπει να πάτε στο 2015. Δείτε πώς έμοιαζε τότε:
Είχαμε περίπου 24 κόμβους που ήταν υπεύθυνοι για την παρακολούθηση. Υπάρχει ένα σωρό διαφορετικά crons, σενάρια, δαίμονες που παρακολουθούν κάτι κάπου, στέλνουν μηνύματα, εκτελούν λειτουργίες. Σκεφτήκαμε ότι όσο περισσότερο, τόσο λιγότερο βιώσιμο θα ήταν ένα τέτοιο σύστημα. Δεν έχει νόημα να το αναπτύξουμε: είναι πολύ δυσκίνητο.
Αποφασίσαμε να επιλέξουμε εκείνα τα στοιχεία παρακολούθησης που θα αφήσουμε και θα αναπτύξουμε και αυτά που θα εγκαταλείψουμε. Ήταν 19. Έμειναν μόνο γραφίτες, αθροιστικά και Γραφάνα ως ταμπλό. Πώς θα μοιάζει όμως το νέο σύστημα; Σαν αυτό:
Έχουμε ένα αποθετήριο μετρήσεων: πρόκειται για γραφίτες που θα βασίζονται σε γρήγορες μονάδες SSD, αυτοί είναι ορισμένοι συγκεντρωτές για μετρήσεις. Επόμενο - Grafana για εμφάνιση ταμπλό και Moira ως ειδοποίηση. Θέλαμε επίσης να αναπτύξουμε ένα σύστημα για την εύρεση ανωμαλιών.
Πρότυπο: Monitoring 2.0
Έτσι έμοιαζαν τα σχέδια το 2015. Αλλά έπρεπε να προετοιμάσουμε όχι μόνο την υποδομή και την ίδια την υπηρεσία, αλλά και την τεκμηρίωση για αυτήν. Έχουμε αναπτύξει ένα εταιρικό πρότυπο για εμάς, το οποίο ονομάσαμε παρακολούθηση 2.0. Ποιες ήταν οι απαιτήσεις για το σύστημα;
- σταθερή διαθεσιμότητα?
- Μετρικό διάστημα αποθήκευσης = 10 δευτερόλεπτα.
- δομημένη αποθήκευση μετρήσεων και πινάκων εργαλείων.
- SLA > 99,99%
- συλλογή μετρήσεων συμβάντων μέσω UDP (!).
Χρειαζόμασταν το UDP επειδή έχουμε πολλή επισκεψιμότητα και συμβάντα που δημιουργούν μετρήσεις. Εάν είναι γραμμένα όλα σε γραφίτη ταυτόχρονα, το αποθετήριο θα καταρρεύσει. Επιλέξαμε επίσης προθέματα πρώτου επιπέδου για όλες τις μετρήσεις.
Κάθε ένα από τα προθέματα έχει κάποια ιδιότητα. Υπάρχουν μετρήσεις για διακομιστές, δίκτυα, κοντέινερ, πόρους, εφαρμογές και ούτω καθεξής. Έχει εφαρμοστεί ένα σαφές, αυστηρό, δακτυλογραφημένο φιλτράρισμα, όπου δεχόμαστε τις μετρήσεις πρώτου επιπέδου και απλώς ρίχνουμε τα υπόλοιπα. Έτσι σχεδιάσαμε αυτό το σύστημα το 2015. Τι υπάρχει στο παρόν;
Παρόν: το σχήμα αλληλεπίδρασης των στοιχείων παρακολούθησης
Πρώτα απ 'όλα, παρακολουθούμε τις εφαρμογές: τον κώδικα PHP, τις εφαρμογές και τις μικροϋπηρεσίες μας - με μια λέξη, όλα όσα γράφουν οι προγραμματιστές μας. Όλες οι εφαρμογές στέλνουν μετρήσεις μέσω UDP στον συγκεντρωτή Brubeck (statsd, ξαναγραμμένο σε C). Αποδείχθηκε ότι ήταν το πιο γρήγορο σύμφωνα με τα αποτελέσματα των συνθετικών δοκιμών. Και στέλνει τις ήδη συγκεντρωμένες μετρήσεις στο Graphite μέσω TCP.
Έχει τέτοιου είδους μετρήσεις όπως χρονόμετρα. Αυτό είναι ένα πολύ βολικό πράγμα. Για παράδειγμα, για κάθε σύνδεση χρήστη στην υπηρεσία, στέλνετε μια μέτρηση χρόνου απόκρισης στο Brubeck. Ήρθαν ένα εκατομμύριο απαντήσεις και ο αθροιστής έδωσε μόνο 10 μετρήσεις. Έχετε τον αριθμό των ατόμων που ήρθαν, τους μέγιστους, ελάχιστους και μέσους χρόνους απόκρισης, τη διάμεσο και 4 εκατοστημόρια. Στη συνέχεια τα δεδομένα μεταφέρονται στο Graphite και τα βλέπουμε όλα ζωντανά.
Έχουμε επίσης συνάθροιση για υλικό, λογισμικό, μετρήσεις συστήματος και το παλιό μας σύστημα παρακολούθησης Munin (δούλευε μαζί μας μέχρι το 2015). Όλα αυτά τα συλλέγουμε μέσω του C'ish daemon CollectD (μια ολόκληρη δέσμη από διάφορα πρόσθετα είναι ραμμένα σε αυτό, μπορεί να αναζητήσει όλους τους πόρους του συστήματος υποδοχής στο οποίο είναι εγκατεστημένο, απλώς να καθορίσει στη διαμόρφωση πού θα γράψει δεδομένα) και να γράψει δεδομένα μέσω αυτού στο Graphite. Υποστηρίζει επίσης πρόσθετα python και σενάρια κελύφους, ώστε να μπορείτε να γράψετε τις δικές σας προσαρμοσμένες λύσεις: Το CollectD θα συλλέξει αυτά τα δεδομένα από έναν τοπικό ή απομακρυσμένο κεντρικό υπολογιστή (υποθέστε ότι υπάρχει Curl) και θα τα στείλει στο Graphite.
Επιπλέον, όλες οι μετρήσεις που έχουμε συλλέξει αποστέλλονται στο Carbon-c-relay. Αυτή είναι η λύση Carbon Relay της Graphite, τροποποιημένη σε C. Αυτός είναι ένας δρομολογητής που συλλέγει όλες τις μετρήσεις που στέλνουμε από τους συγκεντρωτές μας και τις δρομολογεί μέσω των κόμβων. Επίσης, στο στάδιο της δρομολόγησης, ελέγχει την εγκυρότητα των μετρήσεων. Πρώτον, πρέπει να ταιριάζουν με το σχήμα προθέματος που έδειξα νωρίτερα και, δεύτερον, πρέπει να ισχύουν για γραφίτη. Διαφορετικά, πέφτουν.
Στη συνέχεια, το Carbon-c-relay στέλνει τις μετρήσεις στο σύμπλεγμα Graphite. Χρησιμοποιούμε το Carbon-cache που έχει ξαναγραφεί στο Go ως κύριο αποθηκευτικό χώρο για μετρήσεις. Το Go-carbon, λόγω του πολλαπλού νήματος του, είναι πολύ ανώτερο σε απόδοση από το Carbon-cache. Παίρνει δεδομένα στον εαυτό του και τα γράφει στο δίσκο χρησιμοποιώντας το πακέτο whisper (τυπικό, γραμμένο σε python). Για να διαβάσουμε δεδομένα από τις αποθήκες μας, χρησιμοποιούμε το Graphite API. Λειτουργεί πολύ πιο γρήγορα από το τυπικό Graphite WEB. Τι θα γίνει με τα δεδομένα στη συνέχεια;
Πάνε στη Γραφάνα. Χρησιμοποιούμε τα συμπλέγματα γραφίτη μας ως κύρια πηγή δεδομένων, καθώς και το Grafana ως διεπαφή ιστού για την εμφάνιση μετρήσεων, την κατασκευή πινάκων εργαλείων. Για κάθε υπηρεσία τους, οι προγραμματιστές δημιουργούν τον δικό τους πίνακα ελέγχου. Στη συνέχεια χτίζουν γραφήματα με βάση αυτά, τα οποία εμφανίζουν τις μετρήσεις που γράφουν από τις εφαρμογές τους. Εκτός από τη Γραφάνα έχουμε και SLAM. Αυτός είναι ένας πύθωνας δαίμονας που υπολογίζει το SLA με βάση δεδομένα από γραφίτη. Όπως είπα, έχουμε αρκετές δεκάδες microservices, καθεμία από τις οποίες έχει τις δικές της απαιτήσεις. Με τη βοήθεια του SLAM, πηγαίνουμε στην τεκμηρίωση και τη συγκρίνουμε με αυτό που υπάρχει στο Graphite και συγκρίνουμε πώς οι απαιτήσεις αντιστοιχούν στη διαθεσιμότητα των υπηρεσιών μας.
Προχωρώντας παρακάτω: ειδοποίηση. Είναι οργανωμένη με ισχυρό σύστημα - Μοίρα. Είναι ανεξάρτητη γιατί έχει το δικό της Graphite κάτω από την κουκούλα. Αναπτύχθηκε από τα παιδιά από το SKB Kontur, γραμμένο σε python και Go, πλήρως ανοιχτού κώδικα. Η Μόιρα δέχεται όλη την ίδια ροή που πηγαίνει στους γραφίτες. Εάν για κάποιο λόγο η αποθήκευσή σας πεθάνει, τότε η ειδοποίησή σας θα λειτουργήσει.
Αναπτύξαμε το Moira στο Kubernetes, χρησιμοποιεί ένα σύμπλεγμα διακομιστών Redis ως κύρια βάση δεδομένων. Το αποτέλεσμα είναι ένα σύστημα ανεκτικό σε σφάλματα. Συγκρίνει τη ροή των μετρήσεων με τη λίστα των ενεργειών: αν δεν υπάρχουν αναφορές σε αυτήν, τότε απορρίπτει τη μέτρηση. Έτσι είναι σε θέση να αφομοιώσει gigabytes μετρήσεων ανά λεπτό.
Προσθέσαμε επίσης ένα εταιρικό LDAP σε αυτό, με τη βοήθεια του οποίου κάθε χρήστης του εταιρικού συστήματος μπορεί να δημιουργήσει ειδοποιήσεις για τον εαυτό του για υπάρχοντες (ή νεοδημιουργηθέντες) κανόνες ενεργοποίησης. Δεδομένου ότι το Moira περιέχει Graphite, υποστηρίζει όλες τις δυνατότητες του. Έτσι, πρώτα παίρνετε τη γραμμή και την αντιγράφετε στο Grafana. Δείτε πώς εμφανίζονται τα δεδομένα στα γραφήματα. Και μετά παίρνετε την ίδια γραμμή και την αντιγράφετε στο Moira. Κρεμάστε το με όρια και λάβετε ειδοποίηση στην έξοδο. Για να τα κάνετε όλα αυτά, δεν χρειάζεστε καμία συγκεκριμένη γνώση. Το Moira μπορεί να ειδοποιεί μέσω SMS, email, Jira, Slack… Υποστηρίζει επίσης προσαρμοσμένα σενάρια. Όταν έχει ένα έναυσμα και έχει εγγραφεί σε ένα προσαρμοσμένο σενάριο ή δυαδικό, το εκκινεί και στέλνει αυτό το δυαδικό αρχείο JSON στο stdin. Κατά συνέπεια, το πρόγραμμά σας θα πρέπει να το αναλύσει. Το τι θα κάνετε με αυτό το JSON εξαρτάται από εσάς. Αν θες στείλε στο Telegram, αν θες άνοιξε tasks στο Jira, κάνε ό,τι θέλεις.
Χρησιμοποιούμε επίσης τη δική μας ανάπτυξη για ειδοποίηση - Imagotag. Προσαρμόσαμε το πάνελ, που χρησιμοποιείται συνήθως για ηλεκτρονικές τιμές στα καταστήματα, στις ανάγκες μας. Του φέραμε σκανδάλες από τη Μοίρα. Δείχνει σε τι κατάσταση βρίσκονται, πότε συνέβησαν. Μερικά από τα παιδιά από την ανάπτυξη εγκατέλειψαν τις ειδοποιήσεις στο Slack και στο mail υπέρ αυτού του πίνακα.
Λοιπόν, αφού είμαστε μια προοδευτική εταιρεία, παρακολουθήσαμε και την Kubernetes σε αυτό το σύστημα. Το συμπεριέλαβε στο σύστημα χρησιμοποιώντας το Heapster, το οποίο εγκαταστήσαμε στο σύμπλεγμα, συλλέγει δεδομένα και τα στέλνει στο Graphite. Ως αποτέλεσμα, το σχήμα μοιάζει με αυτό:
Εξαρτήματα παρακολούθησης
Ακολουθεί μια λίστα με συνδέσμους προς τα στοιχεία που χρησιμοποιήσαμε για αυτήν την εργασία. Όλα είναι ανοιχτού κώδικα.
Γραφίτης:
- go-carbon:
- ψίθυρος:
- graphite-api:
Ρελέ άνθρακα-c:
Μπρούμπεκ:
Συγκεντρωμένος:
Μόιρα:
Γραφάνα:
Heapster:
Στατιστική
Και εδώ είναι μερικοί αριθμοί για το πώς λειτουργεί το σύστημα για εμάς.
Συγκεντρωτής (μπρουμπέκ)
Αριθμός μετρήσεων: ~ 300 / δευτερόλεπτο
Διάστημα αποστολής μετρικών γραφίτη: 30 δευτ
Αξιοποίηση πόρων διακομιστή: ~ 6% CPU (μιλάμε για πλήρεις διακομιστές). ~ 1Gb RAM; ~ 3 Mbps LAN
Γραφίτης (go-carbon)
Αριθμός μετρήσεων: ~ 1 / λεπτό
Μεσοδιάστημα ενημέρωσης μετρήσεων: 30 δευτερόλεπτα
Σχέδιο αποθήκευσης μετρήσεων: 30sec 35d, 5min 90d, 10min 365d (δίνει κατανόηση του τι συμβαίνει στην υπηρεσία για μεγάλο χρονικό διάστημα)
Χρήση πόρων διακομιστή: ~10% CPU; ~ 20 Gb RAM; ~ 30 Mbps LAN
Ευκαμψία
Εμείς στην Avito εκτιμούμε πραγματικά την ευελιξία στην υπηρεσία παρακολούθησης. Γιατί τελικά βγήκε έτσι; Πρώτον, τα συστατικά μέρη του είναι εναλλάξιμα: τόσο τα ίδια τα εξαρτήματα όσο και οι εκδόσεις τους. Δεύτερον, συντηρησιμότητα. Δεδομένου ότι ολόκληρο το έργο είναι χτισμένο σε ανοιχτό κώδικα, μπορείτε να επεξεργαστείτε τον κώδικα μόνοι σας, να κάνετε αλλαγές και να εφαρμόσετε λειτουργίες που δεν είναι διαθέσιμες από το κουτί. Χρησιμοποιούνται αρκετά κοινές στοίβες, κυρίως Go και Python, οπότε αυτό γίνεται πολύ απλά.
Εδώ είναι ένα παράδειγμα ενός πραγματικού προβλήματος. Μια μέτρηση στο Graphite είναι ένα αρχείο. Έχει όνομα. Όνομα αρχείου = μετρικό όνομα. Και υπάρχει τρόπος να φτάσετε εκεί. Τα ονόματα αρχείων στο Linux περιορίζονται στους 255 χαρακτήρες. Και έχουμε (ως «εσωτερικούς πελάτες») παιδιά από το τμήμα της βάσης δεδομένων. Μας λένε: «Θέλουμε να παρακολουθούμε τα ερωτήματά μας SQL. Και δεν είναι 255 χαρακτήρες, αλλά 8 MB το καθένα. Θέλουμε να τα εμφανίσουμε στο Grafana, να δούμε τις παραμέτρους για αυτό το αίτημα και ακόμα καλύτερα, θέλουμε να δούμε την κορυφή τέτοιων αιτημάτων. Θα είναι υπέροχο αν εμφανίζεται σε πραγματικό χρόνο. Και θα ήταν πολύ ωραίο να τους βάλουμε σε εγρήγορση».
Το παράδειγμα ερωτήματος SQL λαμβάνεται ως παράδειγμα από
Ανεβάζουμε τον διακομιστή Redis και τα πρόσθετα Collectd που πηγαίνουν στο Postgres και παίρνουν όλα τα δεδομένα από εκεί, στέλνουμε μετρήσεις στο Graphite. Αλλά αντικαθιστούμε το όνομα της μέτρησης με κατακερματισμούς. Ο ίδιος κατακερματισμός αποστέλλεται ταυτόχρονα στο Redis ως κλειδί και ολόκληρο το ερώτημα SQL ως τιμή. Μένει να κάνουμε τη Γραφάνα να μπορέσει να πάει στο Ρέντις και να λάβει αυτές τις πληροφορίες. Ανοίγουμε το Graphite API γιατί Αυτή είναι η κύρια διασύνδεση για την αλληλεπίδραση όλων των στοιχείων παρακολούθησης με γραφίτη και εισάγουμε μια νέα συνάρτηση που ονομάζεται aliasByHash () εκεί - παίρνουμε το όνομα της μέτρησης από το Grafana και το χρησιμοποιούμε σε ένα αίτημα προς το Redis ως κλειδί, σε απάντηση παίρνουμε την τιμή του κλειδιού, που είναι το "SQL ερώτημα". Έτσι, φέραμε στο Grafana την εμφάνιση ενός ερωτήματος SQL, το οποίο, θεωρητικά, δεν μπορούσε να εμφανιστεί εκεί, μαζί με τα στατιστικά του (κλήσεις, σειρές, συνολικό_χρόνος, ...).
Αποτελέσματα της
Διαθεσιμότητα. Η υπηρεσία παρακολούθησης μας είναι διαθέσιμη 24/7 από οποιαδήποτε εφαρμογή και οποιονδήποτε κωδικό. Εάν έχετε πρόσβαση στους αποθηκευτικούς χώρους, μπορείτε να γράψετε δεδομένα στην υπηρεσία. Η γλώσσα δεν είναι σημαντική, οι αποφάσεις δεν είναι σημαντικές. Χρειάζεται μόνο να ξέρετε πώς να ανοίξετε μια πρίζα, να ρίξετε μια μέτρηση εκεί και να κλείσετε την πρίζα.
Αξιοπιστία. Όλα τα εξαρτήματα είναι ανεκτικά σε σφάλματα και χειρίζονται καλά τον φόρτο εργασίας μας.
Χαμηλό όριο εισόδου. Για να χρησιμοποιήσετε αυτό το σύστημα, δεν χρειάζεται να μάθετε γλώσσες προγραμματισμού και ερωτήματα στο Grafana. Απλώς ανοίξτε την εφαρμογή σας, προσθέστε μια υποδοχή σε αυτήν που θα στέλνει μετρήσεις στο Graphite, κλείστε το, ανοίξτε το Grafana, δημιουργήστε εκεί πίνακες ελέγχου και δείτε τη συμπεριφορά των μετρήσεων σας, λαμβάνοντας ειδοποιήσεις μέσω της Moira.
Ανεξαρτησία. Μπορείτε να τα κάνετε όλα αυτά μόνοι σας, χωρίς τη βοήθεια μηχανικών DevOps. Και αυτό είναι ένα υπερβολικό χαρακτηριστικό, επειδή μπορείτε να παρακολουθείτε το έργο σας αυτή τη στιγμή, δεν χρειάζεται να ζητήσετε από κανέναν - ούτε να ξεκινήσετε την εργασία ούτε να κάνετε αλλαγές.
Τι επιδιώκουμε;
Όλα όσα αναφέρονται παρακάτω δεν είναι απλώς αφηρημένες σκέψεις, αλλά κάτι προς το οποίο έχουν γίνει τουλάχιστον τα πρώτα βήματα.
- ανιχνευτής ανωμαλιών. Θέλουμε να δημιουργήσουμε μια υπηρεσία που θα πηγαίνει στους αποθηκευτικούς μας χώρους Graphite και θα ελέγχει κάθε μέτρηση χρησιμοποιώντας διάφορους αλγόριθμους. Υπάρχουν ήδη αλγόριθμοι που θέλουμε να δούμε, υπάρχουν δεδομένα, ξέρουμε πώς να δουλέψουμε με αυτά.
- μεταδεδομένα. Έχουμε πολλές υπηρεσίες, αλλάζουν με τον καιρό, όπως και οι άνθρωποι που συνεργάζονται μαζί τους. Η μη αυτόματη διατήρηση αρχείων δεν αποτελεί επιλογή. Επομένως, τα μεταδεδομένα είναι πλέον ενσωματωμένα στις μικροϋπηρεσίες μας. Αναφέρει ποιος το ανέπτυξε, τις γλώσσες με τις οποίες αλληλεπιδρά, τις απαιτήσεις SLA, πού και σε ποιον να αποστέλλονται ειδοποιήσεις. Κατά την ανάπτυξη μιας υπηρεσίας, όλα τα δεδομένα οντοτήτων δημιουργούνται ανεξάρτητα. Ως αποτέλεσμα, λαμβάνετε δύο συνδέσμους - έναν για εναύσματα και τον άλλο για πίνακες εργαλείων στο Grafana.
- Παρακολούθηση σε κάθε σπίτι. Πιστεύουμε ότι όλοι οι προγραμματιστές πρέπει να χρησιμοποιούν ένα τέτοιο σύστημα. Σε αυτή την περίπτωση, καταλαβαίνεις πάντα πού είναι η επισκεψιμότητά σου, τι της συμβαίνει, πού πέφτει, πού έχει αδύναμα σημεία. Εάν, για παράδειγμα, έρθει κάτι και καταρρεύσει η υπηρεσία σας, τότε θα το μάθετε όχι κατά τη διάρκεια μιας κλήσης από τον διαχειριστή, αλλά από μια ειδοποίηση και μπορείτε να ανοίξετε αμέσως νέα αρχεία καταγραφής και να δείτε τι συνέβη εκεί.
- Υψηλή απόδοση. Το έργο μας αναπτύσσεται συνεχώς και σήμερα επεξεργάζεται περίπου 2 μετρικές τιμές ανά λεπτό. Πριν από ένα χρόνο, ο αριθμός αυτός ήταν 000. Και η ανάπτυξη συνεχίζεται, και αυτό σημαίνει ότι μετά από κάποιο χρονικό διάστημα ο Graphite (ψίθυρος) θα αρχίσει να φορτώνει πολύ βαριά το υποσύστημα του δίσκου. Όπως είπα, αυτό το σύστημα παρακολούθησης είναι αρκετά ευέλικτο λόγω της εναλλαξιμότητας των εξαρτημάτων. Κάποιος ειδικά για το Graphite διατηρεί και επεκτείνει συνεχώς την υποδομή του, αλλά αποφασίσαμε να πάμε προς την άλλη κατεύθυνση: χρήση ως αποθήκη για τις μετρήσεις μας. Αυτή η μετάβαση έχει σχεδόν ολοκληρωθεί και πολύ σύντομα θα σας πω με περισσότερες λεπτομέρειες πώς έγινε: ποιες ήταν οι δυσκολίες και πώς ξεπεράστηκαν, πώς πήγε η διαδικασία μετεγκατάστασης, θα περιγράψω τα στοιχεία που επιλέχθηκαν ως δεσμευτικά και τις διαμορφώσεις τους.
Σας ευχαριστώ για την προσοχή σας! Κάντε τις ερωτήσεις σας για το θέμα, θα προσπαθήσω να απαντήσω εδώ ή στις επόμενες αναρτήσεις. Ίσως κάποιος έχει εμπειρία στην κατασκευή ενός παρόμοιου συστήματος παρακολούθησης ή στη μετάβαση στο Clickhouse σε παρόμοια κατάσταση - μοιραστείτε το στα σχόλια.
Πηγή: www.habr.com