Το σύστημα λειτουργεί. Μέχρι τη στιγμή που σταματά
Φαντάσου ένα ηλεκτρονικό κατάστημα όπου οι πελάτες μπορούν να περιηγηθούν στα προϊόντα, να τα προσθέσουν στο καλάθι και να προχωρήσουν στην πληρωμή. Ο διακομιστής ανταποκρίνεται, η σελίδα ανοίγει και οι βασικοί δείκτες της υποδομής δεν δείχνουν κάποιο σοβαρό πρόβλημα. Φαινομενικά όλα λειτουργούν σωστά.
Ωστόσο, ένα μέρος των πελατών δεν μπορεί να ολοκληρώσει την παραγγελία. Σε κάποιους η πληρωμή διαρκεί αρκετά δευτερόλεπτα, σε άλλους εμφανίζεται σφάλμα. Η τεχνική ομάδα λαμβάνει αναφορές, αλλά δεν ξέρει ακόμη αν η αιτία είναι η πύλη πληρωμών, η βάση δεδομένων, η τελευταία ενημέρωση της εφαρμογής ή μήπως κάποιο πρόβλημα στην επικοινωνία μεταξύ υπηρεσιών.
Αυτή είναι μια κατάσταση στην οποία το απλό monitoring μπορεί να αποδειχθεί ανεπαρκές. Μπορεί να δείξει ότι αυξήθηκε ο αριθμός σφαλμάτων ή ότι επιμηκύνθηκε ο χρόνος απόκρισης, αλλά δεν παρέχει πάντα τις πληροφορίες που χρειάζονται για τη γρήγορη εύρεση της αιτίας.
Ακριβώς αυτό το κενό καλύπτει το observability, δηλαδή η παρατηρησιμότητα του συστήματος. Στόχος της δεν είναι μόνο να διαπιστώσει ότι η εφαρμογή λειτουργεί λανθασμένα. Πρόκειται για τη δυνατότητα να αναλυθεί η συμπεριφορά της, να αναπαραχθεί η ακολουθία των γεγονότων και να βρεθεί η πηγή του προβλήματος, ακόμη και όταν δεν είχε προβλεφθεί προηγουμένως κάποιο συγκεκριμένο σενάριο βλάβης.
Monitoring και observability - παρόμοιοι στόχοι, διαφορετικές δυνατότητες
Το monitoring και το observability είναι στενά συνδεδεμένα, αλλά δεν σημαίνουν το ίδιο.
Το monitoring αφορά τη συστηματική συλλογή και ανάλυση δεδομένων για την κατάσταση της εφαρμογής και της υποδομής. Επιτρέπει την παρακολούθηση συγκεκριμένων παραμέτρων, τον εντοπισμό αποκλίσεων από τα καθορισμένα όρια και την ενεργοποίηση ειδοποιήσεων όταν προκύψει μια κατάσταση που απαιτεί αντίδραση.
Ενδεικτικές ερωτήσεις στις οποίες απαντά το monitoring είναι:
- Είναι διαθέσιμος ο διακομιστής;
- Ποιος είναι ο μέσος χρόνος απόκρισης του API;
- Υπερβαίνει ο αριθμός των σφαλμάτων HTTP 500 το καθορισμένο όριο;
- Ποια είναι η χρήση μνήμης και επεξεργαστή;
- Αυξάνεται η ουρά εργασιών πιο γρήγορα από ό,τι το σύστημα μπορεί να την εξυπηρετήσει;
Το observability προχωρά παραπέρα. Επιτρέπει την ανάλυση δεδομένων που προέρχονται από διαφορετικά μέρη του συστήματος και τη σύνδεσή τους σε ένα πλαίσιο που βοηθά να κατανοηθεί γιατί προέκυψε μια συγκεκριμένη συμπεριφορά.
Αυτό μπορεί να αποδοθεί σε τρεις ερωτήσεις:
- Monitoring: Υπάρχει κάτι που δεν πάει καλά;
- Διάγνωση: Πού εμφανίστηκε το πρόβλημα;
- Observability: Τι συνέβη, γιατί και ποιος ήταν ο αντίκτυπος στη λειτουργία του συστήματος;
Η παρατηρησιμότητα δεν αντικαθιστά το monitoring. Είναι μια προσέγγιση που αξιοποιεί το monitoring και τα κατάλληλα προετοιμασμένα τηλεμετρικά δεδομένα, ώστε να επιτρέπει βαθύτερη διερεύνηση της συμπεριφοράς της εφαρμογής. Το OpenTelemetry περιγράφει το observability ως τη δυνατότητα να τίθενται ερωτήσεις στο σύστημα για τη συμπεριφορά του με βάση σήματα όπως logs, metrics και distributed traces. <Cite ref="turn154932search0"/>
Οι τρεις πυλώνες του observability: logs, metrics και tracing
Η βάση της παρατηρησιμότητας είναι τρία είδη τηλεμετρικών δεδομένων: logs, metrics και traces. Κάθε ένα δείχνει μια διαφορετική πλευρά της λειτουργίας της εφαρμογής. Μόνο ο συνδυασμός τους δίνει μια ευρύτερη εικόνα της κατάστασης.
1. Logs - τι συνέβη στην εφαρμογή;
Τα logs είναι οργανωμένες καταγραφές γεγονότων που παράγονται από την εφαρμογή, το λειτουργικό σύστημα, τους διακομιστές, τις βάσεις δεδομένων και άλλα στοιχεία της υποδομής.
Μπορούν να καταγράφουν για παράδειγμα:
- την έναρξη και τη λήξη μιας διεργασίας,
- την προσπάθεια σύνδεσης χρήστη,
- την αποστολή αιτήματος σε εξωτερικό API,
- σφάλμα επικύρωσης δεδομένων,
- μια αποτυχημένη συναλλαγή,
- μια εξαίρεση που αναφέρθηκε από την εφαρμογή,
- την αλλαγή κατάστασης μιας παραγγελίας.
Ένα log μπορεί να περιέχει χρονική σήμανση, επίπεδο σοβαρότητας, όνομα υπηρεσίας, μήνυμα, αναγνωριστικό αιτήματος και πρόσθετα χαρακτηριστικά που περιγράφουν το γεγονός.
Αξίζει να γίνεται διάκριση ανάμεσα σε κειμενικά logs και δομημένα logs. Μια κειμενική καταγραφή μπορεί να μοιάζει ως εξής:Σφάλμα κατά την επεξεργασία της παραγγελίας
Αυτό το μήνυμα ενημερώνει για την εμφάνιση προβλήματος, αλλά λέει ελάχιστα για το πλαίσιο του. Ένα δομημένο log, αντίθετα, μπορεί να περιέχει ξεχωριστά πεδία, όπως αναγνωριστικό παραγγελίας, όνομα ενέργειας, κωδικό σφάλματος, χρόνο εκτέλεσης και αναγνωριστικό ίχνους. Έτσι τα δεδομένα μπορούν να φιλτραριστούν, να ομαδοποιηθούν και να αναλυθούν αυτόματα.
Καλή πρακτική: τα logs πρέπει να σχεδιάζονται με γνώμονα την μετέπειτα ανάλυση και όχι μόνο την καταγραφή μηνυμάτων. Αξίζει να χρησιμοποιούνται συνεπείς ονομασίες, επίπεδα σοβαρότητας και αναγνωριστικά συσχέτισης που θα επιτρέψουν τη σύνδεση γεγονότων που προέρχονται από διαφορετικά στοιχεία.
Ταυτόχρονα, η καταγραφή απαιτεί σύνεση. Η αποθήκευση κάθε ενέργειας σε πλήρη έκταση μπορεί να δημιουργήσει τεράστιους όγκους δεδομένων, να αυξήσει το κόστος αποθήκευσης και να δυσκολέψει την εύρεση σημαντικών πληροφοριών. Εξίσου σημαντικό, τα logs δεν πρέπει να αποκαλύπτουν κωδικούς πρόσβασης, διακριτικά πρόσβασης, στοιχεία καρτών πληρωμής ή άλλες εμπιστευτικές πληροφορίες. Πρέπει να εφαρμόζονται απόκρυψη, έλεγχος πρόσβασης, κατάλληλες περίοδοι διατήρησης και κανόνες ασφαλούς επεξεργασίας δεδομένων.
2. Metrics - πώς συμπεριφέρεται το σύστημα με την πάροδο του χρόνου;
Τα metrics είναι συγκεντρωτικά αριθμητικά δεδομένα που περιγράφουν την κατάσταση, την απόδοση και τη συμπεριφορά του συστήματος σε συγκεκριμένο χρονικό διάστημα.
Ενδεικτικά metrics περιλαμβάνουν:
- τον αριθμό αιτημάτων που εξυπηρετήθηκαν ανά δευτερόλεπτο,
- το ποσοστό αιτημάτων που ολοκληρώθηκαν με σφάλμα,
- τον χρόνο απόκρισης του API,
- τη χρήση CPU και μνήμης,
- τον αριθμό ενεργών συνεδριών,
- το μήκος της ουράς εργασιών,
- τον αριθμό των ολοκληρωμένων συναλλαγών,
- τον χρόνο αναμονής για σύνδεση με τη βάση δεδομένων.
Το μεγαλύτερο πλεονέκτημά τους είναι η δυνατότητα παρακολούθησης τάσεων. Ένα μεμονωμένο σφάλμα μπορεί να είναι ένα μεμονωμένο περιστατικό, αλλά ένας σταδιακά αυξανόμενος χρόνος απόκρισης, ένας αυξανόμενος αριθμός αποτυχημένων συναλλαγών ή μια διογκούμενη ουρά εργασιών μπορεί να υποδεικνύουν ένα πρόβλημα που εξελίσσεται.
Στην πράξη, τα metrics βοηθούν να απαντηθεί όχι μόνο το ερώτημα αν η εφαρμογή λειτουργεί, αλλά και αν η απόδοσή της ανταποκρίνεται στις προσδοκίες των χρηστών και στις επιχειρηματικές απαιτήσεις.
Ιδιαίτερα χρήσιμα είναι τα percentiles του χρόνου απόκρισης, για παράδειγμα p95 και p99. Ο μέσος όρος μπορεί να κρύψει μια κατάσταση όπου η πλειονότητα των χρηστών λαμβάνει γρήγορη απόκριση, αλλά ένα μικρό ποσοστό αντιμετωπίζει πολύ μεγάλες καθυστερήσεις. Τα percentiles δείχνουν πόσο διαρκεί η εξυπηρέτηση των πιο αργών αιτημάτων και βοηθούν να εντοπιστούν προβλήματα που δεν φαίνονται στις μέσες τιμές.
Καλή πρακτική: επίλεξε metrics που έχουν σημασία για τον χρήστη και για την επιχειρηματική διαδικασία. Η απλή πληροφορία για το φορτίο της CPU δεν θα πει αν ο πελάτης μπορεί να υποβάλει παραγγελία. Αξίζει, λοιπόν, να παρακολουθούνται και δείκτες που σχετίζονται με τις βασικές λειτουργίες, όπως η επιτυχία των πληρωμών, ο χρόνος ολοκλήρωσης της παραγγελίας ή η διαθεσιμότητα των σημαντικότερων ενεργειών.
3. Tracing - από πού πέρασε το αίτημα;
Το tracing, και ειδικότερα το distributed tracing, δηλαδή η κατανεμημένη ιχνηλάτηση, επιτρέπει να παρακολουθηθεί η διαδρομή ενός μεμονωμένου αιτήματος μέσα από διαφορετικά στοιχεία του συστήματος.
Σε μια σύγχρονη εφαρμογή, μια ενέργεια χρήστη μπορεί να περιλαμβάνει πολλά στάδια. Το κλικ στο κουμπί «Υποβολή παραγγελίας» μπορεί να ενεργοποιήσει ένα αίτημα στον browser, το οποίο καταλήγει στο API, στη συνέχεια στην υπηρεσία παραγγελιών, στη βάση δεδομένων, στο σύστημα αποθήκης και στον εξωτερικό πάροχο πληρωμών.
Αν η διαδικασία καθυστερεί, η ίδια η πληροφορία για τον χρόνο απόκρισης ολόκληρου του API μπορεί να μην αρκεί. Το tracing επιτρέπει να αναλυθεί αυτός ο χρόνος σε επιμέρους λειτουργίες και να φανεί ποιο στάδιο ευθύνεται για την καθυστέρηση.
Το βασικό στοιχείο ενός ίχνους (trace) είναι το span, δηλαδή η καταγραφή μιας μεμονωμένης λειτουργίας. Το span μπορεί να περιέχει χρόνο έναρξης και λήξης, το όνομα της λειτουργίας, την κατάσταση και μεταδεδομένα. Τα συνδεδεμένα spans δημιουργούν ένα ίχνος που δείχνει την πορεία ολόκληρου του αιτήματος.
Για παράδειγμα:
- Το API λαμβάνει το αίτημα και το προωθεί παρακάτω.
- Η υπηρεσία παραγγελιών επαληθεύει τα δεδομένα.
- Η βάση δεδομένων αποθηκεύει την παραγγελία.
- Η υπηρεσία αποθήκης ελέγχει τη διαθεσιμότητα του προϊόντος.
- Η εξωτερική πύλη πληρωμών επεξεργάζεται τη συναλλαγή.
- Η εφαρμογή επιστρέφει το αποτέλεσμα στον χρήστη.
Αν όλη η διαδικασία διαρκεί 8 δευτερόλεπτα, το tracing μπορεί να δείξει ότι τα 6,5 δευτερόλεπτα κατανάλωσε η απάντηση της εξωτερικής πύλης πληρωμών, ενώ οι υπόλοιπες λειτουργίες εκτελέστηκαν κανονικά. Η ομάδα αποκτά έτσι ένα συγκεκριμένο σημείο για περαιτέρω ανάλυση, αντί να ξεκινά τη διάγνωση από τυχαία στοιχεία του συστήματος.
Το tracing είναι ιδιαίτερα χρήσιμο σε αρχιτεκτονικές μικροϋπηρεσιών, κατανεμημένα συστήματα, εφαρμογές βασισμένες σε ουρές και λύσεις που ενσωματώνουν πολλές εξωτερικές υπηρεσίες. <Cite ref="turn154932search0"/>
Alerts - η πληροφορία πρέπει να φτάνει στο σωστό άτομο
Τα δεδομένα τηλεμετρίας είναι χρήσιμα μόνο όταν μπορεί κανείς να ενεργήσει με βάση αυτά. Γι’ αυτό, σημαντικό μέρος του observability είναι το σύστημα ειδοποιήσεων.
Το alert είναι μια ειδοποίηση για ένα γεγονός ή μια κατάσταση που απαιτεί προσοχή. Μπορεί να ενεργοποιηθεί όταν ξεπεραστεί ένα όριο σε μια μετρική, όταν ανιχνευτεί ένα συγκεκριμένο μοτίβο σφαλμάτων ή όταν διαπιστωθεί ότι μια κρίσιμη λειτουργία της εφαρμογής δεν λειτουργεί όπως αναμένεται.
Ωστόσο, δεν πρέπει κάθε αύξηση φόρτου να δημιουργεί συναγερμό. Αν το σύστημα εξυπηρετεί τακτικά μεγάλη κίνηση στις ώρες αιχμής, η ειδοποίηση για κάθε αύξηση στον αριθμό των αιτημάτων θα προκαλεί θόρυβο πληροφορίας. Πολλά alerts οδηγούν στο να αγνοούνται, και κατά συνέπεια να παραβλέπεται ένα πραγματικά σημαντικό περιστατικό.
Επομένως, αξίζει να οριστούν:
- ποια γεγονότα απαιτούν άμεση αντίδραση,
- ποια προβλήματα μπορούν να αναλυθούν στο πλαίσιο της συνήθους λειτουργίας,
- ποιος είναι υπεύθυνος για κάθε τύπο alert,
- ποιες πληροφορίες πρέπει να περιέχει η ειδοποίηση,
- ποιες ενέργειες πρέπει να γίνουν μετά την παραλαβή της.
Ένα καλό σημείο εκκίνησης είναι ο ορισμός alerts με βάση την επίδραση στον χρήστη και τους στόχους αξιοπιστίας, και όχι μόνο τις παραμέτρους της υποδομής. Για παράδειγμα, ένα alert για αυξανόμενο ποσοστό αποτυχημένων πληρωμών μπορεί να έχει μεγαλύτερη επιχειρησιακή σημασία από μια σύντομη αιχμή στη χρήση της CPU.
Το alert πρέπει να οδηγεί σε ενέργεια. Αν δεν είναι σαφές ποιος πρέπει να το χειριστεί ούτε τι πρέπει να γίνει, είναι απλώς ένα ακόμη μήνυμα στο σύστημα.
Παράδειγμα από την πράξη: πώς το observability βοηθά να βρεθεί η αιτία μιας βλάβης;
Ας υποθέσουμε ότι οι χρήστες μιας B2B εφαρμογής αναφέρουν πως η δημιουργία αναφορών διαρκεί πολύ περισσότερο από το συνηθισμένο. Το monitoring εντοπίζει αύξηση στον χρόνο απόκρισης και ενεργοποιεί ένα alert.
Η ομάδα ξεκινά την ανάλυση:
- Οι μετρικές δείχνουν ότι το πρόβλημα αφορά κυρίως αναφορές που καλύπτουν μεγάλα εύρη δεδομένων. Οι υπόλοιπες λειτουργίες λειτουργούν κανονικά.
- Το tracing δείχνει ότι η μεγαλύτερη καθυστέρηση εμφανίζεται κατά την εκτέλεση του ερωτήματος προς τη βάση δεδομένων.
- Τα log περιέχουν λεπτομέρειες για το ερώτημα, τις παραμέτρους λειτουργίας του και πληροφορίες για σφάλματα, χωρίς να αποκαλύπτουν ευαίσθητα δεδομένα.
- Η συσχέτιση δεδομένων επιτρέπει τη σύνδεση ενός συγκεκριμένου ίχνους με τις αντίστοιχες εγγραφές στα log και με αλλαγές που φαίνονται στα γραφήματα μετρικών.
- Η ανάλυση αλλαγών δείχνει ότι το πρόβλημα εμφανίστηκε μετά την ανάπτυξη της νέας έκδοσης της αναφοράς, η οποία άρχισε να εκτελεί ένα κοστοβόρο ερώτημα.
Χάρη σε αυτό, η ομάδα δεν χρειάζεται να ελέγχει στα τυφλά ολόκληρη την υποδομή. Μπορεί να επικεντρωθεί σε μια συγκεκριμένη λειτουργία, να συγκρίνει τη συμπεριφορά πριν και μετά την ανάπτυξη, και στη συνέχεια να βελτιστοποιήσει το ερώτημα ή να αναστρέψει την αλλαγή.
Το observability δεν καταργεί τις βλάβες και δεν εγγυάται ότι κάθε αιτία θα βρεθεί αυτόματα. Επιτρέπει όμως να περιοριστεί το πεδίο αναζήτησης, να μειωθεί ο χρόνος διάγνωσης και να λαμβάνονται αποφάσεις με βάση δεδομένα αντί για υποθέσεις.
Συσχέτιση δεδομένων - η μεγαλύτερη αξία εμφανίζεται μαζί
Τα log, οι μετρικές και το tracing είναι χρήσιμα ξεχωριστά, αλλά η πραγματική τους αξία αποκαλύπτεται όταν μπορούν να συνδεθούν μεταξύ τους.
Ας φανταστούμε ότι ένα dashboard δείχνει ξαφνική αύξηση στον χρόνο απόκρισης. Η μετρική δείχνει πότε και σε ποια κλίμακα εμφανίστηκε το πρόβλημα. Το trace δείχνει ποιες λειτουργίες συνέθεταν το αργό αίτημα. Τα log επιτρέπουν να ελεγχθεί ποια γεγονότα συνέβησαν σε ένα συγκεκριμένο στάδιο.
Για να είναι αυτό δυνατό, το σύστημα πρέπει να μεταφέρει με συνέπεια το context του αιτήματος μεταξύ υπηρεσιών. Τα αναγνωριστικά trace και span μπορούν να χρησιμοποιηθούν για τη σύνδεση εγγραφών log με τα ίχνη. Αξίζει επίσης να διατηρούνται συνεπείς πληροφορίες για το όνομα της υπηρεσίας, το περιβάλλον, την έκδοση της εφαρμογής και άλλα attributes που περιγράφουν την προέλευση των δεδομένων.
Χωρίς συσχέτιση, η ομάδα μπορεί να έχει πρόσβαση σε πολλά dashboards, αρχεία και εργαλεία, αλλά να συνεχίζει να χάνει χρόνο σε χειροκίνητο προσδιορισμό του ποια γεγονότα συνδέονται μεταξύ τους. Το OpenTelemetry επισημαίνει τη συσχέτιση log, ίχνων και context πόρων ως σημαντικό στοιχείο για τη δημιουργία χρήσιμης τηλεμετρίας. <Cite ref="turn154932search1"/>
OpenTelemetry - κοινό πρότυπο για τα δεδομένα τηλεμετρίας
Η υλοποίηση του observability δεν χρειάζεται να σημαίνει εξάρτηση από έναν μόνο προμηθευτή εργαλείων. Μία από τις λύσεις που υποστηρίζουν τη διαλειτουργικότητα είναι το OpenTelemetry (OTel) - ένα ανοιχτό σύνολο προτύπων, API, βιβλιοθηκών και εργαλείων για instrumenting, παραγωγή, συλλογή και εξαγωγή δεδομένων τηλεμετρίας.
Το OpenTelemetry επιτρέπει σε μια εφαρμογή να εκπέμπει μετρικές, log και ίχνη σε ένα συνεπές μοντέλο. Τα δεδομένα μπορούν στη συνέχεια να προωθηθούν σε ένα επιλεγμένο observability backend, το οποίο είναι υπεύθυνο για την αποθήκευση, την αναζήτηση, την οπτικοποίηση και την ανάλυσή τους.
Ένα σημαντικό στοιχείο του οικοσυστήματος είναι το OpenTelemetry Collector. Μπορεί να λαμβάνει δεδομένα από διαφορετικές πηγές, να τα επεξεργάζεται, να τα εμπλουτίζει με επιπλέον context και να τα εξάγει σε ρυθμισμένα συστήματα. Έτσι η εφαρμογή δεν χρειάζεται να συνδέεται άμεσα με κάθε εργαλείο που χρησιμοποιείται για ανάλυση.
Αυτή η προσέγγιση είναι ιδιαίτερα χρήσιμη όταν μια εταιρεία χρησιμοποιεί πολλές τεχνολογίες, εξελίσσει την αρχιτεκτονική του συστήματος ή θέλει να διατηρήσει τη δυνατότητα αλλαγής παρόχου εργαλείων. Ωστόσο, το ίδιο το πρότυπο δεν παρέχει πλήρες observability. Χρειάζονται ακόμη σωστή instrumentazione, προσεγμένη στρατηγική συλλογής δεδομένων, κατάλληλα dashboards, alerts και διαδικασίες απόκρισης. <Cite ref="turn154932search3"/>
Πότε αξίζει να υλοποιηθεί το observability;
Το observability μπορεί να είναι χρήσιμο τόσο σε μεγάλα κατανεμημένα συστήματα όσο και σε μικρότερες εφαρμογές, όπου μια διακοπή λειτουργίας ή μια δύσκολα εντοπίσιμη βλάβη έχει σημαντικές επιχειρηματικές συνέπειες.
Αξίζει ιδιαίτερα να εξεταστεί αυτή η προσέγγιση όταν:
- η εφαρμογή αποτελείται από πολλές υπηρεσίες ή ενσωματώσεις,
- τα προβλήματα εμφανίζονται ακανόνιστα και είναι δύσκολο να αναπαραχθούν,
- οι χρήστες αναφέρουν σφάλματα που δεν φαίνονται σε τυπικές δοκιμές,
- ο χρόνος διάγνωσης των περιστατικών είναι υπερβολικά μεγάλος,
- οι επόμενες αναπτύξεις προκαλούν δύσκολα προβλέψιμες συνέπειες,
- η εταιρεία αναπτύσσει το σύστημα και χρειάζεται δεδομένα για τον σχεδιασμό της απόδοσης,
- η εφαρμογή υποστηρίζει κρίσιμες εμπορικές, επιχειρησιακές ή οικονομικές διαδικασίες,
- η ομάδα χρειάζεται να κατανοεί καλύτερα τον αντίκτυπο των εξωτερικών υπηρεσιών στη λειτουργία ολόκληρης της λύσης.
Αυτό όμως δεν σημαίνει ότι κάθε ιστοσελίδα χρειάζεται ένα εκτεταμένο περιβάλλον τηλεμετρίας. Σε ένα μικρό, απλό site επαρκούν βασικά logs, έλεγχος διαθεσιμότητας και μερικές βασικές μετρικές. Το εύρος της λύσης πρέπει να αντιστοιχεί στην πολυπλοκότητα της εφαρμογής, την κλίμακα της κίνησης, τις απαιτήσεις αξιοπιστίας και το κόστος πιθανών διακοπών.
Πότε το observability μπορεί να είναι υπερβολή σε σχέση με το περιεχόμενο;
Η υλοποίηση εκτεταμένων εργαλείων χωρίς σαφώς καθορισμένο στόχο μπορεί να φέρει περισσότερο κόστος παρά όφελος.
Στα πιο συνηθισμένα λάθη περιλαμβάνονται:
- Συλλογή όλων χωρίς σχέδιο. Η υπερβολή δεδομένων αυξάνει το κόστος και δυσκολεύει την αναζήτηση πληροφοριών σημαντικών για τη διάγνωση.
- Έλλειψη ερωτήσεων στις οποίες πρέπει να απαντά το σύστημα. Τα dashboards μπορεί να φαίνονται εντυπωσιακά, αλλά να μην βοηθούν στην επίλυση πραγματικών προβλημάτων.
- Alerting για κάθε απόκλιση. Ο υπερβολικός αριθμός ειδοποιήσεων προκαλεί κόπωση από alerts και αυξάνει τον κίνδυνο να μη γίνει αντιληπτό ένα περιστατικό.
- Έλλειψη ευθύνης για την απόκριση. Ακόμα και ένα καλά εντοπισμένο πρόβλημα μπορεί να διαρκέσει πολύ, αν κανείς δεν ξέρει ποιος πρέπει να το αναλάβει.
- Έλλειψη προστασίας δεδομένων. Η τηλεμετρία μπορεί να περιέχει ευαίσθητες πληροφορίες, αναγνωριστικά χρηστών ή λειτουργικά δεδομένα που απαιτούν περιορισμένη πρόσβαση και κατάλληλη διατήρηση.
- Παράβλεψη του κόστους της instrumentacji. Η συλλογή λεπτομερών traces και logs σε μεγάλη κλίμακα μπορεί να επηρεάσει την απόδοση της εφαρμογής και να δημιουργήσει σημαντικά κόστη αποθήκευσης και επεξεργασίας.
- Αντιμετώπιση του εργαλείου ως έτοιμης λύσης. Η απλή εγκατάσταση μιας πλατφόρμας δεν εξασφαλίζει σωστή instrumentacja ούτε αποτελεσματική διαδικασία διάγνωσης.
Το Observability απαιτεί λοιπόν όχι μόνο τεχνολογία, αλλά και οργανωτικές αποφάσεις: ποια δεδομένα χρειάζονται, ποιος τα αναλύει, πώς αντιδρά η ομάδα και με ποιον τρόπο τα συμπεράσματα από τα περιστατικά μεταφράζονται σε αλλαγές στο σύστημα.
Πώς να σχεδιάσετε την υλοποίηση του observability;
Το ασφαλέστερο είναι να αναπτύσσεται η παρατηρησιμότητα σταδιακά, ξεκινώντας από τις διαδικασίες και τις λειτουργίες των οποίων η βλάβη έχει τον μεγαλύτερο αντίκτυπο στους χρήστες και στην εταιρεία.
1. Καθορίστε τις βασικές επιχειρησιακές διαδικασίες
Εντοπίστε τις σημαντικότερες λειτουργίες, όπως η σύνδεση, η υποβολή παραγγελιών, οι πληρωμές, η δημιουργία εγγράφων ή ο συγχρονισμός δεδομένων. Αυτές πρέπει να αποτελέσουν το σημείο εκκίνησης για τον προσδιορισμό του τι σημαίνει σωστή λειτουργία της εφαρμογής.
2. Ορίστε δείκτες αξιοπιστίας
Επιλέξτε μετρικές που αποτυπώνουν την εμπειρία του χρήστη, για παράδειγμα τη διαθεσιμότητα βασικών λειτουργιών, τον χρόνο απόκρισης ή το ποσοστό των επιτυχημένων ενεργειών. Για σημαντικές υπηρεσίες μπορούν να οριστούν SLI (Service Level Indicator), δηλαδή δείκτης επιπέδου υπηρεσίας, και SLO (Service Level Objective), δηλαδή ο στόχος αυτού του δείκτη.
3. Φροντίστε για δομημένα logs
Ενοποιήστε τη μορφή των logs, τα επίπεδα σοβαρότητας και τα βασικά γνωρίσματα. Φροντίστε για αναγνωριστικά συσχέτισης και για πολιτική διαγραφής ή απόκρυψης ευαίσθητων δεδομένων. Τα logs πρέπει να είναι κατανοητά για την ομάδα και να μπορούν να επεξεργαστούν από εργαλεία.
4. Προσθέστε tracing σε κρίσιμες διαδρομές
Ξεκινήστε από διαδικασίες που περιλαμβάνουν πολλές υπηρεσίες, βάσεις δεδομένων ή εξωτερικές ενσωματώσεις. Παρακολουθήστε τη διαδρομή του αιτήματος μέσα στο σύστημα και φροντίστε για τη διάδοση του context μεταξύ των στοιχείων.
5. Δημιουργήστε dashboards γύρω από συγκεκριμένες ερωτήσεις
Αντί να δημιουργήσετε ένα τεράστιο panel, ετοιμάστε προβολές που απαντούν στις ανάγκες διαφορετικών ρόλων. Η τεχνική ομάδα μπορεί να χρειάζεται πληροφορίες για σφάλματα και καθυστερήσεις, ενώ ο ιδιοκτήτης προϊόντος - δεδομένα για την αποτελεσματικότητα βασικών διαδικασιών και τον αντίκτυπο των βλαβών στους χρήστες.
6. Σχεδιάστε alerts και διαδικασίες απόκρισης
Καθορίστε όρια, προτεραιότητες, υπεύθυνα άτομα και οδηγίες ενεργειών. Το alert πρέπει να περιέχει το context που βοηθά να ξεκινήσει γρήγορα η διάγνωση, και όχι απλώς να ενημερώνει για την υπέρβαση μιας τιμής.
7. Δοκιμάστε το observability
Ελέγξτε αν η ομάδα μπορεί να βρει την αιτία ενός ενδεικτικού σφάλματος με βάση τα διαθέσιμα δεδομένα. Μπορούν να πραγματοποιηθούν ελεγχόμενες δοκιμές βλαβών σε περιβάλλον δοκιμών ή ασκήσεις απόκρισης σε περιστατικά. Αξίζει επίσης να επαληθεύεται αν τα alerts ενεργοποιούνται όταν πρέπει.
8. Αναπτύξτε τη λύση με βάση τα περιστατικά
Μετά από κάθε σημαντικό πρόβλημα αξίζει να ελέγχετε ποιες πληροφορίες ήταν διαθέσιμες, τι έλειπε και πώς μπορεί να βελτιωθεί η instrumentacja, το alerting ή οι διαδικασίες. Το Observability δεν είναι εφάπαξ έργο, αλλά διαδικασία βελτίωσης της γνώσης για τη λειτουργία του συστήματος.
Κόστη και ασφάλεια - δύο πτυχές που δεν μπορούν να αγνοηθούν
Τα δεδομένα τηλεμετρίας έχουν το κόστος τους. Τα κόστη μπορεί να προκύπτουν από την instrumentacja, τη μεταφορά, το indexing, την αποθήκευση, τη διατήρηση και την ανάλυση δεδομένων. Σε συστήματα με μεγάλη κίνηση, ιδιαίτερα δαπανηρή μπορεί να είναι η συλλογή όλων των traces ή πολύ λεπτομερών logs.
Γι’ αυτό αξίζει να εφαρμόζονται retention προσαρμοσμένα στις ανάγκες, φιλτράρισμα δεδομένων, sampling των traces και διαφορετικά επίπεδα λεπτομέρειας ανάλογα με το περιβάλλον. Για παράδειγμα, ένα παραγωγικό σύστημα μπορεί να συλλέγει πλήρη δεδομένα για σφάλματα και επιλεγμένες κρίσιμες λειτουργίες, ενώ ένα μέρος των σωστών αιτημάτων να δειγματοληπτείται ώστε να περιορίζεται ο όγκος.
Εξίσου σημαντική είναι η προστασία των δεδομένων. Τα logs και τα traces μπορεί άθελά τους να περιέχουν προσωπικά δεδομένα, αναγνωριστικά συνεδρίας, αποσπάσματα ερωτημάτων ή πληροφορίες για τη δομή της υποδομής. Πρέπει να περιορίζεται η πρόσβαση στην τηλεμετρία, να αφαιρούνται τα περιττά δεδομένα, να αποκρύπτονται οι ευαίσθητες πληροφορίες και να ελέγχονται οι περίοδοι διατήρησης. Αξίζει επίσης να αντιμετωπίζονται τα συστήματα observability ως στοιχείο του παραγωγικού περιβάλλοντος, που και τα ίδια χρειάζονται μέτρα προστασίας, αντίγραφα ασφαλείας και έλεγχο δικαιωμάτων.
Observability ως εργαλείο διαχείρισης, όχι μόνο διάγνωσης
Παρότι η παρατηρησιμότητα συνήθως συνδέεται με το έργο των προγραμματιστών, του DevOps και των διαχειριστών, η αξία της ξεπερνά το πεδίο της πληροφορικής.
Τα δεδομένα για τον χρόνο απόκρισης, τα σφάλματα, τη διαθεσιμότητα και την αποτελεσματικότητα των διαδικασιών μπορούν να βοηθήσουν την εταιρεία να κατανοήσει ποια στοιχεία της τεχνολογίας υποστηρίζουν τη δραστηριότητα και ποια την περιορίζουν. Επιτρέπουν την ταυτοποίηση επαναλαμβανόμενων προβλημάτων, την αξιολόγηση των συνεπειών των αλλαγών και τον σχεδιασμό της ανάπτυξης με βάση την πραγματική συμπεριφορά του συστήματος.
Αν, για παράδειγμα, το σύστημα παραγγελιών επιβραδύνεται τακτικά σε συγκεκριμένες ώρες, τα δεδομένα τηλεμετρίας μπορούν να βοηθήσουν να διαπιστωθεί αν χρειάζεται βελτιστοποίηση των ερωτημάτων, αλλαγή του τρόπου επεξεργασίας των εργασιών ή επέκταση της υποδομής. Αντί να επενδύει σε επιπλέον πόρους με βάση τη διαίσθηση, η εταιρεία μπορεί πρώτα να εντοπίσει το πραγματικό bottleneck.
Το observability υποστηρίζει επίσης την ανάλυση των επιπτώσεων των υλοποιήσεων. Η σύγκριση μετρικών, traces και logs πριν από την αλλαγή και μετά από αυτήν επιτρέπει τον ταχύτερο εντοπισμό παλινδρομήσεων και την εκτίμηση του κατά πόσο η ενημέρωση έφερε το αναμενόμενο αποτέλεσμα.
Δεν πρέπει όμως να ταυτίζουμε την παρατηρησιμότητα με την αυτόματη λήψη αποφάσεων. Τα δεδομένα δείχνουν τη συμπεριφορά του συστήματος, αλλά η ερμηνεία τους απαιτεί γνώση της αρχιτεκτονικής, των επιχειρηματικών διαδικασιών και του πλαισίου του συγκεκριμένου συμβάντος.
Γλωσσάρι όρων
- Observability (παρατηρησιμότητα) - η ικανότητα κατανόησης της εσωτερικής συμπεριφοράς ενός συστήματος με βάση τα δεδομένα που εκπέμπει.
- Monitoring - η συνεχής παρακολούθηση επιλεγμένων παραμέτρων και ο εντοπισμός καθορισμένων καταστάσεων που απαιτούν προσοχή.
- Telemetry (τηλεμετρία) - δεδομένα που συλλέγονται και μεταδίδονται από την εφαρμογή και την υποδομή με σκοπό την ανάλυση της λειτουργίας τους.
- Logs (αρχεία καταγραφής) - καταγραφές συμβάντων που εμφανίζονται στην εφαρμογή ή στην υποδομή.
- Metrics (μετρικές) - αριθμητικές μετρήσεις της κατάστασης, της απόδοσης ή της συμπεριφοράς του συστήματος στο χρόνο.
- Tracing - η παρακολούθηση της πορείας των λειτουργιών μέσα από τα στοιχεία της εφαρμογής.
- Distributed tracing - η παρακολούθηση ενός μεμονωμένου αιτήματος σε ένα σύστημα που αποτελείται από πολλές υπηρεσίες ή διεργασίες.
- Span - η καταγραφή μιας μεμονωμένης λειτουργίας που αποτελεί μέρος ενός trace.
- Trace - ένα σύνολο σχετιζόμενων spans που παρουσιάζουν την πορεία μιας λειτουργίας.
- Alert - ειδοποίηση για μια ανιχνευμένη κατάσταση ή συμβάν που απαιτεί αντίδραση.
- SLI - δείκτης που μετρά μια συγκεκριμένη πτυχή της λειτουργίας μιας υπηρεσίας.
- SLO - ένας καθορισμένος στόχος για έναν επιλεγμένο δείκτη αξιοπιστίας.
- Sampling - τεχνική περιορισμού του αριθμού των συλλεγόμενων τηλεμετρικών δεδομένων μέσω της επιλογής ενός αντιπροσωπευτικού μέρους των συμβάντων.
- OpenTelemetry - ένα ανοιχτό σύνολο προτύπων και εργαλείων που υποστηρίζουν την οργάνωση και την εξαγωγή τηλεμετρικών δεδομένων.
Σύνοψη
Η βλάβη μιας εφαρμογής δεν ξεκινά πάντα από έναν μη διαθέσιμο διακομιστή ή από ένα μήνυμα σφάλματος. Μερικές φορές το σύστημα λειτουργεί τυπικά, αλλά μια βασική λειτουργία γίνεται υπερβολικά αργή, μέρος των συναλλαγών δεν ολοκληρώνεται επιτυχώς ή η διασύνδεση αποτυγχάνει μόνο υπό συγκεκριμένες συνθήκες.
Το monitoring βοηθά στον εντοπισμό ανωμαλιών. Το observability επιτρέπει να κατανοήσουμε τι οδήγησε στην εμφάνισή τους και ποια ήταν η επίδρασή τους στη λειτουργία της εφαρμογής. Τα logs, οι μετρικές, το tracing και οι σωστά σχεδιασμένες ειδοποιήσεις δημιουργούν μαζί τη βάση για πιο αποτελεσματική διάγνωση, συνειδητή ανάπτυξη και μείωση του επιχειρησιακού κινδύνου.
Δεν πρόκειται να συλλέγουμε όσο το δυνατόν περισσότερα δεδομένα ούτε να δημιουργούμε τα πιο σύνθετα dashboards. Πρόκειται για το να μην ρωτάμε, τη στιγμή που εμφανίζεται ένα πρόβλημα, μόνο: «Λειτουργεί το σύστημα;», αλλά να μπορούμε να προσδιορίσουμε: «Τι ακριβώς συνέβη στο σύστημα, γιατί και τι πρέπει να κάνουμε στη συνέχεια;»
Μια ώριμη εφαρμογή δεν είναι μόνο αυτή που λειτουργεί. Είναι επίσης αυτή της οποίας η συμπεριφορά μπορεί να γίνει κατανοητή, να διαγνωστεί και να βελτιωθεί.
