Γιατί παρατηρείς: μετρικές, logs και ειδοποιήσεις

Κοινό

αρχάριοι, καμία βάση δεν απαιτείται

Διάρκεια

30 έως 40 λεπτά

Ενότητα

1/7

Στόχος δεξιότητας

να διακρίνεις παρακολούθηση (monitoring) και παρατηρησιμότητα, να γνωρίζεις το επαγγελματικό λεξιλόγιο (μετρική, log, trace, ειδοποίηση, SLI, SLO, SLA), να αναγνωρίζεις πώς μοιάζουν στα αλήθεια μια μετρική, μια γραμμή log και μια ειδοποίηση του εργαστηρίου, και να τοποθετείς τις δέκα υπηρεσίες του kit μέσα στην ιστορία του μαθήματος

Σε μια εικόνα

Φαντάσου το ταμπλό ενός αυτοκινήτου. Οι μετρητές (ταχύτητα, στροφές κινητήρα, στάθμη βενζίνης) δίνουν μια αριθμητική τιμή σε κάθε στιγμή: αυτές είναι οι μετρικές. Το μαύρο κουτί, ο καταγραφέας συμβάντων ενός σύγχρονου αυτοκινήτου, σημειώνει τι συνέβη, γραμμή προς γραμμή, με την ακριβή ώρα: αυτά είναι τα logs (οι καταγραφές). Τα προειδοποιητικά λαμπάκια (λάδι, μπαταρία, κινητήρας) ανάβουν από μόνα τους όταν μια παρακολουθούμενη τιμή βγαίνει από το φυσιολογικό της εύρος, χωρίς να χρειάζεται να κοιτάς διαρκώς κάθε μετρητή: αυτές είναι οι ειδοποιήσεις. Το GPS, που ανασυνθέτει την πλήρη διαδρομή που ακολούθησες με τον χρόνο που πέρασες σε κάθε τμήμα, είναι ένα trace. Αυτή η εικόνα επανέρχεται σε όλη την ενότητα: κάθε υπηρεσία του εργαστηρίου παίζει τον ρόλο ενός από αυτά τα τέσσερα κομμάτια.

Πώς λειτουργεί

Τρεις δημόσιες βλάβες που δείχνουν γιατί παρατηρούμε

Δεν παρατηρούμε ένα σύστημα για ευχαρίστηση. Το παρατηρούμε γιατί κάποια μέρα κάτι σπάει, και πρέπει να καταλάβουμε τι, πού και από πότε, πριν κοστίσει ακριβά. Οι τρεις παρακάτω βλάβες είναι δημόσιες: κάθε εταιρεία έγραψε και δημοσίευσε η ίδια το post-mortem της. Δείχνουν τι επιτρέπει η παρατηρησιμότητα, και τι δεν επιτρέπει πάντα με την πρώτη.

Cloudflare, 18 Νοεμβρίου 2025: όταν οι μετρικές δεν αρκούν μόνες τους. Στις 11:20 UTC, το δίκτυο της Cloudflare σταματά να δρομολογεί σωστά ένα μεγάλο μέρος της παγκόσμιας κίνησης: οι επισκέπτες των ιστότοπων των πελατών της λαμβάνουν μια σελίδα σφάλματος. Η αιτία: μια αλλαγή δικαιωμάτων σε ένα cluster βάσης δεδομένων ClickHouse διπλασιάζει το μέγεθος ενός εσωτερικού αρχείου ρυθμίσεων (το αρχείο «χαρακτηριστικών» του συστήματος anti-bot), το οποίο ξεπερνά ένα όριο ορισμένο στον κώδικα και ρίχνει τον κεντρικό proxy. Οι μετρικές σφαλμάτων HTTP 5xx είναι ορατές από το πρώτο λεπτό, ως μια καθαρή κορυφή σε ένα γράφημα. Αλλά το αρχείο παραγόταν ελαττωματικά μόνο κατά διαστήματα, σε ένα μέρος μόνο του cluster: η κίνηση επανερχόταν και μετά ξανάπεφτε σε βλάβη κάθε πέντε λεπτά. Αυτή η διακύμανση έκανε αρχικά την ομάδα να πιστέψει ότι επρόκειτο για επίθεση άρνησης υπηρεσίας, όχι για εσωτερική βλάβη. Χρειάστηκε να διασταυρωθούν οι μετρικές με τις καταγραφές της μονάδας anti-bot για να εντοπιστεί η πραγματική αιτία. Η κύρια κίνηση αποκαθίσταται στις 14:30, όλα τα συστήματα επανέρχονται στο φυσιολογικό στις 17:06: σχεδόν 5 ώρες και 46 λεπτά από την αρχή έως το πλήρες τέλος του περιστατικού. Επίσημη πηγή: Cloudflare outage on November 18, 2025.

AWS S3, 28 Φεβρουαρίου 2017: όταν το εργαλείο εποπτείας εξαρτάται από το σύστημα που επιτηρεί. Στις 9:37 (ώρα Ειρηνικού), ένας μηχανικός του Amazon S3 εκτελεί μια εντολή συντήρησης που έπρεπε να αφαιρέσει μερικούς διακομιστές από ένα υποσύστημα χρέωσης, στην περιοχή Βόρειας Βιρτζίνια (us-east-1). Ένα λάθος πληκτρολόγησης αφαιρεί πολύ μεγαλύτερο αριθμό διακομιστών από τον προβλεπόμενο και ρίχνει δύο κρίσιμα υποσυστήματα του S3: το ευρετήριο (τα μεταδεδομένα και η θέση των αντικειμένων) και την τοποθέτηση (η κατανομή νέου αποθηκευτικού χώρου). Το S3 γίνεται ανίκανο να επεξεργαστεί τα αιτήματα GET, LIST, PUT και DELETE, και μαζί του πέφτουν οι νέες εκκινήσεις instances EC2, το EBS, το Lambda, και ο ίδιος ο επίσημος πίνακας κατάστασης της AWS, ο οποίος εξαρτιόταν από το S3 για να ενημερωθεί. Η AWS έπρεπε να επικοινωνήσει την κατάσταση της βλάβης μέσα από το νήμα της στο Twitter. Το ευρετήριο αποκαθίσταται πλήρως στις 13:18, η τοποθέτηση στις 13:54: περίπου 4 ώρες και 17 λεπτά από την αρχή του περιστατικού έως την επάνοδο στο φυσιολογικό. Επίσημη πηγή: Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region.

GitHub, 14 Αυγούστου 2024: όταν η ίδια η εποπτεία προκαλεί τη βλάβη. Στις 22:59 UTC, το GitHub αναπτύσσει μια αλλαγή ρυθμίσεων στις βάσεις δεδομένων του. Αυτή η αλλαγή σπάει την ικανότητα αυτών των βάσεων να απαντούν σωστά στους ελέγχους υγείας (health checks) που στέλνει το επίπεδο δρομολόγησης. Μη λαμβάνοντας πλέον έγκυρη απόκριση, το επίπεδο δρομολόγησης κηρύσσει αυτές τις βάσεις «σε κακή υγεία» και αφαιρεί την πρόσβαση ανάγνωσης: το GitHub.com γίνεται απρόσιτο για όλους τους χρήστες από τις 23:02 έως τις 23:38 UTC, δηλαδή 36 λεπτά. Η ομάδα διορθώνει ακυρώνοντας την αλλαγή ρυθμίσεων, και μετά επιβεβαιώνει με συνεχή επιτήρηση ότι η συνδεσιμότητα έχει αποκατασταθεί πριν κλείσει το περιστατικό στις 00:30 της επόμενης μέρας. Το σημείο που πρέπει να θυμάσαι: δεν ήταν η απουσία εποπτείας που προκάλεσε τη βλάβη, ήταν ένας από τους ίδιους τους μηχανισμούς εποπτείας, ο έλεγχος υγείας, που, κακώς ρυθμισμένος, την ενεργοποίησε. Επίσημη πηγή: GitHub Availability Report: August 2024.

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

Παρακολούθηση και παρατηρησιμότητα, το επαγγελματικό λεξιλόγιο

Η παρακολούθηση (monitoring) επιτηρεί δείκτες επιλεγμένους εκ των προτέρων, με ήδη γνωστά κατώφλια: «το ποσοστό σφαλμάτων ξεπερνά το 5 %». Είναι αποτελεσματική για μια βλάβη που έχουμε ήδη δει να συμβαίνει. Η παρατηρησιμότητα (observability) είναι η ικανότητα να κατανοούμε την εσωτερική κατάσταση ενός συστήματος από τα σήματα που ήδη παράγει (τις μετρικές του, τα logs του, τα traces του), ακόμη και για μια ερώτηση που δεν είχαμε προβλέψει, χωρίς να ξανααναπτύξουμε κώδικα για να πάμε να τη βρούμε. Η παρακολούθηση λέει «κάτι δεν πάει καλά»· η παρατηρησιμότητα βοηθά να απαντήσουμε «γιατί, πού και από πότε».

Αναφορά για τους ορισμούς SLI, SLO και SLA: Google SRE Book — Service Level Objectives. Για την παρατηρησιμότητα όπως τη βλέπουν τα εργαλεία του μαθήματος: Prometheus — Overview και Grafana — Observability.

Η ουσιώδης διαφορά μεταξύ παρακολούθησης και παρατηρησιμότητας: η παρακολούθηση απαντά σε ερωτήσεις γραμμένες εκ των προτέρων («ξεπερνά το ποσοστό σφαλμάτων το 5 %;»). Η παρατηρησιμότητα επιτρέπει να θέσεις μια ερώτηση που δεν είχες προβλέψει («ποια αιτήματα πήραν πάνω από 500 ms μεταξύ 19:33 και 19:34;») και να πάρεις την απάντηση από αυτά που το σύστημα έχει ήδη καταγράψει.

Τι δεν κάνουν ένα grep στον διακομιστή ή ένα ερώτημα SQL

Πριν από τον Prometheus και το Grafana, η ομάδα πλατφόρμας συνδεόταν με SSH στον διακομιστή και πληκτρολογούσε grep ERROR /var/log/api.log. Δουλεύει, για ένα μόνο μηχάνημα, ένα μόνο αρχείο, μια μόνο στιγμή. Αλλά:

• Ένα grep βλέπει μόνο ό,τι είναι γραμμένο σε αυτόν τον διακομιστή, σε αυτό το αρχείο. Με πολλά containers του API που τρέχουν παράλληλα, πρέπει να συνδεθείς σε καθένα και να διασταυρώσεις με το χέρι.
• Ένα grep δεν κρατά ιστορικό πέρα από το τρέχον αρχείο: όταν το αρχείο περιστρέφεται (log rotation) ή το container επανεκκινεί, ό,τι δεν διαβάστηκε χάνεται.
• Ένα grep δεν υπολογίζει τάση: δείχνει γραμμές, όχι μια καμπύλη «ποσοστό σφαλμάτων στα τελευταία πέντε λεπτά».
• Ένα ερώτημα SQL στη βάση του καταλόγου (SELECT count(*) FROM inscriptions) λέει πόσες εγγραφές υπάρχουν τώρα. Δεν λέει τίποτα για την καθυστέρηση των αιτημάτων HTTP, για το ποσοστό σφαλμάτων, ούτε για την κατάσταση των containers: αυτές οι πληροφορίες δεν βρίσκονται σε αυτή τη βάση.
• Ούτε το grep, ούτε το ερώτημα SQL, ειδοποιούν κάποιον αυτόματα. Πρέπει να θυμάσαι να τα εκτελείς, ξανά και ξανά, ή να περιμένεις να παραπονεθεί ένας χρήστης.

Η παρατηρησιμότητα απαντά σε αυτές τις ελλείψεις: συγκεντρώνει τις μετρικές και τα logs όλων των instances, κρατά ένα ιστορικό που μπορεί να ερωτηθεί, υπολογίζει τάσεις, και ειδοποιεί αυτόματα, χωρίς να περιμένει να τεθεί η ερώτηση.

Η ιστορία του μαθήματος: η πλατφόρμα, το API καταλόγου και η προϊσταμένη

Μπαίνεις στην ομάδα που λειτουργεί την πλατφόρμα διαδικτυακών μαθημάτων που χρησιμοποιείται στα άλλα μαθήματα του καταλόγου. Η καρδιά του συστήματος είναι ένα API, το API καταλόγου, γραμμένο σε Python με FastAPI, που εκθέτει 64 μαθήματα (C0001 έως C0064) στις διαδρομές /cours, /cours/{id}, /inscriptions, /lent, /sante και /metrics. Ένα δεύτερο πρόγραμμα, η γεννήτρια φορτίου (η υπηρεσία charge), καλεί αυτό το API συνεχώς, όπως θα έκαναν εκατοντάδες φοιτητές που ξεφυλλίζουν τον κατάλογο, εγγράφονται σε ένα μάθημα, ή πέφτουν πάνω σε μια σελίδα που δεν υπάρχει πια.

Η προϊσταμένη της ομάδας σου θέτει μια απλή ερώτηση, στην οποία όμως κανένα grep ούτε κανένα ερώτημα SQL δεν απαντά μονομιάς: «Δουλεύει; Για ποιον; Από πότε; Και γιατί χαλάει;» Δεν θέλει να συνδεθεί στον διακομιστή. Θέλει έναν πίνακα ελέγχου που μπορεί να ανοίξει η ίδια, και μια ειδοποίηση που την προειδοποιεί πριν γράψει ένας φοιτητής για να παραπονεθεί.

Αυτό είναι το κόκκινο νήμα του μαθήματος. Κάθε ενότητα προσθέτει ένα κομμάτι: οι μετρικές και η PromQL (ενότητα 2), η ενορχήστρωση του ίδιου του API (ενότητα 3), οι πίνακες ελέγχου Grafana (ενότητα 4), τα logs με το Loki (ενότητα 5), οι ειδοποιήσεις που προειδοποιούν πριν από το παράπονο (ενότητα 6). Η ενότητα 7 συγκεντρώνει τα πάντα. Και σε κάθε βήμα, το εργαστήριο σε αφήνει να σπάσεις επίτηδες ένα κομμάτι της πλατφόρμας (.\labo.ps1 casser api, casser erreurs, casser lenteur, casser disque) για να μάθεις να διαβάζεις τη βλάβη στα εργαλεία πριν την επιδιορθώσεις.

Οι δέκα υπηρεσίες του εργαστηρίου

Βήμα προς βήμα

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

1. Μια μετρική, όπως τη διαβάζει ο Prometheus. Κάθε 15 δευτερόλεπτα, ο Prometheus καλεί το http://api:8000/metrics. Εδώ είναι τέσσερις γραμμές αυτής της σελίδας, στο μηχάνημα του μαθήματος:

   text

   # HELP http_requetes_total Nombre de requêtes HTTP reçues, par méthode, route normalisée et code de réponse.
   # TYPE http_requetes_total counter
   http_requetes_total{code="200",methode="GET",route="/cours"} 3247.0
   http_requetes_total{code="500",methode="GET",route="/cours"} 32.0

   Τι πρέπει να δεις: μια μετρική έχει ένα όνομα (http_requetes_total), labels μέσα σε άγκιστρα (code, methode, route) και μια τιμή (3247.0). Οι δύο γραμμές έχουν το ίδιο όνομα αλλά διαφορετικά labels: είναι δύο διακριτές σειρές. Η γραμμή # TYPE … counter λέει ότι αυτός ο αριθμός μόνο αυξάνεται. Το μάθημα 02 αναλύει τους τέσσερις τύπους.

2. Ένα log, όπως το γράφει το API. Το API γράφει μια γραμμή JSON ανά αίτημα στην τυπική έξοδό του. Το .\labo.ps1 journal api τις εμφανίζει· εδώ είναι δύο από αυτές, στο μηχάνημα του μαθήματος:

   text

   labo-api  | {"horodatage": "2026-09-15T19:33:25.839+00:00", "niveau": "INFO", "id_requete": "46bb533b33e9", "methode": "GET", "route": "/cours/{id}", "code": 200, "duree_ms": 13.9, "message": "GET /cours/C0038 -> 200"}
   labo-api  | {"horodatage": "2026-09-15T19:33:14.781+00:00", "niveau": "ERROR", "id_requete": "dc1c2ff189a6", "methode": "GET", "route": "/cours/{id}", "code": 500, "duree_ms": 0.1, "message": "GET /cours/C0019 -> 500"}

   Τι πρέπει να δεις: ένα log είναι ένα ακριβές συμβάν (αυτό το συγκεκριμένο αίτημα, αυτή τη συγκεκριμένη στιγμή, για το μάθημα C0038), ενώ η μετρική του βήματος 1 είναι μια συσσώρευση (3247 επιτυχημένα αιτήματα /cours από την εκκίνηση). Το πεδίο id_requete ταυτοποιεί ένα μοναδικό αίτημα· η ίδια τιμή επιστρέφεται στον πελάτη στην κεφαλίδα HTTP x-id-requete. Η δεύτερη γραμμή είναι ένα σφάλμα 500: το εργαστήριο παράγει επίτηδες 1 % τέτοια σε κανονική λειτουργία.

3. Μια ειδοποίηση, όπως τη λαμβάνει η ομάδα εφημερίας. Όταν το API είναι σταματημένο (casser api), ο Prometheus δεν μπορεί πλέον να διαβάσει το /metrics, ο κανόνας APIInjoignable περνά σε firing μετά από 30 δευτερόλεπτα, ο Alertmanager τη μεταδίδει στο webhook. Εδώ είναι τι περιέχει τότε το http://localhost:8090/alertes.json, στο μηχάνημα του μαθήματος:

   json

   {"recu_a":"2026-09-15T19:41:26+00:00","etat":"firing","nom":"APIInjoignable","severite":"critique","service":"api","resume":"L'API catalogue ne répond plus","description":"Prometheus n'arrive plus à lire http://api:8000/metrics depuis 30 secondes (cible api:8000).","debut":"2026-09-15T19:41:11.496Z","fin":"0001-01-01T00:00:00Z"}

   Τι πρέπει να δεις: η ειδοποίηση έχει ένα όνομα, μια σοβαρότητα, μια περίληψη αναγνώσιμη από άνθρωπο, και μια κατάσταση firing (ηχεί). Το πεδίο fin έχει μια μηδενική ημερομηνία όσο η ειδοποίηση είναι σε εξέλιξη· μετά το reparer, φτάνει μια δεύτερη γνωστοποίηση με "etat":"resolved" και μια πραγματική ημερομηνία λήξης. Κανείς δεν χρειάστηκε να ανανεώσει μια σελίδα: το λαμπάκι άναψε μόνο του.

4. Η συνολική εικόνα, σε μια εντολή. Το .\labo.ps1 etat συνοψίζει την κατάσταση των δέκα υπηρεσιών και της εποπτείας. Στο μηχάνημα του μαθήματος, σε κανονική λειτουργία:

   text

   == Supervision ==
     ✔ Prometheus répond — cibles up : 8/8
        séries en mémoire : 12350
        alertes : 0 active(s), 0 en attente (pending)
     ✔ Alertmanager répond (http://localhost:9093)
     ✔ Grafana répond (http://localhost:3000)
     ✔ Loki répond (http://localhost:3100)
     ✔ API catalogue répond — version 1.0.0, 64 cours
     ✔ Webhook répond — 0 alerte(s) reçue(s) (http://localhost:8090)
   
   Labo : 10/10 services, 8/8 cibles up, 0 alertes actives.

   Τι πρέπει να δεις: 8/8 cibles up (ο Prometheus διαβάζει οκτώ σελίδες /metrics: οι δέκα υπηρεσίες μείον charge και webhook, που δεν εκθέτουν καμία), 12350 σειρές στη μνήμη (αυτός ο αριθμός διαφέρει από μηχάνημα σε μηχάνημα), 0 alertes actives. Αυτή είναι η γραμμή που πρέπει να ξαναβρίσκεις στο τέλος κάθε πρακτικής του μαθήματος.

5. Ο κανόνας που συνδέει τη μετρική με την ειδοποίηση. Η ειδοποίηση του βήματος 3 δεν βγήκε από το πουθενά: είναι γραμμένη σε ένα αρχείο του kit, το prometheus/regles/alertes.yml, του οποίου ο Prometheus αξιολογεί κάθε κανόνα κάθε 15 δευτερόλεπτα (evaluation_interval: 15s στο prometheus/prometheus.yml). Εδώ είναι ο πρώτος από τους δέκα κανόνες, όπως είναι στο kit:

   yaml

   groups:
     - name: api-catalogue
       rules:
         - alert: APIInjoignable
           expr: up{job="api"} == 0
           for: 30s
           labels:
             severite: critique
             service: api
           annotations:
             resume: "L'API catalogue ne répond plus"
             description: "Prometheus n'arrive plus à lire http://api:8000/metrics depuis 30 secondes (cible {{ $labels.instance }})."

   Τι πρέπει να δεις: το expr είναι μια μετρική (up, αυτή που κατασκευάζει ο ίδιος ο Prometheus σε κάθε ανάγνωση: 1 αν ο στόχος απάντησε, 0 αλλιώς) συγκρινόμενη με μια τιμή· το for: 30s είναι η διάρκεια κατά την οποία η συνθήκη πρέπει να παραμείνει αληθής πριν ηχήσει η ειδοποίηση· resume και description είναι ακριβώς το κείμενο που εμφάνισε το webhook στο βήμα 3, με το {{ $labels.instance }} αντικατεστημένο από api:8000. Μια ειδοποίηση είναι μια μετρική, ένα κατώφλι και μια διάρκεια: τίποτα περισσότερο. Η ενότητα 6 θα σε κάνει να γράψεις τις δικές σου.

Αν κολλήσει

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

• «Το API έχει βλάβη, απαντά 404»: όχι. Ένα 404 είναι μια υγιής απόκριση μιας υπηρεσίας που τρέχει και λέει «αυτός ο πόρος δεν υπάρχει». Στο εργαστήριο, το http://localhost:8000/cours/C9999 απαντά:

  text

  HTTP 404 {"detail":"cours C9999 introuvable"}

  Ένα API που είναι πραγματικά σταματημένο δεν απαντά τίποτα απολύτως. Κατά τη διάρκεια του casser api, το curl http://localhost:8000/sante επιστρέφει:

  text

  curl: (7) Failed to connect to localhost:8000 after 2237 ms: Could not connect to server

  Και το Invoke-RestMethod http://localhost:8000/sante σε PowerShell: Le délai de l'opération a expiré. Ένα 404 είναι ένα log επιπέδου WARNING και μια μετρική code="404"· ένα σταματημένο API είναι το up{job="api"} που ισούται με 0.

• «Δεν υπάρχει καμία ειδοποίηση, η εποπτεία δεν δουλεύει»: στον Prometheus, η μετρική ALERTS επιστρέφει κενό αποτέλεσμα όταν όλα πάνε καλά. Στο μηχάνημα του μαθήματος, σε κανονική λειτουργία, το API ερωτημάτων απαντά:

  json

  {"status":"success","data":{"resultType":"vector","result":[]}}

  "status":"success" με "result":[]: το ερώτημα είναι σωστό, απλώς δεν υπάρχει τίποτα να δείξει. Αυτή είναι η κανονική κατάσταση, όχι βλάβη. Η ALERTS περιέχει μια σειρά μόνο για μια ειδοποίηση pending ή firing.

• «Μια μετρική και ένα log είναι η ίδια πληροφορία»: όχι. Η μετρική http_requetes_total{code="500",methode="GET",route="/cours/{id}"} 27.0 λέει ότι υπήρξαν 27 σφάλματα σε αυτή τη διαδρομή από την εκκίνηση, χωρίς να λέει ποια. Το log "GET /cours/C0019 -> 500" με "id_requete": "dc1c2ff189a6" λέει ακριβώς ποιο. Η μετρική είναι φθηνή και μετριέται· το log είναι λεπτομερές και διαβάζεται. Η ενότητα 5 τα συνδέει μέσω του πεδίου id_requete.

Να θυμάσαι

Η παρακολούθηση επιτηρεί κατώφλια γνωστά εκ των προτέρων· η παρατηρησιμότητα επιτρέπει να κατανοήσεις μια βλάβη που δεν είχες προβλέψει, από τις μετρικές, τα logs και τα traces που ένα σύστημα παράγει ήδη. Μια μετρική είναι ένας αριθμός που μετριέται στον χρόνο, με ένα όνομα, labels και μια τιμή (http_requetes_total{code="200",methode="GET",route="/cours"} 3247.0). Ένα log είναι ένα συμβάν με χρονοσφραγίδα, μια γραμμή JSON ανά αίτημα στο εργαστήριο, με ένα μοναδικό id_requete. Μια ειδοποίηση προειδοποιεί αυτόματα όταν μια συνθήκη παραμένει αληθής αρκετά (APIInjoignable μετά από 30 δευτερόλεπτα απρόσιτου API) και φτάνει στο webhook με κατάσταση firing και μετά resolved. Το ταμπλό ενός αυτοκινήτου τα συνοψίζει όλα: μετρητές = μετρικές, μαύρο κουτί = logs, λαμπάκια = ειδοποιήσεις, GPS = traces, παρμπρίζ = Grafana. Ούτε ένα grep σε έναν μόνο διακομιστή ούτε ένα ερώτημα SQL στην επιχειρησιακή βάση συγκεντρώνουν το ιστορικό, υπολογίζουν μια τάση ή προειδοποιούν αυτόματα. Ένα 404 είναι η υγιής απόκριση μιας υπηρεσίας που τρέχει· ένα σταματημένο API δεν απαντά τίποτα και το up ισούται με 0. Το κόκκινο νήμα του μαθήματος είναι η πλατφόρμα διαδικτυακών μαθημάτων, το API καταλόγου των 64 μαθημάτων της, η γεννήτρια φορτίου της και οι δέκα υπηρεσίες της.

Για να πας παρακάτω

• Τα τρία post-mortems που αναφέρθηκαν, να τα διαβάσεις ολόκληρα: είναι σύντομα, γραμμένα από τις ίδιες τις ομάδες, και καθένα περιέχει μια χρονολογία λεπτό προς λεπτό που μοιάζει με αυτή που θα κατασκευάσεις στην ενότητα 6 με casser και reparer.
• Prometheus — Overview: η επίσημη σελίδα εισαγωγής, που εξηγεί το μοντέλο pull και τον ρόλο κάθε συστατικού.
• Google SRE Book — Monitoring Distributed Systems: το κεφάλαιο που καθιέρωσε το λεξιλόγιο (τα τέσσερα χρυσά σήματα: καθυστέρηση, κίνηση, σφάλματα, κορεσμός). Ο πίνακας ελέγχου «API catalogue — signaux dorés» (API καταλόγου — χρυσά σήματα) του εργαστηρίου, που θα ανοίξεις στο μάθημα 04, ακολουθεί ακριβώς αυτή τη διάρθρωση.
• Grafana Loki — Overview: γιατί το Loki ευρετηριάζει labels και όχι το κείμενο των logs, η διαφορά με μια μηχανή αναζήτησης πλήρους κειμένου.
• Το μάθημα 02 ξαναπιάνει κάθε όρο αυτού του μαθήματος με τις πραγματικές γραμμές του /metrics του εργαστηρίου: οι τέσσερις τύποι μετρικών, τα labels, η πληθικότητα, το pull, και η ακριβής δομή μιας γραμμής log JSON.