Είναι νεκρή η παρακολούθηση; — Ζήτω η παρακολούθηση

Από το 2008, η εταιρεία μας ασχολείται κυρίως με τη διαχείριση υποδομής και την 400ωρη τεχνική υποστήριξη για έργα web: έχουμε περισσότερους από 15 πελάτες, που είναι περίπου το 15% του ρωσικού ηλεκτρονικού εμπορίου. Αντίστοιχα, υποστηρίζεται μια πολύ διαφορετική αρχιτεκτονική. Αν πέσει κάτι, είμαστε υποχρεωμένοι να το φτιάξουμε μέσα σε XNUMX λεπτά. Αλλά για να καταλάβετε ότι έχει συμβεί ένα ατύχημα, πρέπει να παρακολουθείτε το έργο και να ανταποκρίνεστε σε περιστατικά. Πώς να το κάνετε αυτό;

Πιστεύω ότι υπάρχει πρόβλημα στην οργάνωση ενός σωστού συστήματος παρακολούθησης. Αν δεν υπήρχε πρόβλημα, τότε η ομιλία μου θα συνίστατο σε μια διατριβή: «Παρακαλώ εγκαταστήστε το Prometheus + Grafana και τα πρόσθετα 1, 2, 3». Δυστυχώς, δεν λειτουργεί πια έτσι. Και το βασικό πρόβλημα είναι ότι όλοι συνεχίζουν να πιστεύουν σε κάτι που υπήρχε το 2008, όσον αφορά τα στοιχεία λογισμικού.

Σχετικά με την οργάνωση του συστήματος παρακολούθησης, θα τολμήσω να πω ότι... έργα με αρμόδια παρακολούθηση δεν υπάρχουν. Και η κατάσταση είναι τόσο κακή που αν πέσει κάτι, υπάρχει κίνδυνος να περάσει απαρατήρητο - άλλωστε όλοι είναι σίγουροι ότι «όλα παρακολουθούνται».
Ίσως όλα παρακολουθούνται. Αλλά πως?

Όλοι έχουμε συναντήσει μια ιστορία όπως η εξής: ένας συγκεκριμένος devops, ένας συγκεκριμένος διαχειριστής εργάζεται, μια ομάδα ανάπτυξης έρχεται σε αυτούς και λέει - "απελευθερωθήκαμε, τώρα παρακολουθήστε". Παρακολούθηση τι; Πως δουλεύει?

ΕΝΤΑΞΕΙ. Παρακολουθούμε τον παλιό τρόπο. Και αλλάζει ήδη, και αποδεικνύεται ότι παρακολουθήσατε την υπηρεσία Α, η οποία έγινε υπηρεσία Β, η οποία αλληλεπιδρά με την υπηρεσία Γ. Αλλά η ομάδα ανάπτυξης σας λέει: "Εγκαταστήστε το λογισμικό, θα πρέπει να παρακολουθεί τα πάντα!"

Τι άλλαξε λοιπόν; - Τα πάντα έχουν αλλάξει!

2008 Ολα ειναι καλά

Υπάρχουν μερικοί προγραμματιστές, ένας διακομιστής, ένας διακομιστής βάσης δεδομένων. Όλα πάνε από εδώ. Έχουμε κάποιες πληροφορίες, τοποθετούμε zabbix, Nagios, κάκτους. Και μετά ορίζουμε σαφείς ειδοποιήσεις στη CPU, στη λειτουργία του δίσκου και στο χώρο του δίσκου. Κάνουμε επίσης μερικούς μη αυτόματους ελέγχους για να διασφαλίσουμε ότι ο ιστότοπος ανταποκρίνεται και ότι οι παραγγελίες φτάνουν στη βάση δεδομένων. Και αυτό είναι - είμαστε περισσότερο ή λιγότερο προστατευμένοι.

Αν συγκρίνουμε τον όγκο της δουλειάς που έκανε τότε ο διαχειριστής για την παροχή παρακολούθησης, τότε το 98% ήταν αυτόματη: το άτομο που κάνει την παρακολούθηση πρέπει να καταλάβει πώς να εγκαταστήσει το Zabbix, πώς να το διαμορφώσει και να ρυθμίσει τις ειδοποιήσεις. Και 2% - για εξωτερικούς ελέγχους: ότι ο ιστότοπος ανταποκρίνεται και υποβάλλει αίτημα στη βάση δεδομένων, ότι έχουν φτάσει νέες παραγγελίες.

2010 Το φορτίο μεγαλώνει

Αρχίζουμε να κλιμακώνουμε τον ιστό, προσθέτοντας μια μηχανή αναζήτησης. Θέλουμε να βεβαιωθούμε ότι ο κατάλογος προϊόντων περιέχει όλα τα προϊόντα. Και αυτή η αναζήτηση προϊόντος λειτουργεί. Ότι η βάση δεδομένων λειτουργεί, ότι γίνονται παραγγελίες, ότι ο ιστότοπος ανταποκρίνεται εξωτερικά και ανταποκρίνεται από δύο διακομιστές και ο χρήστης δεν αποβάλλεται από τον ιστότοπο, ενώ επανεξισορροπείται σε άλλο διακομιστή κ.λπ. Υπάρχουν περισσότερες οντότητες.

Επιπλέον, η οντότητα που σχετίζεται με την υποδομή εξακολουθεί να παραμένει η μεγαλύτερη στο κεφάλι του διαχειριστή. Υπάρχει ακόμα μια ιδέα στο μυαλό μου ότι το άτομο που κάνει την παρακολούθηση είναι το άτομο που θα εγκαταστήσει το zabbix και θα μπορεί να το ρυθμίσει.

Αλλά ταυτόχρονα, εμφανίζεται δουλειά για τη διεξαγωγή εξωτερικών ελέγχων, για τη δημιουργία ενός συνόλου σεναρίων ερωτημάτων ευρετηρίου αναζήτησης, ενός συνόλου σεναρίων για να ελεγχθεί ότι η αναζήτηση αλλάζει κατά τη διαδικασία ευρετηρίασης, ένα σύνολο σεναρίων που ελέγχουν ότι τα αγαθά μεταφέρονται στο υπηρεσία παράδοσης κ.λπ. και ούτω καθεξής.

Σημείωση: Έγραψα «ένα σύνολο σεναρίων» 3 φορές. Δηλαδή, ο υπεύθυνος για την παρακολούθηση δεν είναι πλέον αυτός που απλώς εγκαθιστά το zabbix. Αυτό είναι ένα άτομο που αρχίζει να κωδικοποιεί. Όμως τίποτα δεν έχει αλλάξει ακόμα στο μυαλό της ομάδας.

Όμως ο κόσμος αλλάζει, γίνεται όλο και πιο περίπλοκος. Προστίθεται ένα επίπεδο εικονικοποίησης και πολλά νέα συστήματα. Αρχίζουν να αλληλεπιδρούν μεταξύ τους. Ποιος είπε ότι «μυρίζει μικροϋπηρεσίες;» Αλλά κάθε υπηρεσία εξακολουθεί να μοιάζει με ιστότοπο ξεχωριστά. Μπορούμε να απευθυνθούμε σε αυτό και να καταλάβουμε ότι παρέχει τις απαραίτητες πληροφορίες και λειτουργεί από μόνο του. Και αν είσαι διαχειριστής που εμπλέκεται συνεχώς σε ένα έργο που αναπτύσσεται εδώ και 5-7-10 χρόνια, αυτή η γνώση συσσωρεύεται: εμφανίζεται ένα νέο επίπεδο - το συνειδητοποίησες, ένα άλλο επίπεδο εμφανίζεται - το συνειδητοποίησες...

Σπάνια όμως κάποιος συνοδεύει ένα έργο για 10 χρόνια.

Το βιογραφικό του Monitoringman

Ας υποθέσουμε ότι ήρθατε σε μια νέα εκκίνηση που προσέλαβε αμέσως 20 προγραμματιστές, έγραψε 15 microservices και είστε ένας διαχειριστής που σας λένε: «Δημιουργήστε CI/CD. Σας παρακαλούμε." Έχετε φτιάξει CI/CD και ξαφνικά ακούτε: «Είναι δύσκολο για εμάς να δουλέψουμε με την παραγωγή σε έναν «κύβο», χωρίς να καταλαβαίνουμε πώς θα λειτουργήσει η εφαρμογή σε αυτό. Φτιάξτε μας ένα sandbox στον ίδιο «κύβο».
Φτιάχνεις ένα sandbox σε αυτόν τον κύβο. Σας λένε αμέσως: «Θέλουμε μια βάση δεδομένων σκηνής που ενημερώνεται κάθε μέρα από την παραγωγή, ώστε να καταλαβαίνουμε ότι λειτουργεί στη βάση δεδομένων, αλλά ταυτόχρονα να μην χαλάει τη βάση δεδομένων παραγωγής».

Ζεις σε όλα αυτά. Απομένουν 2 εβδομάδες πριν την κυκλοφορία, σου λένε: «Τώρα ας τα παρακολουθήσουμε όλα αυτά...» Δηλαδή. παρακολούθηση της υποδομής συμπλέγματος, παρακολούθηση της αρχιτεκτονικής μικροϋπηρεσιών, παρακολούθηση εργασιών με εξωτερικές υπηρεσίες...

Και οι συνάδελφοί μου βγάζουν το συνηθισμένο σχέδιο από το κεφάλι τους και λένε: «Λοιπόν, όλα είναι ξεκάθαρα εδώ! Εγκαταστήστε ένα πρόγραμμα που θα παρακολουθεί όλα αυτά." Ναι, ναι: Prometheus + Grafana + plugins.
Και προσθέτουν: «Έχετε δύο εβδομάδες, βεβαιωθείτε ότι όλα είναι ασφαλή».

Σε πολλά έργα που βλέπουμε, ένα άτομο διατίθεται για παρακολούθηση. Φανταστείτε ότι θέλουμε να προσλάβουμε ένα άτομο να κάνει παρακολούθηση για 2 εβδομάδες, και του γράφουμε ένα βιογραφικό. Τι δεξιότητες πρέπει να έχει αυτό το άτομο, δεδομένων όλων όσων έχουμε πει μέχρι τώρα;

• Πρέπει να κατανοήσει την παρακολούθηση και τις ιδιαιτερότητες της λειτουργίας της υποδομής σιδήρου.
• Πρέπει να κατανοήσει τις ιδιαιτερότητες της παρακολούθησης του Kubernetes (και όλοι θέλουν να πάνε στον "κύβο", επειδή μπορείτε να αφαιρέσετε τα πάντα, να κρύψετε, επειδή ο διαχειριστής θα ασχοληθεί με τα υπόλοιπα) - τον εαυτό του, την υποδομή του και να κατανοήσει πώς να παρακολουθεί τις εφαρμογές μέσα.
• Πρέπει να κατανοήσει ότι οι υπηρεσίες επικοινωνούν μεταξύ τους με ειδικούς τρόπους και να γνωρίζει τις ιδιαιτερότητες του τρόπου αλληλεπίδρασης των υπηρεσιών μεταξύ τους. Είναι πολύ πιθανό να δούμε ένα έργο όπου ορισμένες υπηρεσίες επικοινωνούν συγχρονισμένα, γιατί δεν υπάρχει άλλος τρόπος. Για παράδειγμα, το backend πηγαίνει μέσω REST, μέσω gRPC στην υπηρεσία καταλόγου, λαμβάνει μια λίστα προϊόντων και την επιστρέφει. Δεν μπορείτε να περιμένετε εδώ. Και με άλλες υπηρεσίες λειτουργεί ασύγχρονα. Μεταφορά της παραγγελίας στην υπηρεσία παράδοσης, αποστολή επιστολής κ.λπ.
  Μάλλον έχετε ήδη κολυμπήσει από όλα αυτά; Και ο διαχειριστής, που πρέπει να το παρακολουθεί, μπερδεύτηκε ακόμη περισσότερο.
• Πρέπει να μπορεί να προγραμματίζει και να προγραμματίζει σωστά - καθώς η δουλειά γίνεται όλο και περισσότερο.
• Πρέπει επομένως να δημιουργήσει μια στρατηγική από τη δημιουργημένη υπηρεσία για να κατανοήσει πώς να την παρακολουθεί συγκεκριμένα. Χρειάζεται κατανόηση της αρχιτεκτονικής του έργου και της ανάπτυξής του + κατανόηση των τεχνολογιών που χρησιμοποιούνται στην ανάπτυξη.

Ας θυμηθούμε μια απολύτως φυσιολογική περίπτωση: κάποιες υπηρεσίες είναι σε PHP, κάποιες υπηρεσίες είναι στο Go, κάποιες υπηρεσίες είναι σε JS. Κατά κάποιο τρόπο συνεργάζονται μεταξύ τους. Από εδώ προέρχεται ο όρος "microservice": υπάρχουν τόσα πολλά μεμονωμένα συστήματα που οι προγραμματιστές δεν μπορούν να κατανοήσουν το έργο ως σύνολο. Ένα μέρος της ομάδας γράφει υπηρεσίες σε JS που λειτουργούν μόνες τους και δεν γνωρίζουν πώς λειτουργεί το υπόλοιπο σύστημα. Το άλλο μέρος γράφει υπηρεσίες σε Python και δεν παρεμβαίνει στον τρόπο λειτουργίας των άλλων υπηρεσιών· είναι απομονωμένες στη δική τους περιοχή. Το τρίτο είναι υπηρεσίες γραφής σε PHP ή κάτι άλλο.
Όλα αυτά τα 20 άτομα χωρίζονται σε 15 υπηρεσίες, και υπάρχει μόνο ένας διαχειριστής που πρέπει να τα καταλάβει όλα αυτά. Να σταματήσει! Απλώς χωρίσαμε το σύστημα σε 15 μικροϋπηρεσίες επειδή 20 άτομα δεν μπορούν να καταλάβουν ολόκληρο το σύστημα.

Αλλά πρέπει κάπως να παρακολουθείται...

Ποιο είναι το αποτέλεσμα; Ως αποτέλεσμα, υπάρχει ένα άτομο που βρίσκει όλα όσα δεν μπορεί να καταλάβει ολόκληρη η ομάδα προγραμματιστών και ταυτόχρονα πρέπει επίσης να γνωρίζει και να μπορεί να κάνει αυτό που υποδείξαμε παραπάνω - υποδομή υλικού, υποδομή Kubernetes κ.λπ.

Τι να πω... Χιούστον, έχουμε προβλήματα.

Η παρακολούθηση ενός σύγχρονου έργου λογισμικού είναι ένα έργο λογισμικού από μόνο του

Από την ψευδή πεποίθηση ότι η παρακολούθηση είναι λογισμικό, αναπτύσσουμε μια πίστη στα θαύματα. Αλλά θαύματα, δυστυχώς, δεν γίνονται. Δεν μπορείτε να εγκαταστήσετε το zabbix και να περιμένετε ότι όλα θα λειτουργήσουν. Δεν έχει νόημα να εγκαταστήσετε το Grafana και να ελπίζετε ότι όλα θα πάνε καλά. Ο περισσότερος χρόνος θα αφιερωθεί στην οργάνωση ελέγχων της λειτουργίας των υπηρεσιών και της αλληλεπίδρασής τους μεταξύ τους, ελέγχοντας πώς λειτουργούν τα εξωτερικά συστήματα. Στην πραγματικότητα, το 90% του χρόνου δεν θα αφιερωθεί στη συγγραφή σεναρίων, αλλά στην ανάπτυξη λογισμικού. Και θα πρέπει να το χειρίζεται μια ομάδα που κατανοεί τη δουλειά του έργου.
Εάν σε αυτήν την κατάσταση ένα άτομο ριχτεί στην παρακολούθηση, τότε θα συμβεί καταστροφή. Αυτό που συμβαίνει παντού.

Για παράδειγμα, υπάρχουν αρκετές υπηρεσίες που επικοινωνούν μεταξύ τους μέσω του Κάφκα. Η παραγγελία έφτασε, στείλαμε μήνυμα για την παραγγελία στον Κάφκα. Υπάρχει μια υπηρεσία που ακούει πληροφορίες σχετικά με την παραγγελία και αποστέλλει τα εμπορεύματα. Υπάρχει μια υπηρεσία που ακούει πληροφορίες σχετικά με την παραγγελία και στέλνει μια επιστολή στον χρήστη. Και μετά εμφανίζονται ένα σωρό περισσότερες υπηρεσίες και αρχίζουμε να μπερδευόμαστε.

Και αν το δώσετε επίσης στον διαχειριστή και τους προγραμματιστές στο στάδιο που απομένει λίγος χρόνος πριν την κυκλοφορία, το άτομο θα πρέπει να κατανοήσει ολόκληρο αυτό το πρωτόκολλο. Εκείνοι. Ένα έργο αυτής της κλίμακας απαιτεί σημαντικό χρόνο και αυτό θα πρέπει να ληφθεί υπόψη στην ανάπτυξη του συστήματος.
Πολύ συχνά όμως, ειδικά στις startups, βλέπουμε πώς η παρακολούθηση αναβάλλεται για αργότερα. «Τώρα θα κάνουμε ένα Proof of Concept, θα εκτοξευτούμε με αυτό, θα το αφήσουμε να πέσει - είμαστε έτοιμοι να θυσιασθούμε. Και μετά θα τα παρακολουθήσουμε όλα». Όταν (ή εάν) το έργο αρχίσει να κερδίζει χρήματα, η επιχείρηση θέλει να προσθέσει ακόμα περισσότερες δυνατότητες - επειδή έχει αρχίσει να λειτουργεί, επομένως πρέπει να αναπτυχθεί περαιτέρω! Και βρίσκεστε στο σημείο όπου πρέπει πρώτα να παρακολουθείτε όλα τα προηγούμενα, κάτι που δεν παίρνει το 1% του χρόνου, αλλά πολύ περισσότερο. Και παρεμπιπτόντως, θα χρειαστούν προγραμματιστές για την παρακολούθηση και είναι πιο εύκολο να τους αφήσουμε να εργαστούν σε νέες δυνατότητες. Ως αποτέλεσμα, γράφονται νέες δυνατότητες, τα πάντα μπερδεύονται και βρίσκεστε σε ένα ατελείωτο αδιέξοδο.

Λοιπόν, πώς να παρακολουθήσετε ένα έργο ξεκινώντας από την αρχή και τι να κάνετε εάν λάβετε ένα έργο που πρέπει να παρακολουθηθεί, αλλά δεν ξέρετε από πού να ξεκινήσετε;

Πρώτα, πρέπει να προγραμματίσετε.

Λυρική παρέκβαση: πολύ συχνά ξεκινούν με την παρακολούθηση της υποδομής. Για παράδειγμα, έχουμε Kubernetes. Ας ξεκινήσουμε με την εγκατάσταση του Prometheus με το Grafana, την εγκατάσταση πρόσθετων για την παρακολούθηση του «κύβου». Όχι μόνο οι προγραμματιστές, αλλά και οι διαχειριστές έχουν την ατυχή πρακτική: «Θα εγκαταστήσουμε αυτό το πρόσθετο, αλλά το πρόσθετο πιθανότατα ξέρει πώς να το κάνει». Στους ανθρώπους αρέσει να ξεκινούν με τα απλά και απλά, παρά με τις σημαντικές ενέργειες. Και η παρακολούθηση της υποδομής είναι εύκολη.

Πρώτα, αποφασίστε τι και πώς θέλετε να παρακολουθήσετε και, στη συνέχεια, επιλέξτε ένα εργαλείο, επειδή οι άλλοι δεν μπορούν να σκεφτούν για εσάς. Και θα έπρεπε; Άλλοι άνθρωποι σκέφτηκαν μόνοι τους για ένα καθολικό σύστημα - ή δεν σκέφτηκαν καθόλου όταν γράφτηκε αυτό το πρόσθετο. Και το ότι αυτό το πρόσθετο έχει 5 χιλιάδες χρήστες δεν σημαίνει ότι είναι χρήσιμο. Ίσως να γίνετε ο 5001ος απλώς και μόνο επειδή υπήρχαν ήδη 5000 άτομα εκεί πριν.

Εάν αρχίσετε να παρακολουθείτε την υποδομή και το backend της εφαρμογής σας σταματήσει να ανταποκρίνεται, όλοι οι χρήστες θα χάσουν τη σύνδεση με την εφαρμογή για κινητά. Θα εμφανιστεί ένα σφάλμα. Θα έρθουν σε εσάς και θα σας πουν "Η εφαρμογή δεν λειτουργεί, τι κάνετε εδώ;" - «Παρακολουθούμε». — "Πώς παρακολουθείτε εάν δεν βλέπετε ότι η εφαρμογή δεν λειτουργεί;"

1. Πιστεύω ότι πρέπει να ξεκινήσετε την παρακολούθηση ακριβώς από το σημείο εισόδου του χρήστη. Εάν ο χρήστης δεν δει ότι η εφαρμογή λειτουργεί, αυτό είναι, είναι αποτυχία. Και το σύστημα παρακολούθησης θα πρέπει πρώτα να προειδοποιήσει για αυτό.
2. Και μόνο τότε μπορούμε να παρακολουθούμε τις υποδομές. Ή κάντε το παράλληλα. Είναι πιο εύκολο με την υποδομή - εδώ μπορούμε τελικά να εγκαταστήσουμε το zabbix.
3. Και τώρα πρέπει να πάτε στις ρίζες της εφαρμογής για να καταλάβετε πού δεν λειτουργούν τα πράγματα.

Η βασική μου ιδέα είναι ότι η παρακολούθηση πρέπει να πηγαίνει παράλληλα με τη διαδικασία ανάπτυξης. Εάν αποσπάσετε την προσοχή της ομάδας παρακολούθησης για άλλες εργασίες (δημιουργία CI/CD, sandboxing, αναδιοργάνωση υποδομής), η παρακολούθηση θα αρχίσει να καθυστερεί και μπορεί να μην προλάβετε ποτέ την ανάπτυξη (ή αργά ή γρήγορα θα πρέπει να τη σταματήσετε).

Όλα ανά επίπεδα

Έτσι βλέπω την οργάνωση ενός συστήματος παρακολούθησης.

1) Επίπεδο εφαρμογής:

• παρακολούθηση της επιχειρηματικής λογικής της εφαρμογής.
• παρακολούθηση των μετρήσεων υγείας των υπηρεσιών·
• παρακολούθηση της ολοκλήρωσης.

2) Επίπεδο υποδομής:

• παρακολούθηση επιπέδου ενορχήστρωσης.
• παρακολούθηση λογισμικού συστήματος·
• παρακολούθηση στάθμης σιδήρου.

3) Και πάλι το επίπεδο εφαρμογής - αλλά ως προϊόν μηχανικής:

• συλλογή και παρακολούθηση αρχείων καταγραφής εφαρμογών.
• APM;
• ιχνηλασία.

4) Προειδοποίηση:

• οργάνωση ενός συστήματος προειδοποίησης·
• οργάνωση ενός συστήματος υπηρεσίας·
• οργάνωση μιας «βάσης γνώσεων» και ροής εργασιών για την επεξεργασία περιστατικών.

Είναι σημαντικό: φτάνουμε σε συναγερμό όχι μετά, αλλά αμέσως! Δεν χρειάζεται να ξεκινήσει η παρακολούθηση και «κάπως αργότερα» να καταλάβουμε ποιος θα λαμβάνει ειδοποιήσεις. Σε τελική ανάλυση, ποιο είναι το καθήκον της παρακολούθησης: να κατανοήσει σε ποιο σημείο του συστήματος κάτι δεν λειτουργεί σωστά και να ενημερώσει τους κατάλληλους ανθρώπους σχετικά με αυτό. Εάν το αφήσετε αυτό μέχρι το τέλος, τότε οι σωστοί άνθρωποι θα ξέρουν ότι κάτι δεν πάει καλά μόνο φωνάζοντας «τίποτα δεν λειτουργεί για εμάς».

Επίπεδο Εφαρμογής - Παρακολούθηση Επιχειρηματικής Λογικής

Εδώ μιλάμε για έλεγχο του ίδιου του γεγονότος ότι η εφαρμογή λειτουργεί για τον χρήστη.

Αυτό το επίπεδο πρέπει να γίνει κατά τη φάση ανάπτυξης. Για παράδειγμα, έχουμε έναν Prometheus υπό όρους: πηγαίνει στον διακομιστή που κάνει τους ελέγχους, τραβάει το τελικό σημείο και το τελικό σημείο πηγαίνει και ελέγχει το API.

Όταν τους ζητείται συχνά να παρακολουθούν την αρχική σελίδα για να βεβαιωθούν ότι ο ιστότοπος λειτουργεί, οι προγραμματιστές δίνουν μια λαβή που μπορεί να τραβήξει κάθε φορά που χρειάζεται για να βεβαιωθεί ότι το API λειτουργεί. Και οι προγραμματιστές αυτή τη στιγμή εξακολουθούν να παίρνουν και να γράφουν /api/test/helloworld
Ο μόνος τρόπος για να βεβαιωθείτε ότι όλα λειτουργούν; - Οχι!

• Η δημιουργία τέτοιων επιταγών είναι ουσιαστικά καθήκον των προγραμματιστών. Οι δοκιμές μονάδων πρέπει να γράφονται από τους προγραμματιστές που γράφουν τον κώδικα. Επειδή αν το διαρρεύσετε στον διαχειριστή, "Φίλε, εδώ είναι μια λίστα με τα πρωτόκολλα API και για τις 25 λειτουργίες, παρακαλώ παρακολουθήστε τα πάντα!" - τίποτα δεν θα βγει.
• Εάν εκτυπώσετε "γεια κόσμο", κανείς δεν θα μάθει ποτέ ότι το API πρέπει και λειτουργεί. Κάθε αλλαγή API πρέπει να οδηγεί σε αλλαγή στους ελέγχους.
• Εάν έχετε ήδη ένα τέτοιο πρόβλημα, σταματήστε τις δυνατότητες και εκχωρήστε προγραμματιστές που θα γράψουν αυτούς τους ελέγχους ή αποδεχτείτε τις απώλειες, αποδεχτείτε ότι τίποτα δεν έχει ελεγχθεί και θα αποτύχει.

Τεχνικές συμβουλές:

• Φροντίστε να οργανώσετε έναν εξωτερικό διακομιστή για την οργάνωση των ελέγχων - πρέπει να είστε βέβαιοι ότι το έργο σας είναι προσβάσιμο στον έξω κόσμο.
• Οργανώστε τους ελέγχους σε ολόκληρο το πρωτόκολλο API, όχι μόνο σε μεμονωμένα τελικά σημεία.
• Δημιουργήστε ένα τελικό σημείο προμηθέας με τα αποτελέσματα της δοκιμής.

Επίπεδο εφαρμογής - παρακολούθηση μετρήσεων υγείας

Τώρα μιλάμε για εξωτερικές μετρήσεις υγείας των υπηρεσιών.

Αποφασίσαμε να παρακολουθούμε όλες τις «λαβές» της εφαρμογής χρησιμοποιώντας εξωτερικούς ελέγχους, τους οποίους καλούμε από ένα εξωτερικό σύστημα παρακολούθησης. Αλλά αυτές είναι οι «λαβές» που «βλέπει» ο χρήστης. Θέλουμε να είμαστε σίγουροι ότι οι ίδιες οι υπηρεσίες μας λειτουργούν. Υπάρχει μια καλύτερη ιστορία εδώ: το K8s έχει υγειονομικούς ελέγχους, έτσι ώστε τουλάχιστον ο ίδιος ο «κύβος» να μπορεί να πειστεί ότι η υπηρεσία λειτουργεί. Αλλά οι μισές από τις επιταγές που έχω δει είναι με την ίδια τυπωμένη φράση «γεια σου κόσμο». Εκείνοι. Έτσι, τραβάει μία φορά μετά την ανάπτυξη, απάντησε ότι όλα είναι καλά - αυτό είναι όλο. Και η υπηρεσία, εάν παρέχει το δικό της API, έχει έναν τεράστιο αριθμό σημείων εισόδου για το ίδιο API, το οποίο πρέπει επίσης να παρακολουθείται, γιατί θέλουμε να γνωρίζουμε ότι λειτουργεί. Και το παρακολουθούμε ήδη μέσα.

Πώς να το εφαρμόσετε σωστά τεχνικά: κάθε υπηρεσία εκθέτει ένα τελικό σημείο σχετικά με την τρέχουσα απόδοσή της και στα γραφήματα του Grafana (ή οποιασδήποτε άλλης εφαρμογής) βλέπουμε την κατάσταση όλων των υπηρεσιών.

• Κάθε αλλαγή API πρέπει να οδηγεί σε αλλαγή στους ελέγχους.
• Δημιουργήστε μια νέα υπηρεσία αμέσως με μετρήσεις υγείας.
• Ένας διαχειριστής μπορεί να έρθει στους προγραμματιστές και να ρωτήσει "προσθέστε μου μερικές λειτουργίες, ώστε να καταλαβαίνω τα πάντα και να προσθέσω πληροφορίες σχετικά με αυτό στο σύστημα παρακολούθησης". Αλλά οι προγραμματιστές συνήθως απαντούν: "Δεν θα προσθέσουμε τίποτα δύο εβδομάδες πριν από την κυκλοφορία."
  Ενημερώστε τους υπεύθυνους ανάπτυξης ότι θα υπάρξουν τέτοιες απώλειες, ενημερώστε και τη διοίκηση των υπευθύνων ανάπτυξης. Γιατί όταν όλα πέφτουν, κάποιος θα εξακολουθεί να τηλεφωνεί και να απαιτεί να παρακολουθεί τη «συνεχώς πέφτει υπηρεσία» (γ)
• Παρεμπιπτόντως, εκχωρήστε προγραμματιστές για να γράφουν προσθήκες για το Grafana - αυτό θα είναι μια καλή βοήθεια για τους διαχειριστές.

Επίπεδο Εφαρμογής - Παρακολούθηση Ενσωμάτωσης

Η παρακολούθηση ολοκλήρωσης επικεντρώνεται στην παρακολούθηση των επικοινωνιών μεταξύ κρίσιμων για τις επιχειρήσεις συστημάτων.

Για παράδειγμα, υπάρχουν 15 υπηρεσίες που επικοινωνούν μεταξύ τους. Αυτοί δεν είναι πλέον ξεχωριστοί ιστότοποι. Εκείνοι. δεν μπορούμε να τραβήξουμε την υπηρεσία μόνοι μας, να πάρουμε το /helloworld και να καταλάβουμε ότι η υπηρεσία εκτελείται. Επειδή η υπηρεσία ιστού παραγγελίας πρέπει να στείλει πληροφορίες σχετικά με την παραγγελία στο λεωφορείο - από το λεωφορείο, η υπηρεσία αποθήκης πρέπει να λάβει αυτό το μήνυμα και να συνεργαστεί περαιτέρω με αυτό. Και η υπηρεσία διανομής email πρέπει να το επεξεργαστεί με κάποιο τρόπο περαιτέρω, κ.λπ.

Κατά συνέπεια, δεν μπορούμε να καταλάβουμε, ποντάροντας σε κάθε μεμονωμένη υπηρεσία, ότι όλα λειτουργούν. Γιατί έχουμε ένα συγκεκριμένο λεωφορείο μέσω του οποίου όλα επικοινωνούν και αλληλεπιδρούν.
Επομένως, αυτό το στάδιο θα πρέπει να σηματοδοτεί το στάδιο δοκιμής των υπηρεσιών για αλληλεπίδραση με άλλες υπηρεσίες. Είναι αδύνατο να οργανωθεί η παρακολούθηση της επικοινωνίας παρακολουθώντας τον μεσίτη μηνυμάτων. Εάν υπάρχει μια υπηρεσία που εκδίδει δεδομένα και μια υπηρεσία που τα λαμβάνει, κατά την παρακολούθηση του μεσίτη θα δούμε μόνο δεδομένα που πετούν από πλευρά σε πλευρά. Ακόμα κι αν καταφέραμε με κάποιο τρόπο να παρακολουθήσουμε την αλληλεπίδραση αυτών των δεδομένων εσωτερικά - ότι ένας συγκεκριμένος παραγωγός δημοσιεύει τα δεδομένα, κάποιος τα διαβάζει, αυτή η ροή συνεχίζει να πηγαίνει στον Κάφκα - αυτό και πάλι δεν θα μας δώσει πληροφορίες εάν μια υπηρεσία έστειλε το μήνυμα σε μία έκδοση , αλλά η άλλη υπηρεσία δεν περίμενε αυτή την έκδοση και την παρέλειψε. Δεν θα το μάθουμε αυτό, καθώς οι υπηρεσίες θα μας πουν ότι όλα λειτουργούν.

Τι προτείνω να κάνετε:

• Για σύγχρονη επικοινωνία: το τελικό σημείο υποβάλλει αιτήματα σε σχετικές υπηρεσίες. Εκείνοι. παίρνουμε αυτό το τελικό σημείο, τραβάμε ένα σενάριο μέσα στην υπηρεσία, το οποίο πηγαίνει σε όλα τα σημεία και λέει "μπορώ να τραβήξω εκεί και να τραβήξω εκεί, μπορώ να τραβήξω εκεί..."
• Για ασύγχρονη επικοινωνία: εισερχόμενα μηνύματα - το τελικό σημείο ελέγχει το δίαυλο για δοκιμαστικά μηνύματα και εμφανίζει την κατάσταση επεξεργασίας.
• Για ασύγχρονη επικοινωνία: εξερχόμενα μηνύματα - το τελικό σημείο στέλνει δοκιμαστικά μηνύματα στο δίαυλο.

Όπως συμβαίνει συνήθως: έχουμε μια υπηρεσία που ρίχνει δεδομένα στο δίαυλο. Ερχόμαστε σε αυτήν την υπηρεσία και σας ζητάμε να μας πείτε για την υγεία της ενσωμάτωσής της. Και αν η υπηρεσία χρειάζεται να παράγει ένα μήνυμα κάπου περαιτέρω (WebApp), τότε θα παράγει αυτό το δοκιμαστικό μήνυμα. Και αν εκτελούμε μια υπηρεσία στην πλευρά της Επεξεργασίας Παραγγελιών, αυτή πρώτα δημοσιεύει ό,τι μπορεί να δημοσιεύσει ανεξάρτητα, και αν υπάρχουν κάποια εξαρτημένα πράγματα, τότε διαβάζει ένα σύνολο δοκιμαστικών μηνυμάτων από το δίαυλο, καταλαβαίνει ότι μπορεί να τα επεξεργαστεί, να τα αναφέρει και , αν χρειαστεί, δημοσιεύστε τα περαιτέρω, και για αυτό λέει - όλα είναι εντάξει, είμαι ζωντανός.

Πολύ συχνά ακούμε την ερώτηση "πώς μπορούμε να το δοκιμάσουμε σε δεδομένα μάχης;" Για παράδειγμα, μιλάμε για την ίδια υπηρεσία παραγγελιών. Η παραγγελία στέλνει μηνύματα στην αποθήκη όπου διαγράφονται τα αγαθά: δεν μπορούμε να το δοκιμάσουμε σε δεδομένα μάχης, γιατί "τα αγαθά μου θα διαγραφούν!" Λύση: Σχεδιάστε ολόκληρο το τεστ από την αρχή. Έχετε επίσης μοναδιαίες δοκιμές που κάνουν κοροϊδίες. Κάντε το λοιπόν σε βαθύτερο επίπεδο όπου έχετε ένα κανάλι επικοινωνίας που δεν βλάπτει τη λειτουργία της επιχείρησης.

Στρώμα υποδομής

Η παρακολούθηση της υποδομής είναι κάτι που θεωρείται από καιρό ως η ίδια η παρακολούθηση.

• Η παρακολούθηση της υποδομής μπορεί και πρέπει να ξεκινήσει ως χωριστή διαδικασία.
• Δεν πρέπει να ξεκινήσετε με την παρακολούθηση υποδομής σε ένα έργο που βρίσκεται σε εξέλιξη, ακόμα κι αν το θέλετε πραγματικά. Αυτό είναι πόνος για όλους τους devop. "Πρώτα θα παρακολουθήσω το σύμπλεγμα, θα παρακολουθήσω την υποδομή" - δηλ. Πρώτον, θα παρακολουθεί τι βρίσκεται παρακάτω, αλλά δεν θα μπει στην εφαρμογή. Γιατί η εφαρμογή είναι κάτι ακατανόητο για devops. Του διέρρευσε και δεν καταλαβαίνει πώς λειτουργεί. Και καταλαβαίνει την υποδομή και ξεκινά από αυτήν. Αλλά όχι - πρέπει πάντα να παρακολουθείτε πρώτα την εφαρμογή.
• Μην υπερβάλλετε με τον αριθμό των ειδοποιήσεων. Λαμβάνοντας υπόψη την πολυπλοκότητα των σύγχρονων συστημάτων, οι ειδοποιήσεις πετούν συνεχώς και πρέπει να ζήσετε με κάποιο τρόπο με αυτό το μάτσο ειδοποιήσεων. Και ο εφημερεύων, έχοντας δει εκατό από τις επόμενες ειδοποιήσεις, θα αποφασίσει «Δεν θέλω να το σκέφτομαι». Οι ειδοποιήσεις θα πρέπει να ειδοποιούν μόνο για κρίσιμα πράγματα.

Επίπεδο εφαρμογής ως επιχειρηματική μονάδα

Βασικά σημεία:

• ΜΕΓΑΛΗ ΕΛΑΦΟΣ. Αυτό είναι το βιομηχανικό πρότυπο. Εάν για κάποιο λόγο δεν συγκεντρώνετε αρχεία καταγραφής, ξεκινήστε να το κάνετε αμέσως.
• APM. Εξωτερικά APM ως τρόπος για γρήγορο κλείσιμο της παρακολούθησης εφαρμογών (NewRelic, BlackFire, Datadog). Μπορείτε να εγκαταστήσετε αυτό το πράγμα προσωρινά για να καταλάβετε τουλάχιστον με κάποιο τρόπο τι συμβαίνει με εσάς.
• Ιχνηλασία. Σε δεκάδες μικροϋπηρεσίες, πρέπει να εντοπίσετε τα πάντα, γιατί το αίτημα δεν ζει πλέον από μόνο του. Είναι πολύ δύσκολο να προστεθεί αργότερα, επομένως είναι καλύτερο να προγραμματίσετε αμέσως την ανίχνευση στην ανάπτυξη - αυτό είναι το έργο και η χρησιμότητα των προγραμματιστών. Αν δεν το έχετε εφαρμόσει ακόμα, εφαρμόστε το! Δείτε Jaeger/Zipkin

Συναγερμός

• Οργάνωση συστήματος ειδοποιήσεων: σε συνθήκες παρακολούθησης πολλών πραγμάτων, θα πρέπει να υπάρχει ένα ενοποιημένο σύστημα αποστολής ειδοποιήσεων. Μπορείτε στα Γραφάνα. Στη Δύση, όλοι χρησιμοποιούν το PagerDuty. Οι ειδοποιήσεις πρέπει να είναι σαφείς (π.χ. από πού προέρχονται...). Και καλό είναι να ελέγχετε ότι λαμβάνονται καθόλου ειδοποιήσεις
• Οργάνωση ενός συστήματος υπηρεσίας: ειδοποιήσεις δεν πρέπει να αποστέλλονται σε όλους (είτε θα αντιδρούν όλοι σε ένα πλήθος, είτε κανείς δεν θα αντιδράσει). Οι προγραμματιστές πρέπει επίσης να είναι σε ετοιμότητα: φροντίστε να ορίσετε τομείς ευθύνης, να κάνετε σαφείς οδηγίες και να γράψετε σε αυτό ποιον ακριβώς να καλέσουν τη Δευτέρα και την Τετάρτη και ποιον να καλέσουν την Τρίτη και την Παρασκευή (διαφορετικά δεν θα καλέσουν κανέναν ακόμη και στο περίπτωση μεγάλου προβλήματος - θα φοβούνται να σας ξυπνήσουν ή να ενοχλήσουν: οι άνθρωποι γενικά δεν τους αρέσει να τηλεφωνούν και να ξυπνούν άλλους ανθρώπους, ειδικά τη νύχτα). Και εξηγήστε ότι το να ζητάτε βοήθεια δεν είναι δείκτης ανικανότητας («Ζητώ βοήθεια, αυτό σημαίνει ότι είμαι κακός εργαζόμενος»), ενθαρρύνετε τα αιτήματα για βοήθεια.
• Οργάνωση μιας «βάσης γνώσης» και ροής εργασιών για την επεξεργασία του περιστατικού: για κάθε σοβαρό περιστατικό, θα πρέπει να προγραμματίζεται μια νεκροψία και ως προσωρινό μέτρο, οι ενέργειες που θα επιλύσουν το συμβάν θα πρέπει να καταγράφονται. Και κάντε το ότι οι επαναλαμβανόμενες ειδοποιήσεις είναι αμαρτία. πρέπει να διορθωθούν σε εργασίες κώδικα ή υποδομής.

Στοίβα τεχνολογίας

Ας φανταστούμε ότι η στοίβα μας είναι η εξής:

• συλλογή δεδομένων - Prometheus + Grafana;
• ανάλυση καταγραφής - ELK;
• για APM ή Tracing - Jaeger (Zipkin).

Η επιλογή των επιλογών δεν είναι κρίσιμη. Γιατί αν στην αρχή καταλάβατε πώς να παρακολουθείτε το σύστημα και γράψατε ένα σχέδιο, τότε αρχίζετε να επιλέγετε εργαλεία που ταιριάζουν στις απαιτήσεις σας. Το ερώτημα είναι τι επιλέξατε να παρακολουθήσετε αρχικά. Γιατί ίσως το εργαλείο που επιλέξατε στην αρχή να μην ταιριάζει καθόλου στις απαιτήσεις σας.

Μερικά τεχνικά σημεία που βλέπω παντού τον τελευταίο καιρό:

Ο Προμηθέας σπρώχνεται μέσα στο Kubernetes - ποιος το σκέφτηκε;! Αν το σύμπλεγμα σας καταρρεύσει, τι θα κάνετε; Εάν έχετε ένα σύνθετο σύμπλεγμα μέσα, τότε θα πρέπει να υπάρχει κάποιο είδος συστήματος παρακολούθησης μέσα στο σύμπλεγμα και κάποιο έξω, το οποίο θα συλλέγει δεδομένα από το εσωτερικό του συμπλέγματος.

Μέσα στο σύμπλεγμα συλλέγουμε κορμούς και οτιδήποτε άλλο. Αλλά το σύστημα παρακολούθησης πρέπει να είναι έξω. Πολύ συχνά, σε ένα σύμπλεγμα όπου έχει εγκατασταθεί εσωτερικά ο Promtheus, υπάρχουν και συστήματα που πραγματοποιούν εξωτερικούς ελέγχους της λειτουργίας του ιστότοπου. Τι γίνεται αν οι συνδέσεις σας με τον έξω κόσμο έχουν πέσει και η εφαρμογή δεν λειτουργεί; Αποδεικνύεται ότι όλα είναι καλά μέσα, αλλά δεν διευκολύνει τα πράγματα για τους χρήστες.

Ευρήματα

• Η παρακολούθηση της ανάπτυξης δεν είναι η εγκατάσταση βοηθητικών προγραμμάτων, αλλά η ανάπτυξη ενός προϊόντος λογισμικού. Το 98% της σημερινής παρακολούθησης είναι κωδικοποίηση. Κωδικοποίηση σε υπηρεσίες, κωδικοποίηση εξωτερικών ελέγχων, έλεγχος εξωτερικών υπηρεσιών και αυτό είναι όλο.
• Μην σπαταλάτε τον χρόνο των προγραμματιστών σας στην παρακολούθηση: μπορεί να διαρκέσει έως και το 30% της δουλειάς τους, αλλά αξίζει τον κόπο.
• Devops, μην ανησυχείτε ότι δεν μπορείτε να παρακολουθήσετε κάτι, γιατί ορισμένα πράγματα είναι εντελώς διαφορετικός τρόπος σκέψης. Δεν ήσουν προγραμματιστής και η παρακολούθηση της εργασίας είναι ακριβώς η δουλειά τους.
• Εάν το έργο εκτελείται ήδη και δεν παρακολουθείται (και είστε διαχειριστής), διαθέστε πόρους για παρακολούθηση.
• Εάν το προϊόν είναι ήδη σε παραγωγή και είστε ένας devop στον οποίο είπαν να "ρυθμίσετε την παρακολούθηση" - προσπαθήστε να εξηγήσετε στη διοίκηση για τι έγραψα όλα αυτά.

Αυτή είναι μια εκτεταμένη έκδοση της έκθεσης στο συνέδριο Saint Highload++.

Εάν ενδιαφέρεστε για τις ιδέες και τις σκέψεις μου για αυτό και σχετικά θέματα, τότε μπορείτε εδώ διαβάστε το κανάλι ????

Πηγή: www.habr.com