Σκεφτείτε την έννοια της παρακολούθησης Kubernetes, εξοικειωθείτε με το εργαλείο Prometheus και μιλήστε για ειδοποίηση.
Το θέμα της παρακολούθησης είναι ογκώδες, δεν μπορεί να αποσυναρμολογηθεί σε ένα άρθρο. Σκοπός αυτού του κειμένου είναι να παρέχει μια επισκόπηση των εργαλείων, των εννοιών και των προσεγγίσεων.
Το υλικό του άρθρου είναι μια συμπίεση από . Εάν θέλετε να παρακολουθήσετε ένα πλήρες μάθημα - εγγραφείτε για ένα μάθημα για .
Τι παρακολουθείται σε ένα σύμπλεγμα Kubernetes
φυσικούς διακομιστές. Εάν το σύμπλεγμα Kubernetes έχει αναπτυχθεί στους διακομιστές του, πρέπει να παρακολουθείτε την υγεία τους. Το Zabbix χειρίζεται αυτήν την εργασία. αν συνεργαστείτε μαζί του, τότε δεν χρειάζεται να αρνηθείτε, δεν θα υπάρξουν συγκρούσεις. Είναι το Zabbix που παρακολουθεί την κατάσταση των διακομιστών μας.
Ας προχωρήσουμε στην παρακολούθηση σε επίπεδο cluster.
Εξαρτήματα επιπέδου ελέγχου: API, Scheduler και άλλα. Τουλάχιστον, πρέπει να βεβαιωθείτε ότι το API των διακομιστών ή του etcd είναι μεγαλύτερο από 0. Το Etcd μπορεί να επιστρέψει πολλές μετρήσεις: από τους δίσκους στους οποίους περιστρέφεται, από την υγεία του συμπλέγματος etcd και άλλα.
Λιμενεργάτης εμφανίστηκε πριν από πολύ καιρό και όλοι γνωρίζουν καλά τα προβλήματά του: πολλά δοχεία δημιουργούν παγώματα και άλλα προβλήματα. Επομένως, το ίδιο το Docker, ως σύστημα, θα πρέπει επίσης να ελέγχεται, τουλάχιστον ως προς τη διαθεσιμότητα.
dns. Εάν το DNS πέσει στο σύμπλεγμα, τότε ολόκληρη η υπηρεσία Discovery θα πέσει μετά από αυτό, οι κλήσεις από ομάδες σε ομάδες θα σταματήσουν να λειτουργούν. Στην πρακτική μου, δεν υπήρχαν τέτοια προβλήματα, αλλά αυτό δεν σημαίνει ότι η κατάσταση του DNS δεν χρειάζεται παρακολούθηση. Η καθυστέρηση αιτήματος και ορισμένες άλλες μετρήσεις μπορούν να παρακολουθούνται στο CoreDNS.
Είσοδος. Είναι απαραίτητο να ελέγχεται η διαθεσιμότητα των εισερχομένων (συμπεριλαμβανομένου του Ελεγκτή Εισόδου) ως σημεία εισόδου στο έργο.
Τα κύρια συστατικά του συμπλέγματος έχουν αποσυναρμολογηθεί - τώρα ας πάμε στο επίπεδο των αφαιρέσεων.
Φαίνεται ότι οι εφαρμογές τρέχουν σε pods, πράγμα που σημαίνει ότι πρέπει να ελέγχονται, αλλά στην πραγματικότητα δεν είναι. Τα Pods είναι εφήμερα: σήμερα εκτελούνται σε έναν διακομιστή, αύριο σε έναν άλλο. σήμερα υπάρχουν 10 από αυτά, αύριο 2. Επομένως, κανείς δεν παρακολουθεί τους λοβούς. Μέσα σε μια αρχιτεκτονική microservice, είναι πιο σημαντικό να ελέγχεται η διαθεσιμότητα της εφαρμογής στο σύνολό της. Συγκεκριμένα, ελέγξτε τη διαθεσιμότητα των τελικών σημείων της υπηρεσίας: λειτουργεί κάτι; Εάν η εφαρμογή είναι διαθέσιμη, τότε τι συμβαίνει πίσω από αυτήν, πόσα αντίγραφα υπάρχουν τώρα - αυτά είναι ερωτήσεις δεύτερης τάξης. Δεν υπάρχει ανάγκη παρακολούθησης μεμονωμένων περιπτώσεων.
Στο τελευταίο επίπεδο, πρέπει να ελέγχετε τη λειτουργία της ίδιας της εφαρμογής, να λαμβάνετε επιχειρηματικές μετρήσεις: τον αριθμό των παραγγελιών, τη συμπεριφορά των χρηστών και ούτω καθεξής.
Προμηθέας
Το καλύτερο σύστημα για την παρακολούθηση ενός συμπλέγματος είναι . Δεν ξέρω κανένα εργαλείο που να μπορεί να ταιριάξει με τον Προμηθέα σε ποιότητα και ευκολία χρήσης. Είναι εξαιρετικό για ευέλικτες υποδομές, οπότε όταν λένε "Kubernetes monitoring", συνήθως εννοούν τον Προμηθέα.
Υπάρχουν μερικές επιλογές για να ξεκινήσετε με το Prometheus: χρησιμοποιώντας το Helm, μπορείτε να εγκαταστήσετε έναν κανονικό Prometheus ή Prometheus Operator.
- Κανονικός Προμηθέας. Όλα είναι καλά μαζί του, αλλά πρέπει να διαμορφώσετε το ConfigMap - στην πραγματικότητα, γράψτε αρχεία διαμόρφωσης που βασίζονται σε κείμενο, όπως κάναμε πριν, πριν από την αρχιτεκτονική microservice.
- Το Prometheus Operator είναι λίγο πιο απλωμένο, λίγο πιο περίπλοκο από την άποψη της εσωτερικής λογικής, αλλά είναι πιο εύκολο να δουλέψεις μαζί του: υπάρχουν ξεχωριστά αντικείμενα, προστίθενται αφαιρέσεις στο σύμπλεγμα, επομένως είναι πολύ πιο βολικό στον έλεγχο και τη διαμόρφωση.
Για να κατανοήσετε το προϊόν, συνιστώ να εγκαταστήσετε πρώτα τον κανονικό Prometheus. Θα πρέπει να ρυθμίσετε τα πάντα μέσω του config, αλλά αυτό θα είναι επωφελές: θα καταλάβετε τι ανήκει σε τι και πώς έχει ρυθμιστεί. Στο Prometheus Operator, ανεβαίνεις αμέσως σε μια αφαίρεση υψηλότερα, αν και μπορείς να εμβαθύνεις και στα βάθη αν το επιθυμείς.
Ο Prometheus είναι καλά ενσωματωμένος με το Kubernetes: μπορεί να έχει πρόσβαση και να αλληλεπιδρά με τον διακομιστή API.
Ο Prometheus είναι δημοφιλής, γι' αυτό τον υποστηρίζει ένας μεγάλος αριθμός εφαρμογών και γλωσσών προγραμματισμού. Χρειάζεται υποστήριξη, αφού ο Prometheus έχει τη δική του μορφή μετρήσεων και για να τη μεταφέρεις χρειάζεται είτε βιβλιοθήκη μέσα στην εφαρμογή είτε έτοιμο εξαγωγέα. Και υπάρχουν αρκετοί τέτοιοι εξαγωγείς. Για παράδειγμα, υπάρχει το PostgreSQL Exporter: παίρνει δεδομένα από την PostgreSQL και τα μετατρέπει σε μορφή Prometheus, ώστε ο Prometheus να μπορεί να εργαστεί μαζί του.
Αρχιτεκτονική του Προμηθέα
Διακομιστής Prometheus είναι το πίσω τέλος, ο εγκέφαλος του Προμηθέα. Οι μετρήσεις αποθηκεύονται και υποβάλλονται σε επεξεργασία εδώ.
Οι μετρήσεις αποθηκεύονται στη βάση δεδομένων χρονοσειρών (TSDB). Το TSDB δεν είναι μια ξεχωριστή βάση δεδομένων, αλλά ένα πακέτο στη γλώσσα Go που είναι ενσωματωμένο στον Prometheus. Σε γενικές γραμμές, όλα είναι σε ένα δυαδικό αρχείο.
Μην αποθηκεύετε δεδομένα στο TSDB για μεγάλο χρονικό διάστημα
Η υποδομή Prometheus δεν είναι κατάλληλη για μακροχρόνια αποθήκευση μετρήσεων. Η προεπιλεγμένη περίοδος διατήρησης είναι 15 ημέρες. Μπορείτε να υπερβείτε αυτό το όριο, αλλά να έχετε κατά νου: όσο περισσότερα δεδομένα αποθηκεύετε στο TSDB και όσο περισσότερο το κάνετε, τόσο περισσότερους πόρους θα καταναλώσει. Η αποθήκευση ιστορικών δεδομένων στον Προμηθέα θεωρείται κακή πρακτική.
Εάν έχετε τεράστια επισκεψιμότητα, ο αριθμός των μετρήσεων είναι εκατοντάδες χιλιάδες ανά δευτερόλεπτο, τότε είναι καλύτερο να περιορίσετε την αποθήκευσή τους ανά χώρο στο δίσκο ή ανά περίοδο. Συνήθως, τα "καυτά δεδομένα" αποθηκεύονται στο TSDB, μετρήσεις σε λίγες μόνο ώρες. Για μεγαλύτερη αποθήκευση, η εξωτερική αποθήκευση χρησιμοποιείται σε εκείνες τις βάσεις δεδομένων που είναι πραγματικά κατάλληλες για αυτό, για παράδειγμα, InfluxDB, ClickHouse και ούτω καθεξής. Είδα περισσότερες καλές κριτικές για το ClickHouse.
Ο διακομιστής Prometheus λειτουργεί στο μοντέλο τραβήξτε: πηγαίνει για μετρήσεις σε εκείνα τα τελικά σημεία που του δώσαμε. Είπαν: «πηγαίνετε στον διακομιστή API», και πηγαίνει εκεί κάθε ν-οστό αριθμό δευτερολέπτων και παίρνει τις μετρήσεις.
Για αντικείμενα με μικρή διάρκεια ζωής (job ή cron job) που μπορεί να εμφανιστούν μεταξύ των περιόδων απόξεσης, υπάρχει ένα στοιχείο Pushgateway. Οι μετρήσεις από βραχυπρόθεσμα αντικείμενα προωθούνται σε αυτό: η εργασία έχει ανέβει, εκτέλεσε μια ενέργεια, έστειλε μετρήσεις στο Pushgateway και ολοκληρώθηκε. Μετά από λίγο, ο Prometheus θα κατέβει με τον δικό του ρυθμό και θα πάρει αυτές τις μετρήσεις από το Pushgateway.
Για να ρυθμίσετε τις ειδοποιήσεις στο Prometheus υπάρχει ένα ξεχωριστό στοιχείο - Alertmanager. Και οι κανόνες ειδοποίησης. Για παράδειγμα, πρέπει να δημιουργήσετε μια ειδοποίηση εάν το API διακομιστή είναι 0. Όταν ενεργοποιείται το συμβάν, η ειδοποίηση μεταβιβάζεται στον διαχειριστή ειδοποιήσεων για περαιτέρω αποστολή. Ο διαχειριστής ειδοποιήσεων έχει αρκετά ευέλικτες ρυθμίσεις δρομολόγησης: μια ομάδα ειδοποιήσεων μπορεί να αποσταλεί στη συνομιλία τηλεγραφήματος των διαχειριστών, μια άλλη στη συνομιλία των προγραμματιστών και μια τρίτη στη συνομιλία των εργαζομένων υποδομής. Οι ειδοποιήσεις μπορούν να αποστέλλονται σε κανάλια Slack, Telegram, email και άλλα.
Και τέλος, θα σας πω για το χαρακτηριστικό δολοφόνος του Προμηθέα - Ανακαλύπτοντας. Όταν εργάζεστε με τον Prometheus, δεν χρειάζεται να καθορίσετε συγκεκριμένες διευθύνσεις αντικειμένων για παρακολούθηση, αρκεί να ορίσετε τον τύπο τους. Δηλαδή, δεν χρειάζεται να γράψετε "εδώ είναι η διεύθυνση IP, εδώ είναι η θύρα - οθόνη", αντίθετα, πρέπει να καθορίσετε με ποιες αρχές θα βρείτε αυτά τα αντικείμενα (στόχους - στόχοι). Ο ίδιος ο Προμηθέας, ανάλογα με το ποια αντικείμενα είναι ενεργά αυτή τη στιγμή, τραβάει τα απαραίτητα και τα προσθέτει στην παρακολούθηση.
Αυτή η προσέγγιση ταιριάζει καλά με τη δομή Kubernetes, όπου όλα επιπλέουν επίσης: σήμερα υπάρχουν 10 διακομιστές, αύριο 3. Για να μην προσδιορίζεται η διεύθυνση IP του διακομιστή κάθε φορά, έγραψαν μία φορά πώς να το βρουν - και το Discovering θα το κάνει .
Η γλώσσα του Προμηθέα λέγεται PromQL. Χρησιμοποιώντας αυτήν τη γλώσσα, μπορείτε να λάβετε τις τιμές συγκεκριμένων μετρήσεων και στη συνέχεια να τις μετατρέψετε, να δημιουργήσετε αναλυτικούς υπολογισμούς με βάση αυτές.
https://prometheus.io/docs/prometheus/latest/querying/basics/
Простой запрос
container_memory_usage_bytes
Математические операции
container_memory_usage_bytes / 1024 / 1024
Встроенные функции
sum(container_memory_usage_bytes) / 1024 / 1024
Уточнение запроса
100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)Διασύνδεση web Prometheus
Ο Prometheus έχει τη δική του, αρκετά μινιμαλιστική διεπαφή ιστού. Κατάλληλο μόνο για εντοπισμό σφαλμάτων ή επίδειξη.
Στη γραμμή Expression, μπορείτε να γράψετε ένα ερώτημα στη γλώσσα PromQL.
Η καρτέλα Ειδοποιήσεις περιέχει κανόνες ειδοποίησης και έχουν τρεις καταστάσεις:
- ανενεργό - εάν η ειδοποίηση δεν είναι ενεργή αυτή τη στιγμή, δηλαδή, όλα είναι καλά με αυτήν και δεν λειτούργησε.
- σε εκκρεμότητα - αυτό είναι εάν η ειδοποίηση λειτούργησε, αλλά η αποστολή δεν έχει ακόμη περάσει. Η καθυστέρηση έχει ρυθμιστεί για να αντισταθμίσει το δίκτυο που αναβοσβήνει: εάν η καθορισμένη υπηρεσία έχει αυξηθεί μέσα σε ένα λεπτό, τότε ο συναγερμός δεν πρέπει να ηχήσει ακόμα.
- η πυροδότηση είναι η τρίτη κατάσταση όταν ανάβει η ειδοποίηση και στέλνει μηνύματα.
Στο μενού Κατάσταση θα βρείτε πρόσβαση σε πληροφορίες σχετικά με το τι είναι ο Προμηθέας. Υπάρχει επίσης μια μετάβαση στους στόχους (στόχους), για τους οποίους μιλήσαμε παραπάνω.
Για μια πιο λεπτομερή επισκόπηση της διεπαφής Prometheus, βλ .
Ενσωμάτωση με Grafana
Στο web interface του Prometheus, δεν θα βρείτε όμορφα και κατανοητά γραφήματα από τα οποία μπορείτε να βγάλετε ένα συμπέρασμα σχετικά με την κατάσταση του συμπλέγματος. Για την κατασκευή τους, ο Προμηθέας ενσωματώνεται με τη Γραφάνα. Παίρνουμε τέτοιους πίνακες εργαλείων.
Η ρύθμιση της ενοποίησης των Prometheus και Grafana δεν είναι καθόλου δύσκολη, μπορείτε να βρείτε οδηγίες στην τεκμηρίωση: Λοιπόν, θα τελειώσω με αυτό.
Στα επόμενα άρθρα, θα συνεχίσουμε το θέμα της παρακολούθησης: θα μιλήσουμε για τη συλλογή και την ανάλυση κορμών χρησιμοποιώντας το Grafana Loki και εναλλακτικά εργαλεία.
Συγγραφέας: Marcel Ibraev, πιστοποιημένος διαχειριστής Kubernetes, ασκούμενος μηχανικός στην εταιρεία , ομιλητής και προγραμματιστής μαθημάτων Slurm.
Πηγή: www.habr.com