Όσο πιο περίπλοκο είναι το σύστημα, τόσο περισσότερο κατακλύζεται από κάθε είδους ειδοποιήσεις. Και υπάρχει ανάγκη να αντιδράσουμε σε αυτές τις ίδιες ειδοποιήσεις, να τις συγκεντρώσουμε και να τις οπτικοποιήσουμε. Νομίζω ότι αυτή είναι μια κατάσταση που είναι γνωστή σε πολλούς σε σημείο νευρικότητας.
Η λύση που θα συζητηθεί δεν είναι η πιο απροσδόκητη, αλλά η αναζήτηση δεν επιστρέφει ένα πλήρες άρθρο σχετικά με αυτό το θέμα.
Ως εκ τούτου, αποφάσισα να μοιραστώ την εμπειρία της FunCorp και να μιλήσω για το πώς είναι δομημένη η διαδικασία καθήκοντος, ποιος καλεί, γιατί και πώς μπορείτε να τα δείτε όλα.
Τι είναι το PagerDuty;
Έτσι, για να λύσουμε όλα αυτά τα προβλήματα, αρχίσαμε να ψάχνουμε για ένα βολικό εργαλείο. Μετά από λίγο ψάξιμο, επιλέξαμε το PagerDuty. Το PD μας φάνηκε ως μια αρκετά πλήρης και συνοπτική λύση με μεγάλο αριθμό ενσωματώσεων και ρυθμίσεων. Πώς είναι αυτή;
Εν ολίγοις, το PagerDuty είναι μια πλατφόρμα επεξεργασίας συμβάντων που μπορεί να επεξεργαστεί εισερχόμενα περιστατικά μέσω διαφόρων ενσωματώσεων, να ορίσει εντολές υπηρεσίας και στη συνέχεια να ειδοποιήσει τον μηχανικό υπηρεσίας ανάλογα με το επίπεδο του συμβάντος (σε υψηλό επίπεδο - κλήση, σε χαμηλό επίπεδο - μια ώθηση από την εφαρμογή / SMS) .
Ποιος είναι ο αξιωματικός υπηρεσίας;
Αυτό είναι ίσως το πρώτο μέρος για να ξεκινήσετε τη ρύθμιση του PD.
Στη FunCorp, όπως και άλλες εταιρείες, υπάρχει τιμητική θέση αξιωματικού καθήκοντος. Μεταδίδεται από μηχανικό σε μηχανικό μία φορά την ημέρα. Υπάρχει μια λεγόμενη πρώτη και δεύτερη γραμμή απόκρισης σε μια ειδοποίηση από το PagerDuty. Ας υποθέσουμε ότι φτάσει μια ειδοποίηση υψηλής προτεραιότητας και εάν 10 λεπτά μετά την κλήση στον αξιωματικό υπηρεσίας από την πρώτη γραμμή δεν υπάρξει αντίδραση σε αυτήν (δηλαδή, δεν μεταφέρεται σε κατάσταση αναγνώρισης ή επίλυσης), η κλήση πηγαίνει στη δεύτερη μηχανικός υπηρεσίας. Αυτό διαμορφώνεται στο ίδιο το PagerDuty μέσω των πολιτικών κλιμάκωσης.
Εάν ο δεύτερος αξιωματικός υπηρεσίας δεν ανταποκριθεί, η ειδοποίηση επιστρέφει στο το κύριο στον αξιωματικό υπηρεσίας.
Έτσι, οποιαδήποτε εισερχόμενη ειδοποίηση υψηλής προτεραιότητας δεν μπορεί να παραμείνει χωρίς επεξεργασία.
Ας δούμε τώρα από πού μπορεί να προέρχονται τα περιστατικά.
Τι ενσωματώσεις χρησιμοποιούμε;
Η ΠΔ δέχεται πολλά διαφορετικά περιστατικά από διάφορες υπηρεσίες. Αυτή τη στιγμή έχουμε περίπου 25 τέτοιες υπηρεσίες και για να τις επεξεργαστούμε χρησιμοποιούμε κάποιες έτοιμες ενσωματώσεις.
- Προμηθέας
Το κύριο σύστημα συλλογής μετρήσεων είναι ο Προμηθέας. Έχουν ήδη γραφτεί πολλά για αυτό στο Habré, θα πω απλώς ότι έχουμε πολλά από αυτά για διαφορετικά περιβάλλοντα: το ένα συλλέγει μετρήσεις από εικονικές μηχανές και dockers, ένα άλλο από υπηρεσίες Amazon, το τρίτο από μηχανήματα υλικού. Η Telegraf χρησιμοποιείται κυρίως ως εξαγωγέας μετρήσεων.
- Ηλεκτρονική Διεύθυνση (Email)
Και εδώ, νομίζω, όλα είναι ξεκάθαρα από τον τίτλο. Αυτή η ενοποίηση χρησιμοποιείται για την αποστολή ειδοποιήσεων από ορισμένα σενάρια που εκτελούνται από το cron. Το PD σας δίνει μια συγκεκριμένη διεύθυνση στην οποία στέλνετε επιστολές. Κατά τη δημιουργία μιας υπηρεσίας με τέτοια ενοποίηση, μπορείτε να ορίσετε προτεραιότητες, με ποια σειρά θα υποβάλλονται σε επεξεργασία τα εισερχόμενα περιστατικά, πώς ακριβώς να δημιουργήσετε μια ειδοποίηση (για κάθε εισερχόμενη επιστολή, για μια εισερχόμενη επιστολή + έναν συγκεκριμένο κανόνα κ.λπ.).
- Χαλαρότητα
Κατά τη γνώμη μου, μια πολύ ενδιαφέρουσα ενσωμάτωση. Υπάρχουν φορές που κάτι συμβαίνει αλλά δεν καλύπτεται από περιστατικά. Επομένως, προσθέσαμε ενσωμάτωση από το Slack για να δημιουργήσουμε ένα περιστατικό. Δηλαδή, μπορείτε να γράψετε στο εταιρικό Slack /callofduty όλα αργούν και θα σπάσουν σύντομα και το ΠΔ θα το επεξεργαστεί και θα στείλει το περιστατικό στον εφημερεύοντα μηχανικό.
Κανουμε:
Βλέπουμε:
- API
Ενσωμάτωση HTTP. Στην πραγματικότητα, δεν υπάρχει τίποτα ιδιαίτερα ενδιαφέρον εδώ, απλώς ένα αίτημα POST με σώμα σε μορφή JSON. Για παράδειγμα, κάτι ενδιαφέρον: το χρησιμοποιούμε για εξωτερική παρακολούθηση χρησιμοποιώντας . Αυτή η υπηρεσία ελέγχει την προσβασιμότητα των τοποθεσιών μας από διάφορα μέρη του κόσμου. Στην περίπτωση που λάβουμε έναν μη αποδεκτό κωδικό απόκρισης (για παράδειγμα, 502), δημιουργείται ένα περιστατικό και στη συνέχεια όλα ακολουθούν την αλυσίδα που περιγράφεται παραπάνω. Το ίδιο το StatusCake έχει τη δυνατότητα να παρακολουθεί τις εσωτερικές διευθύνσεις URL, το πιστοποιητικό SSL ή τη λήξη του τομέα.
- ΔωρεάνNMS
Αυτό είναι ένα άλλο σύστημα παρακολούθησης, μπορείτε να διαβάσετε περισσότερα σχετικά με αυτό στον ιστότοπό τους . Με τη βοήθειά του, παρακολουθούμε τις διεπαφές δικτύου και το iDRAC από διακομιστές.
Υπήρχαν επίσης ενσωματώσεις όπως Datadog, CloudWatch. Μπορείτε να δείτε περισσότερα για το τι τους συνέβη .
Οραματισμός
Το κύριο σύστημα αναφοράς περιστατικών είναι το Slack. Όλα τα περιστατικά που έρχονται στο PD εγγράφονται σε μια ειδική συνομιλία και εάν αλλάξει η κατάστασή τους, αυτό εμφανίζεται επίσης στη συνομιλία.
Όταν προέκυψε η ευκαιρία να εμφανίσουμε χρήσιμα δεδομένα στις οθόνες των οθονών που κρέμονταν από την οροφή, ξαφνικά συνειδητοποιήσαμε ότι εμείς (στο τμήμα devops) δεν είχαμε τίποτα να εμφανίσουμε σε αυτές. Υπάρχει μια υπέροχη Grafana, αλλά δεν καλύπτει τα πάντα και οι εργαζόμενοι αντιδρούν σε ειδοποιήσεις, όχι σε γραφήματα.
Μετά από μια ενδελεχή αλλά ανεπιτυχή αναζήτηση στο GitHub για έναν συνοπτικό και ενημερωτικό "πίνακα" για το PD, αποφασίσαμε να γράψουμε το δικό μας - μόνο με ό,τι χρειαζόμασταν. Αν και αρχικά υπήρχε μια ιδέα να εμφανιστεί η ίδια η διεπαφή PD, φαινόταν ακόμα πιο άβολο.
Για να το γράψετε, το μόνο που χρειάζεται να κάνετε είναι να αποκτήσετε ένα κλειδί από ένα PD με δικαιώματα μόνο για ανάγνωση.
Και αυτό είναι που πήραμε:
Η οθόνη εμφανίζει τα τρέχοντα ανοιχτά συμβάντα, το όνομα του τρέχοντος μηχανικού σε υπηρεσία από το επιλεγμένο πρόγραμμα και την ώρα χωρίς συμβάν υψηλής προτεραιότητας (ο πίνακας με ένα συμβάν υψηλής προτεραιότητας θα τονιστεί με κόκκινο χρώμα).
.
Ως αποτέλεσμα, λάβαμε έναν βολικό πίνακα ελέγχου για την προβολή όλων των περιστατικών μας. Θα χαρώ αν κάποιοι από εσάς βρουν χρήσιμη την εμπειρία μας.
Πηγή: www.habr.com