Το όνομά μου είναι Anton Baderin. Εργάζομαι στο Κέντρο Υψηλής Τεχνολογίας και κάνω διαχείριση συστήματος. Πριν από ένα μήνα ολοκληρώθηκε το εταιρικό μας συνέδριο, όπου μοιραστήκαμε τη συσσωρευμένη εμπειρία μας με την κοινότητα πληροφορικής της πόλης μας. Μίλησα για την παρακολούθηση εφαρμογών ιστού. Το υλικό προοριζόταν για junior ή μεσαίο επίπεδο, που δεν έχτισαν αυτή τη διαδικασία από την αρχή.
Ο ακρογωνιαίος λίθος που βρίσκεται κάτω από κάθε σύστημα παρακολούθησης είναι η επίλυση επιχειρηματικών προβλημάτων. Η παρακολούθηση για λόγους παρακολούθησης δεν ενδιαφέρει κανέναν. Τι θέλει η επιχείρηση; Για να λειτουργούν όλα γρήγορα και χωρίς λάθη. Οι επιχειρήσεις θέλουν να είναι προληπτικές, ώστε εμείς οι ίδιοι να εντοπίσουμε προβλήματα στην υπηρεσία και να τα διορθώσουμε το συντομότερο δυνατό. Αυτά, στην πραγματικότητα, είναι τα προβλήματα που έλυσα όλο τον περασμένο χρόνο σε ένα έργο για έναν από τους πελάτες μας.
Σχετικά με το έργο
Το έργο είναι ένα από τα μεγαλύτερα προγράμματα πιστότητας στη χώρα. Βοηθάμε τις αλυσίδες λιανικής να αυξήσουν τη συχνότητα των πωλήσεων μέσω διαφόρων εργαλείων μάρκετινγκ, όπως οι κάρτες μπόνους. Συνολικά, το έργο περιλαμβάνει 14 εφαρμογές που τρέχουν σε δέκα διακομιστές.
Κατά τη διαδικασία της συνέντευξης, παρατήρησα επανειλημμένα ότι οι διαχειριστές δεν προσεγγίζουν πάντα σωστά την παρακολούθηση εφαρμογών ιστού: πολλοί εξακολουθούν να εστιάζουν στις μετρήσεις του λειτουργικού συστήματος και περιστασιακά παρακολουθούν τις υπηρεσίες.
Στην περίπτωσή μου, το σύστημα παρακολούθησης του πελάτη βασιζόταν προηγουμένως στο Icinga. Δεν έλυσε με κανέναν τρόπο τα παραπάνω προβλήματα. Συχνά ο ίδιος ο πελάτης μας ενημέρωσε για προβλήματα και τις περισσότερες φορές απλώς δεν είχαμε αρκετά δεδομένα για να καταλάβουμε τον λόγο.
Επιπλέον, υπήρχε σαφής κατανόηση της ματαιότητας της περαιτέρω ανάπτυξής του. Νομίζω ότι όσοι γνωρίζουν το Icinga θα με καταλάβουν. Έτσι, αποφασίσαμε να επανασχεδιάσουμε πλήρως το σύστημα παρακολούθησης διαδικτυακών εφαρμογών για το έργο.
Προμηθέας
Επιλέξαμε τον Προμηθέα με βάση τρεις βασικούς δείκτες:
- Ένας τεράστιος αριθμός διαθέσιμων μετρήσεων. Στην περίπτωσή μας υπάρχουν 60 χιλιάδες από αυτούς. Αξίζει βέβαια να σημειωθεί ότι δεν χρησιμοποιούμε τη συντριπτική τους πλειοψηφία (μάλλον περίπου το 95%). Από την άλλη, είναι όλα σχετικά φθηνά. Για εμάς, αυτό είναι το άλλο άκρο σε σύγκριση με το Icinga που χρησιμοποιήθηκε στο παρελθόν. Σε αυτό, η προσθήκη μετρήσεων ήταν ιδιαίτερος πόνος: οι υπάρχουσες ήταν ακριβές (απλώς κοιτάξτε τον πηγαίο κώδικα οποιουδήποτε πρόσθετου). Οποιοδήποτε πρόσθετο ήταν ένα σενάριο σε Bash ή Python, η κυκλοφορία του οποίου είναι ακριβή όσον αφορά τους πόρους που καταναλώνονται.
- Αυτό το σύστημα καταναλώνει σχετικά μικρό ποσό πόρων. 600 MB μνήμης RAM, 15% ενός πυρήνα και μερικές ντουζίνες IOPS είναι αρκετά για όλες τις μετρήσεις μας. Φυσικά, πρέπει να εκτελείτε εξαγωγείς μετρήσεων, αλλά είναι όλα γραμμένα στο Go και επίσης δεν χρειάζονται πολύ ενέργεια. Δεν νομίζω ότι στη σύγχρονη πραγματικότητα αυτό είναι πρόβλημα.
- Παρέχει τη δυνατότητα μετανάστευσης στο Kubernetes. Λαμβάνοντας υπόψη τα σχέδια του πελάτη, η επιλογή είναι προφανής.
ΜΕΓΑΛΗ ΕΛΑΦΟΣ
Προηγουμένως, δεν συλλέγαμε ούτε επεξεργαζόμασταν αρχεία καταγραφής. Οι ελλείψεις είναι ξεκάθαρες σε όλους. Επιλέξαμε το ΕΛΚ γιατί είχαμε ήδη εμπειρία με αυτό το σύστημα. Εκεί αποθηκεύουμε μόνο αρχεία καταγραφής εφαρμογών. Τα κύρια κριτήρια επιλογής ήταν η αναζήτηση πλήρους κειμένου και η ταχύτητά της.
Сlickhouse
Αρχικά, η επιλογή έπεσε στο InfluxDB. Συνειδητοποιήσαμε την ανάγκη συλλογής αρχείων καταγραφής Nginx, στατιστικών στοιχείων από pg_stat_statements και αποθήκευσης ιστορικών δεδομένων Prometheus. Δεν μας άρεσε το Influx γιατί περιοδικά άρχισε να καταναλώνει μεγάλη ποσότητα μνήμης και κολλούσε. Επιπλέον, ήθελα να ομαδοποιήσω ερωτήματα κατά remote_addr, αλλά η ομαδοποίηση σε αυτό το DBMS γίνεται μόνο με ετικέτες. Οι ετικέτες είναι ακριβές (μνήμη), ο αριθμός τους είναι περιορισμένος υπό όρους.
Αρχίσαμε ξανά την αναζήτησή μας. Αυτό που χρειαζόταν ήταν μια αναλυτική βάση δεδομένων με ελάχιστη κατανάλωση πόρων, κατά προτίμηση με συμπίεση δεδομένων σε δίσκο.
Το Clickhouse πληροί όλα αυτά τα κριτήρια και ποτέ δεν μετανιώσαμε για την επιλογή μας. Δεν γράφουμε καμία έκτακτη ποσότητα δεδομένων σε αυτό (ο αριθμός των εισαγωγών είναι μόνο περίπου πέντε χιλιάδες ανά λεπτό).
NewRelic
Η NewRelic ήταν ιστορικά μαζί μας επειδή ήταν επιλογή του πελάτη. Το χρησιμοποιούμε ως APM.
Zabbix
Χρησιμοποιούμε το Zabbix αποκλειστικά για την παρακολούθηση του Black Box διαφόρων API.
Καθορισμός μιας προσέγγισης παρακολούθησης
Θέλαμε να αποσυνθέσουμε την εργασία και έτσι να συστηματοποιήσουμε την προσέγγιση της παρακολούθησης.
Για να γίνει αυτό, χώρισα το σύστημά μας στα ακόλουθα επίπεδα:
- Υλικό και VMS·
- λειτουργικό σύστημα;
- υπηρεσίες συστήματος, στοίβα λογισμικού.
- εφαρμογή;
- επαγγελματική λογική.
Γιατί είναι βολική αυτή η προσέγγιση:
- Γνωρίζουμε ποιος είναι υπεύθυνος για το έργο κάθε επιπέδου και, βάσει αυτού, μπορούμε να στείλουμε ειδοποιήσεις.
- μπορούμε να χρησιμοποιήσουμε τη δομή κατά την καταστολή ειδοποιήσεων - θα ήταν περίεργο να στείλουμε μια ειδοποίηση σχετικά με τη μη διαθεσιμότητα της βάσης δεδομένων όταν η εικονική μηχανή στο σύνολό της δεν είναι διαθέσιμη.
Δεδομένου ότι το καθήκον μας είναι να εντοπίσουμε παραβιάσεις στη λειτουργία του συστήματος, πρέπει σε κάθε επίπεδο να επισημάνουμε ένα συγκεκριμένο σύνολο μετρήσεων που αξίζει να προσέξουμε κατά τη σύνταξη κανόνων ειδοποίησης. Στη συνέχεια, ας περάσουμε από τα επίπεδα "VMS", "Λειτουργικό σύστημα" και "Υπηρεσίες συστήματος, στοίβα λογισμικού".
Εικονικές μηχανές
Η φιλοξενία μας εκχωρεί επεξεργαστή, δίσκο, μνήμη και δίκτυο. Και είχαμε προβλήματα με τα δύο πρώτα. Λοιπόν, οι μετρήσεις:
Κλεμένος χρόνος CPU - όταν αγοράζετε μια εικονική μηχανή στο Amazon (t2.micro, για παράδειγμα), θα πρέπει να καταλάβετε ότι δεν σας εκχωρείται ένας ολόκληρος πυρήνας επεξεργαστή, αλλά μόνο ένα όριο του χρόνου του. Και όταν το εξαντλήσετε, ο επεξεργαστής θα αφαιρεθεί από εσάς.
Αυτή η μέτρηση σάς επιτρέπει να παρακολουθείτε τέτοιες στιγμές και να λαμβάνετε αποφάσεις. Για παράδειγμα, είναι απαραίτητο να λάβετε ένα πιο παχύ τιμολόγιο ή να διανείμετε την επεξεργασία των εργασιών παρασκηνίου και των αιτημάτων API σε διαφορετικούς διακομιστές;
Χρόνος αναμονής IOPS + CPU - για κάποιο λόγο, πολλά cloud hostings αμαρτάνουν επειδή δεν παρέχουν αρκετό IOPS. Επιπλέον, ένα πρόγραμμα με χαμηλό IOPS δεν αποτελεί επιχείρημα για αυτούς. Επομένως, αξίζει να συλλέξετε CPU iowait. Με αυτό το ζευγάρι γραφημάτων - με χαμηλό IOPS και υψηλή αναμονή εισόδου/εξόδου - μπορείτε ήδη να μιλήσετε με το hosting και να λύσετε το πρόβλημα.
Λειτουργικό σύστημα
Μετρήσεις λειτουργικού συστήματος:
- ποσότητα διαθέσιμης μνήμης σε %·
- δραστηριότητα swap χρήσης: vmstat swapin, swapout;
- αριθμός διαθέσιμων ινωδών και ελεύθερος χώρος στο σύστημα αρχείων σε %
- μέσο φορτίο?
- αριθμός συνδέσεων σε κατάσταση δύο.
- Conntrack πληρότητα πίνακα?
- Η ποιότητα του δικτύου μπορεί να παρακολουθηθεί χρησιμοποιώντας το βοηθητικό πρόγραμμα ss, το πακέτο iproute2 - λάβετε μια ένδειξη των συνδέσεων RTT από την έξοδο του και ομαδοποιήστε το ανά θύρα προορισμού.
Επίσης σε επίπεδο λειτουργικού συστήματος έχουμε μια τέτοια οντότητα ως διεργασίες. Είναι σημαντικό να εντοπιστεί στο σύστημα ένα σύνολο διαδικασιών που παίζουν σημαντικό ρόλο στη λειτουργία του. Εάν, για παράδειγμα, έχετε πολλά pgpool, τότε πρέπει να συλλέξετε πληροφορίες για καθένα από αυτά.
Το σύνολο των μετρήσεων έχει ως εξής:
- ΕΠΕΞΕΡΓΑΣΤΗΣ;
- Η μνήμη είναι κατά κύριο λόγο μόνιμος.
- IO - κατά προτίμηση σε IOPS.
- FileFd - άνοιγμα και περιορισμός.
- σημαντικές αποτυχίες σελίδας - με αυτόν τον τρόπο μπορείτε να καταλάβετε ποια διαδικασία ανταλλάσσεται.
Αναπτύσσουμε όλη την παρακολούθηση στο Docker και χρησιμοποιούμε το Advisor για τη συλλογή δεδομένων μετρήσεων. Σε άλλα μηχανήματα χρησιμοποιούμε διεργασία-εξαγωγέα.
Υπηρεσίες συστήματος, στοίβα λογισμικού
Κάθε εφαρμογή έχει τις δικές της ιδιαιτερότητες και είναι δύσκολο να ξεχωρίσεις ένα συγκεκριμένο σύνολο μετρήσεων.
Το σετ γενικής χρήσης είναι:
- ποσοστό αίτησης?
- αριθμός λαθών?
- αφάνεια;
- κορεσμός.
Τα πιο εντυπωσιακά παραδείγματα παρακολούθησης σε αυτό το επίπεδο είναι το Nginx και το PostgreSQL.
Η πιο φορτωμένη υπηρεσία στο σύστημά μας είναι η βάση δεδομένων. Στο παρελθόν, είχαμε συχνά πρόβλημα να καταλάβουμε τι έκανε η βάση δεδομένων.
Είδαμε μεγάλο φορτίο στους δίσκους, αλλά τα αργά αρχεία καταγραφής δεν έδειχναν τίποτα. Επιλύσαμε αυτό το πρόβλημα χρησιμοποιώντας pg_stat_statements, μια προβολή που συλλέγει στατιστικά ερωτημάτων.
Αυτό είναι το μόνο που χρειάζεται ο διαχειριστής.
Δημιουργούμε γραφήματα της δραστηριότητας των αιτημάτων ανάγνωσης και εγγραφής:
Όλα είναι απλά και ξεκάθαρα, κάθε αίτημα έχει το δικό του χρώμα.
Ένα εξίσου εντυπωσιακό παράδειγμα είναι τα αρχεία καταγραφής Nginx. Δεν προκαλεί έκπληξη το γεγονός ότι λίγοι άνθρωποι τα αναλύουν ή τα αναφέρουν στη λίστα με τα απαραίτητα. Η τυπική μορφή δεν είναι πολύ ενημερωτική και πρέπει να επεκταθεί.
Προσωπικά, πρόσθεσα request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Σχεδιάζουμε το χρόνο απόκρισης και τον αριθμό των σφαλμάτων:
Κατασκευάζουμε γραφήματα του χρόνου απόκρισης και του αριθμού των σφαλμάτων. Θυμάμαι? Μίλησα για επιχειρηματικούς στόχους; Γρήγορα και χωρίς λάθη; Έχουμε ήδη καλύψει αυτά τα θέματα με δύο γραφήματα. Και μπορείτε ήδη να καλέσετε τους εφημερεύοντες διαχειριστές χρησιμοποιώντας τους.
Αλλά ένα ακόμη πρόβλημα παραμένει - να εξασφαλιστεί η ταχεία εξάλειψη των αιτιών του συμβάντος.
Επίλυση περιστατικού
Η όλη διαδικασία από τον εντοπισμό έως την επίλυση ενός προβλήματος μπορεί να χωριστεί σε διάφορα στάδια:
- εντοπισμός του προβλήματος·
- κοινοποίηση στον διοικητή υπηρεσίας·
- απάντηση σε ένα περιστατικό·
- εξάλειψη των αιτιών.
Είναι σημαντικό να το κάνουμε αυτό το συντομότερο δυνατό. Και αν στα στάδια του εντοπισμού ενός προβλήματος και της αποστολής μιας ειδοποίησης δεν μπορούμε να κερδίσουμε πολύ χρόνο - σε κάθε περίπτωση θα δαπανηθούν δύο λεπτά σε αυτά, τότε τα επόμενα είναι απλώς μη οργωμένο πεδίο για βελτιώσεις.
Ας φανταστούμε ότι χτύπησε το τηλέφωνο του αξιωματικού υπηρεσίας. Τι θα κάνει; Αναζητήστε απαντήσεις σε ερωτήσεις - τι έσπασε, πού χάλασε, πώς να αντιδράσετε; Δείτε πώς απαντάμε σε αυτές τις ερωτήσεις:
Απλώς συμπεριλαμβάνουμε όλες αυτές τις πληροφορίες στο κείμενο της ειδοποίησης, της δίνουμε έναν σύνδεσμο προς μια σελίδα wiki που περιγράφει πώς να απαντήσετε σε αυτό το πρόβλημα, πώς να το επιλύσετε και να το κλιμακώσετε.
Ακόμα δεν έχω πει τίποτα για το επίπεδο εφαρμογής και την επιχειρηματική λογική. Δυστυχώς, οι εφαρμογές μας δεν εφαρμόζουν ακόμη τη συλλογή μετρήσεων. Η μόνη πηγή οποιασδήποτε πληροφορίας από αυτά τα επίπεδα είναι τα αρχεία καταγραφής.
Μερικά σημεία.
Πρώτα, γράψτε δομημένα αρχεία καταγραφής. Δεν χρειάζεται να συμπεριλάβετε το πλαίσιο στο κείμενο του μηνύματος. Αυτό τους κάνει δύσκολο να ομαδοποιηθούν και να αναλυθούν. Το Logstash χρειάζεται πολύ χρόνο για να ομαλοποιήσει όλα αυτά.
Δεύτερον, χρησιμοποιήστε σωστά τα επίπεδα σοβαρότητας. Κάθε γλώσσα έχει το δικό της πρότυπο. Προσωπικά, διακρίνω τέσσερα επίπεδα:
- κανένα λάθος?
- Σφάλμα από την πλευρά του πελάτη.
- το λάθος είναι με το μέρος μας, δεν χάνουμε χρήματα, δεν αναλαμβάνουμε κινδύνους.
- Το λάθος είναι με το μέρος μας, χάνουμε χρήματα.
Επιτρέψτε μου να συνοψίσω. Πρέπει να προσπαθήσετε να δημιουργήσετε παρακολούθηση με βάση την επιχειρηματική λογική. Προσπαθήστε να παρακολουθείτε την ίδια την εφαρμογή και να λειτουργείτε με μετρήσεις όπως ο αριθμός των πωλήσεων, ο αριθμός των εγγραφών νέων χρηστών, ο αριθμός των ενεργών χρηστών και ούτω καθεξής.
Εάν ολόκληρη η επιχείρησή σας είναι ένα κουμπί στο πρόγραμμα περιήγησης, πρέπει να παρακολουθείτε εάν κάνει κλικ και λειτουργεί σωστά. Όλα τα υπόλοιπα δεν έχουν σημασία.
Εάν δεν το έχετε αυτό, μπορείτε να προσπαθήσετε να το βρείτε στα αρχεία καταγραφής εφαρμογών, στα αρχεία καταγραφής Nginx και ούτω καθεξής, όπως κάναμε. Θα πρέπει να είστε όσο το δυνατόν πιο κοντά στην εφαρμογή.
Οι μετρήσεις του λειτουργικού συστήματος είναι φυσικά σημαντικές, αλλά οι επιχειρήσεις δεν ενδιαφέρονται για αυτές, δεν πληρωνόμαστε για αυτές.
Πηγή: www.habr.com