Σημείωση. μετάφρ.: Ο συγγραφέας αυτού του υλικού είναι η Cindy Sridharan, μηχανικός στο imgix που ειδικεύεται στην ανάπτυξη API και, ειδικότερα, στις δοκιμές μικροϋπηρεσιών. Σε αυτό το υλικό, μοιράζεται το λεπτομερές όραμά της για τα τρέχοντα προβλήματα στον τομέα της κατανεμημένης ανίχνευσης, όπου, κατά τη γνώμη της, υπάρχει έλλειψη πραγματικά αποτελεσματικών εργαλείων για την επίλυση πιεστικών προβλημάτων.
[Η εικονογράφηση λαμβάνεται από σχετικά με την κατανεμημένη ιχνηλάτηση.]
Πιστεύεται ότι δύσκολο να εφαρμοστεί και η απόδοση σε αυτό . Υπάρχουν πολλοί λόγοι για τους οποίους η ανίχνευση είναι προβληματική, αναφέροντας συχνά την εργασία που απαιτείται για τη διαμόρφωση κάθε στοιχείου συστήματος για τη μετάδοση των κατάλληλων κεφαλίδων με κάθε αίτημα. Αν και αυτό το πρόβλημα υπάρχει, δεν είναι σε καμία περίπτωση ανυπέρβλητο. Παρεμπιπτόντως, δεν εξηγεί γιατί στους προγραμματιστές δεν αρέσει πραγματικά η ανίχνευση (ακόμα και όταν λειτουργεί ήδη).
Η κύρια πρόκληση με την κατανεμημένη ανίχνευση δεν είναι η συλλογή δεδομένων, η τυποποίηση μορφών για τη διανομή και παρουσίαση των αποτελεσμάτων ή ο καθορισμός του πότε, πού και πώς γίνεται η δειγματοληψία. Δεν προσπαθώ να φανταστώ ασήμαντος αυτά τα "προβλήματα κατανοητότητας" είναι, στην πραγματικότητα, αρκετά σημαντικά τεχνικά και (αν εξετάζουμε πραγματικά το ανοιχτό κώδικα) ) πολιτικές προκλήσεις που πρέπει να ξεπεραστούν ώστε αυτά τα προβλήματα να θεωρηθούν λυμένα.
Ωστόσο, αν φανταστούμε ότι όλα αυτά τα προβλήματα έχουν λυθεί, υπάρχει μεγάλη πιθανότητα ότι τίποτα δεν θα αλλάξει σημαντικά όσον αφορά εμπειρία τελικού χρήστη. Η ανίχνευση μπορεί να εξακολουθεί να μην είναι πρακτική χρήση στα πιο συνηθισμένα σενάρια εντοπισμού σφαλμάτων—ακόμα και μετά την ανάπτυξή της.
Ένα τόσο διαφορετικό ίχνος
Η κατανεμημένη ανίχνευση περιλαμβάνει διάφορα ανόμοια στοιχεία:
- Εξοπλισμός εφαρμογών και ενδιάμεσων λογισμικών με εργαλεία ελέγχου.
- κατανεμημένη μεταφορά περιβάλλοντος.
- συλλογή ιχνών?
- αποθήκευση ιχνών.
- εξαγωγή και οπτικοποίηση τους.
Η πολλή συζήτηση για την κατανεμημένη ανίχνευση τείνει να την αντιμετωπίζει ως ένα είδος μη ενιαίας λειτουργίας της οποίας ο μοναδικός σκοπός είναι να βοηθήσει στην πλήρη διάγνωση του συστήματος. Αυτό οφείλεται σε μεγάλο βαθμό στον τρόπο με τον οποίο έχουν διαμορφωθεί ιστορικά οι ιδέες για την κατανεμημένη ανίχνευση. ΣΕ , που έγινε όταν άνοιξαν οι πηγές Zipkin, αναφέρθηκε ότι αυτό [Zipkin] κάνει το Twitter πιο γρήγορο. Οι πρώτες εμπορικές προσφορές για ιχνηλάτηση προωθήθηκαν επίσης ως .
Σημείωση. μετάφρ.: Για να γίνει πιο κατανοητό το περαιτέρω κείμενο, ας ορίσουμε δύο βασικούς όρους ανάλογα :
- Span — το βασικό στοιχείο της κατανεμημένης ανίχνευσης. Είναι μια περιγραφή μιας συγκεκριμένης ροής εργασίας (για παράδειγμα, ένα ερώτημα βάσης δεδομένων) με όνομα, ώρες έναρξης και λήξης, ετικέτες, αρχεία καταγραφής και περιβάλλον.
- Τα διαστήματα συνήθως περιέχουν συνδέσμους προς άλλα ανοίγματα, επιτρέποντας τον συνδυασμό πολλαπλών διαστημάτων Ιχνος — οπτικοποίηση της διάρκειας ζωής ενός αιτήματος καθώς κινείται μέσα από ένα κατανεμημένο σύστημα.
Τα ίχνη περιέχουν απίστευτα πολύτιμα δεδομένα που μπορούν να βοηθήσουν σε εργασίες όπως δοκιμές παραγωγής, δοκιμές αποκατάστασης καταστροφών, δοκιμές έγχυσης σφαλμάτων κ.λπ. Στην πραγματικότητα, ορισμένες εταιρείες χρησιμοποιούν ήδη την ανίχνευση για παρόμοιους σκοπούς. Ας ξεκινήσουμε με έχει και άλλες χρήσεις εκτός από την απλή μετακίνηση διαστημάτων στο σύστημα αποθήκευσης:
- Για παράδειγμα, η Uber ανίχνευση αποτελεσμάτων για τη διαφοροποίηση μεταξύ δοκιμαστικής κυκλοφορίας και κυκλοφορίας παραγωγής.
- Facebook δεδομένα ανίχνευσης για ανάλυση κρίσιμης διαδρομής και για εναλλαγή κυκλοφορίας κατά τη διάρκεια τακτικών δοκιμών αποκατάστασης από καταστροφές.
- Επίσης κοινωνικό δίκτυο Σημειωματάρια Jupyter που επιτρέπουν στους προγραμματιστές να εκτελούν αυθαίρετα ερωτήματα σε αποτελέσματα ιχνών.
- Υποστηρικτές (Έγχυση αποτυχίας με γνώμονα τη σειρά) κατανεμημένα ίχνη για δοκιμή με έγχυση σφάλματος.
Καμία από τις επιλογές που αναφέρονται παραπάνω δεν ισχύει πλήρως για το σενάριο αποσφαλμάτωση, κατά την οποία ο μηχανικός προσπαθεί να λύσει το πρόβλημα κοιτάζοντας το ίχνος.
Οταν έρθει Ακόμη φτάνει στο σενάριο εντοπισμού σφαλμάτων, η κύρια διεπαφή παραμένει το διάγραμμα traceview (αν και κάποιοι το αποκαλούν επίσης "Gantt διάγραμμα" ή "διάγραμμα καταρράκτη"). Κάτω από traceview я όλα τα ανοίγματα και τα συνοδευτικά μεταδεδομένα που μαζί συνθέτουν το ίχνος. Κάθε σύστημα εντοπισμού ανοιχτού κώδικα, καθώς και κάθε εμπορική λύση εντοπισμού, προσφέρει α traceview διεπαφή χρήστη για οπτικοποίηση, λεπτομέρεια και φιλτράρισμα ιχνών.
Το πρόβλημα με όλα τα συστήματα ανίχνευσης που έχω δει μέχρι τώρα είναι ότι το αποτέλεσμα οπτικοποίηση (traceview) αντανακλά σχεδόν πλήρως τα χαρακτηριστικά της διαδικασίας δημιουργίας ίχνους. Ακόμη και όταν προτείνονται εναλλακτικές απεικονίσεις: χάρτες θερμότητας, τοπολογίες υπηρεσιών, ιστογράμματα λανθάνοντος χρόνου, τελικά καταλήγουν σε traceview.
Στο παρελθόν Ι ότι οι περισσότερες "καινοτομίες" στην ανίχνευση UI/UX φαίνεται να περιορίζονται πρόσθετα μεταδεδομένα σε ίχνος, επενδύοντας σε αυτά πληροφορίες με υψηλή ταυτότητα (υψηλή καρδιναλικότητα) ή παρέχοντας τη δυνατότητα διερεύνησης συγκεκριμένων διαστημάτων ή εκτέλεσης ερωτημάτων ενδο- και ενδο-ίχνος... Εν traceview παραμένει το κύριο εργαλείο οπτικοποίησης. Όσο συνεχίζεται αυτή η κατάσταση, η κατανεμημένη ανίχνευση θα καταλαμβάνει (στην καλύτερη περίπτωση) την 4η θέση ως εργαλείο εντοπισμού σφαλμάτων, μετά από μετρήσεις, αρχεία καταγραφής και ίχνη στοίβας, και στη χειρότερη θα αποδειχθεί σπατάλη χρημάτων και χρόνου.
Πρόβλημα με το traceview
Σκοπός traceview — παρέχει μια πλήρη εικόνα της κίνησης ενός μεμονωμένου αιτήματος σε όλα τα στοιχεία του κατανεμημένου συστήματος με το οποίο σχετίζεται. Ορισμένα πιο προηγμένα συστήματα ανίχνευσης σάς επιτρέπουν να διερευνήσετε μεμονωμένα διαστήματα και να δείτε μια ανάλυση με την πάροδο του χρόνου μέσα μία διαδικασία (όταν τα ανοίγματα έχουν λειτουργικά όρια).
Η βασική προϋπόθεση της αρχιτεκτονικής των microservices είναι η ιδέα ότι η οργανωτική δομή μεγαλώνει ανάλογα με τις ανάγκες της εταιρείας. Οι υποστηρικτές των microservices υποστηρίζουν ότι η διανομή διαφόρων επιχειρηματικών εργασιών σε μεμονωμένες υπηρεσίες επιτρέπει σε μικρές, αυτόνομες ομάδες ανάπτυξης να ελέγχουν ολόκληρο τον κύκλο ζωής τέτοιων υπηρεσιών, δίνοντάς τους τη δυνατότητα να δημιουργούν, να δοκιμάζουν και να αναπτύσσουν ανεξάρτητα αυτές τις υπηρεσίες. Ωστόσο, το μειονέκτημα αυτής της διανομής είναι η απώλεια πληροφοριών σχετικά με το πώς κάθε υπηρεσία αλληλεπιδρά με άλλες. Σε τέτοιες συνθήκες, η κατανεμημένη ανίχνευση ισχυρίζεται ότι είναι ένα απαραίτητο εργαλείο για αποσφαλμάτωση σύνθετες αλληλεπιδράσεις μεταξύ των υπηρεσιών.
Αν πραγματικά , τότε ούτε ένας άνθρωπος δεν μπορεί να το κρατήσει στο κεφάλι του πλήρης εικόνα. Στην πραγματικότητα, η ανάπτυξη ενός εργαλείου που βασίζεται στην υπόθεση ότι είναι ακόμη δυνατό είναι κάτι σαν αντι-μοτίβο (μια αναποτελεσματική και μη παραγωγική προσέγγιση). Στην ιδανική περίπτωση, ο εντοπισμός σφαλμάτων απαιτεί ένα εργαλείο που βοηθάει περιορίστε την περιοχή αναζήτησής σας, έτσι ώστε οι μηχανικοί να μπορούν να επικεντρωθούν σε ένα υποσύνολο διαστάσεων (υπηρεσίες/χρήστες/κεντρικοί υπολογιστές κ.λπ.) που σχετίζονται με το υπό εξέταση σενάριο προβλήματος. Κατά τον προσδιορισμό της αιτίας μιας βλάβης, οι μηχανικοί δεν απαιτείται να κατανοήσουν τι συνέβη κατά τη διάρκεια της όλες οι υπηρεσίες ταυτόχρονα, καθώς μια τέτοια απαίτηση θα έρχονταν σε αντίθεση με την ίδια την ιδέα της αρχιτεκτονικής μικροϋπηρεσιών.
Ωστόσο, το traceview είναι δηλαδή Αυτό. Ναι, ορισμένα συστήματα ανίχνευσης προσφέρουν συμπιεσμένες προβολές ανίχνευσης όταν ο αριθμός των διαστημάτων στο ίχνος είναι τόσο μεγάλος που δεν μπορούν να εμφανιστούν σε μία απεικόνιση. Ωστόσο, λόγω του μεγάλου όγκου πληροφοριών που περιέχονται ακόμη και σε μια τέτοια απογυμνωμένη απεικόνιση, οι μηχανικοί εξακολουθούν να αναγκαστικά «Κοσκινίστε» το, περιορίζοντας χειροκίνητα την επιλογή σε ένα σύνολο υπηρεσιών που αποτελούν πηγές προβλημάτων. Δυστυχώς, σε αυτόν τον τομέα, οι μηχανές είναι πολύ πιο γρήγορες από τους ανθρώπους, λιγότερο επιρρεπείς σε σφάλματα και τα αποτελέσματά τους είναι πιο επαναλαμβανόμενα.
Ένας άλλος λόγος που πιστεύω ότι το traceview είναι λάθος είναι επειδή δεν είναι καλό για εντοπισμό σφαλμάτων που βασίζεται σε υποθέσεις. Στον πυρήνα του, ο εντοπισμός σφαλμάτων είναι επαναληπτικός μια διαδικασία που ξεκινά με μια υπόθεση, ακολουθούμενη από επαλήθευση διαφόρων παρατηρήσεων και γεγονότων που λαμβάνονται από το σύστημα κατά μήκος διαφορετικών διανυσμάτων, συμπεράσματα/γενικεύσεις και περαιτέρω αξιολόγηση της αλήθειας της υπόθεσης.
Ευκαιρία γρήγορα και φθηνά ο έλεγχος υποθέσεων και η αναλόγως βελτίωση του νοητικού μοντέλου είναι ακρωγωνιαίος λίθος αποσφαλμάτωση Οποιοδήποτε εργαλείο εντοπισμού σφαλμάτων θα πρέπει να είναι διαδραστικό και περιορίστε τον χώρο αναζήτησης ή, σε περίπτωση ψευδούς δυνητικού πελάτη, επιτρέψτε στον χρήστη να επιστρέψει και να εστιάσει σε διαφορετική περιοχή του συστήματος. Το τέλειο εργαλείο θα το κάνει αυτό προληπτικά, εφιστώντας αμέσως την προσοχή του χρήστη σε πιθανές προβληματικές περιοχές.
Αλίμονο, traceview δεν μπορεί να ονομαστεί εργαλείο με διαδραστική διεπαφή. Το καλύτερο που μπορείτε να ελπίζετε όταν το χρησιμοποιείτε είναι να βρείτε κάποια πηγή αυξημένου λανθάνοντος χρόνου και να δείτε όλες τις πιθανές ετικέτες και αρχεία καταγραφής που σχετίζονται με αυτό. Αυτό δεν βοηθά τον μηχανικό να αναγνωρίσει μοτίβα στην κυκλοφορία, όπως οι ιδιαιτερότητες της κατανομής καθυστέρησης, ή ανίχνευση συσχετίσεων μεταξύ διαφορετικών μετρήσεων. μπορεί να βοηθήσει στην αντιμετώπιση ορισμένων από αυτά τα προβλήματα. Πραγματικά, επιτυχημένη ανάλυση με χρήση μηχανικής μάθησης για τον εντοπισμό ανώμαλων περιοχών και τον εντοπισμό ενός υποσυνόλου ετικετών που μπορεί να σχετίζονται με ανώμαλη συμπεριφορά. Ωστόσο, δεν έχω δει ακόμη συναρπαστικές απεικονίσεις ευρημάτων μηχανικής μάθησης ή εξόρυξης δεδομένων που εφαρμόζονται σε εύρη που διαφέρουν σημαντικά από μια παρακολούθηση παρακολούθησης ή ένα DAG (κατευθυνόμενο άκυκλο γράφημα).
Τα ανοίγματα είναι πολύ χαμηλά
Το θεμελιώδες πρόβλημα με το traceview είναι αυτό εκτείνεται είναι πολύ χαμηλού επιπέδου πρωτόγονα τόσο για ανάλυση λανθάνουσας κατάστασης όσο και για ανάλυση βασικής αιτίας. Είναι σαν να αναλύετε μεμονωμένες εντολές επεξεργαστή για να προσπαθήσετε να επιλύσετε μια εξαίρεση, γνωρίζοντας ότι υπάρχουν πολύ υψηλότερου επιπέδου εργαλεία όπως το backtrace με τα οποία είναι πολύ πιο βολικό να εργαστείτε.
Επιπλέον, θα πάρω την ελευθερία να υποστηρίξω τα εξής: ιδανικά, δεν χρειαζόμαστε πλήρη εικόνα συνέβη κατά τη διάρκεια του κύκλου ζωής του αιτήματος, ο οποίος αντιπροσωπεύεται από σύγχρονα εργαλεία ανίχνευσης. Αντίθετα, απαιτείται κάποια μορφή αφαίρεσης υψηλότερου επιπέδου που περιέχει πληροφορίες για το τι πήγε στραβά (παρόμοιο με το backtrace), μαζί με κάποιο πλαίσιο. Αντί να παρακολουθώ ολόκληρο το ίχνος, προτιμώ να το δω часть, όπου συμβαίνει κάτι ενδιαφέρον ή ασυνήθιστο. Επί του παρόντος, η αναζήτηση πραγματοποιείται χειροκίνητα: ο μηχανικός λαμβάνει το ίχνος και αναλύει ανεξάρτητα τα ανοίγματα αναζητώντας κάτι ενδιαφέρον. Η προσέγγιση των ατόμων που κοιτάζουν τα πεδία σε μεμονωμένα ίχνη με την ελπίδα να ανιχνεύσουν ύποπτη δραστηριότητα δεν κλιμακώνεται καθόλου (ειδικά όταν πρέπει να κατανοήσουν όλα τα μεταδεδομένα που κωδικοποιούνται σε διαφορετικά πεδία, όπως αναγνωριστικό εύρους, όνομα μεθόδου RPC, διάρκεια περιόδου «α, αρχεία καταγραφής, ετικέτες, κ.λπ.).
Εναλλακτικές λύσεις για το traceview
Τα αποτελέσματα ανίχνευσης είναι πιο χρήσιμα όταν μπορούν να οπτικοποιηθούν με τρόπο που να παρέχει μη ασήμαντη εικόνα για το τι συμβαίνει σε διασυνδεδεμένα μέρη του συστήματος. Μέχρι να συμβεί αυτό, η διαδικασία εντοπισμού σφαλμάτων παραμένει σε μεγάλο βαθμό αδρανής και εξαρτάται από την ικανότητα του χρήστη να παρατηρεί τις σωστές συσχετίσεις, να ελέγχει τα σωστά μέρη του συστήματος ή να ενώνει τα κομμάτια του παζλ - σε αντίθεση με εργαλείο, βοηθώντας τον χρήστη να διατυπώσει αυτές τις υποθέσεις.
Δεν είμαι οπτικός σχεδιαστής ή ειδικός στο UX, αλλά στην επόμενη ενότητα θέλω να μοιραστώ μερικές ιδέες για το πώς μπορεί να μοιάζουν αυτές οι απεικονίσεις.
Εστίαση σε συγκεκριμένες υπηρεσίες
Την ώρα που ο κλάδος εδραιώνεται γύρω από τις ιδέες , φαίνεται λογικό οι μεμονωμένες ομάδες να δίνουν προτεραιότητα στο να διασφαλίζουν ότι οι υπηρεσίες τους είναι ευθυγραμμισμένες με αυτούς τους στόχους. Από αυτό προκύπτει ότι προσανατολισμένη στις υπηρεσίες Η οπτικοποίηση είναι η καταλληλότερη για τέτοιες ομάδες.
Τα ίχνη, ειδικά χωρίς δειγματοληψία, είναι ένας θησαυρός πληροφοριών για κάθε στοιχείο ενός κατανεμημένου συστήματος. Αυτές οι πληροφορίες μπορούν να τροφοδοτηθούν σε έναν πονηρό επεξεργαστή που θα παρέχει στους χρήστες προσανατολισμένη στις υπηρεσίες ευρήματα. Μπορούν να αναγνωριστούν εκ των προτέρων - ακόμη και πριν ο χρήστης κοιτάξει τα ίχνη:
- Διαγράμματα διανομής λανθάνοντος χρόνου μόνο για εξαιρετικά εμφανή αιτήματα (εξαιρετικά αιτήματα);
- Διαγράμματα κατανομής καθυστέρησης για περιπτώσεις που δεν επιτυγχάνονται οι στόχοι της υπηρεσίας SLO.
- Οι πιο «κοινές», «ενδιαφέρουσες» και «περίεργες» ετικέτες σε ερωτήματα που τις περισσότερες φορές επαναλαμβάνονται;
- Ανάλυση καθυστέρησης για περιπτώσεις όπου зависимости οι υπηρεσίες δεν επιτυγχάνουν τους στόχους τους SLO·
- Ανάλυση λανθάνοντος χρόνου για διάφορες υπηρεσίες κατάντη.
Μερικές από αυτές τις ερωτήσεις απλώς δεν απαντώνται με ενσωματωμένες μετρήσεις, αναγκάζοντας τους χρήστες να ελέγχουν εξονυχιστικά τις εκτάσεις. Ως αποτέλεσμα, έχουμε έναν εξαιρετικά εχθρικό μηχανισμό για τον χρήστη.
Αυτό εγείρει το ερώτημα: τι γίνεται με τις περίπλοκες αλληλεπιδράσεις μεταξύ διαφορετικών υπηρεσιών που ελέγχονται από διαφορετικές ομάδες; Δεν είναι traceview δεν θεωρείται το καταλληλότερο εργαλείο για την ανάδειξη μιας τέτοιας κατάστασης;
Οι προγραμματιστές κινητών τηλεφώνων, οι κάτοχοι υπηρεσιών ανιθαγενών, οι κάτοχοι διαχειριζόμενων κρατικών υπηρεσιών (όπως οι βάσεις δεδομένων) και οι κάτοχοι πλατφορμών μπορεί να ενδιαφέρονται για κάτι άλλο παρουσίαση κατανεμημένο σύστημα? traceview είναι μια πολύ γενική λύση για αυτές τις θεμελιωδώς διαφορετικές ανάγκες. Ακόμη και σε μια πολύ περίπλοκη αρχιτεκτονική μικροϋπηρεσιών, οι ιδιοκτήτες υπηρεσιών δεν χρειάζονται βαθιά γνώση περισσότερων από δύο ή τριών υπηρεσιών ανάντη και κατάντη. Ουσιαστικά, στα περισσότερα σενάρια, οι χρήστες χρειάζεται μόνο να απαντήσουν σε ερωτήσεις που αφορούν περιορισμένο σύνολο υπηρεσιών.
Είναι σαν να βλέπεις ένα μικρό υποσύνολο υπηρεσιών μέσω ενός μεγεθυντικού φακού για να το εξετάσεις εξονυχιστικά. Αυτό θα επιτρέψει στον χρήστη να κάνει πιο πιεστικές ερωτήσεις σχετικά με τις πολύπλοκες αλληλεπιδράσεις μεταξύ αυτών των υπηρεσιών και τις άμεσες εξαρτήσεις τους. Αυτό είναι παρόμοιο με το backtrace στον κόσμο των υπηρεσιών, όπου ο μηχανικός γνωρίζει ότι λάθος, και έχει επίσης κάποια κατανόηση του τι συμβαίνει στις γύρω υπηρεσίες γιατί.
Η προσέγγιση που προωθώ είναι ακριβώς το αντίθετο από την προσέγγιση από πάνω προς τα κάτω, βασισμένη σε ιχνηλασία, όπου η ανάλυση ξεκινά με ολόκληρο το ίχνος και στη συνέχεια καταλήγει σταδιακά σε μεμονωμένες εκτάσεις. Αντίθετα, μια προσέγγιση από κάτω προς τα πάνω ξεκινά με την ανάλυση μιας μικρής περιοχής κοντά στην πιθανή αιτία του συμβάντος και στη συνέχεια επεκτείνει τον χώρο αναζήτησης όπως απαιτείται (με τη δυνατότητα να έρθουν άλλες ομάδες για να αναλύσουν ένα ευρύτερο φάσμα υπηρεσιών). Η δεύτερη προσέγγιση είναι πιο κατάλληλη για τον γρήγορο έλεγχο των αρχικών υποθέσεων. Μόλις ληφθούν συγκεκριμένα αποτελέσματα, θα είναι δυνατό να προχωρήσουμε σε μια πιο στοχευμένη και λεπτομερή ανάλυση.
Κατασκευή τοπολογίας
Οι προβολές για συγκεκριμένες υπηρεσίες μπορεί να είναι απίστευτα χρήσιμες εάν ο χρήστης γνωρίζει τι μια υπηρεσία ή μια ομάδα υπηρεσιών είναι υπεύθυνη για την αύξηση του λανθάνοντος χρόνου ή την πρόκληση σφαλμάτων. Ωστόσο, σε ένα περίπλοκο σύστημα, η αναγνώριση της υπηρεσίας που παραβιάζει μπορεί να είναι μια μη τετριμμένη εργασία κατά τη διάρκεια μιας αποτυχίας, ειδικά εάν δεν αναφέρθηκαν μηνύματα σφάλματος από τις υπηρεσίες.
Η δημιουργία μιας τοπολογίας υπηρεσίας μπορεί να βοηθήσει πολύ στο να καταλάβουμε ποια υπηρεσία παρουσιάζει αύξηση στα ποσοστά σφαλμάτων ή αύξηση του λανθάνοντος χρόνου που προκαλεί αισθητή υποβάθμιση της υπηρεσίας. Όταν μιλάω για κατασκευή τοπολογίας, δεν εννοώ χάρτης υπηρεσιών, εμφανίζοντας κάθε υπηρεσία που είναι διαθέσιμη στο σύστημα και είναι γνωστή για αυτήν . Αυτή η προβολή δεν είναι καλύτερη από την παρακολούθηση παρακολούθησης που βασίζεται σε ένα κατευθυνόμενο άκυκλο γράφημα. Αντίθετα θα ήθελα να δω δυναμικά δημιουργημένη τοπολογία υπηρεσίας, με βάση ορισμένα χαρακτηριστικά, όπως το ποσοστό σφάλματος, ο χρόνος απόκρισης ή οποιαδήποτε παράμετρος που καθορίζεται από το χρήστη που βοηθά στην αποσαφήνιση της κατάστασης με συγκεκριμένες ύποπτες υπηρεσίες.
Ας πάρουμε ένα παράδειγμα. Ας φανταστούμε ένα υποθετικό ειδησεογραφικό site. Υπηρεσία αρχικής σελίδας (εξώφυλλο) ανταλλάσσει δεδομένα με τη Redis, με μια υπηρεσία συστάσεων, με μια υπηρεσία διαφήμισης και μια υπηρεσία βίντεο. Η υπηρεσία βίντεο λαμβάνει βίντεο από το S3 και μεταδεδομένα από το DynamoDB. Η υπηρεσία συστάσεων λαμβάνει μεταδεδομένα από το DynamoDB, φορτώνει δεδομένα από το Redis και τη MySQL και γράφει μηνύματα στον Κάφκα. Η διαφημιστική υπηρεσία λαμβάνει δεδομένα από τη MySQL και γράφει μηνύματα στον Κάφκα.
Παρακάτω είναι μια σχηματική αναπαράσταση αυτής της τοπολογίας (πολλά εμπορικά προγράμματα δρομολόγησης δημιουργούν την τοπολογία). Μπορεί να είναι χρήσιμο εάν πρέπει να κατανοήσετε τις εξαρτήσεις των υπηρεσιών. Ωστόσο, κατά τη διάρκεια αποσφαλμάτωση, όταν μια συγκεκριμένη υπηρεσία (ας πούμε, μια υπηρεσία βίντεο) εμφανίζει αυξημένο χρόνο απόκρισης, μια τέτοια τοπολογία δεν είναι πολύ χρήσιμη.
Διάγραμμα εξυπηρέτησης υποθετικού ειδησεογραφικού ιστότοπου
Το παρακάτω διάγραμμα θα ταιριάζει καλύτερα. Υπάρχει πρόβλημα με την υπηρεσία (βίντεο) απεικονίζεται ακριβώς στο κέντρο. Ο χρήστης το παρατηρεί αμέσως. Από αυτήν την οπτικοποίηση, γίνεται σαφές ότι η υπηρεσία βίντεο λειτουργεί ανώμαλα λόγω της αύξησης του χρόνου απόκρισης S3, η οποία επηρεάζει την ταχύτητα φόρτωσης μέρους της κύριας σελίδας.
Δυναμική τοπολογία που εμφανίζει μόνο «ενδιαφέρουσες» υπηρεσίες
Οι δυναμικά δημιουργούμενες τοπολογίες μπορούν να είναι πιο αποτελεσματικές από τους στατικούς χάρτες υπηρεσιών, ειδικά σε ελαστικές υποδομές αυτόματης κλίμακας. Η δυνατότητα σύγκρισης και αντίθεσης τοπολογιών υπηρεσιών επιτρέπει στο χρήστη να κάνει πιο σχετικές ερωτήσεις. Πιο ακριβείς ερωτήσεις σχετικά με το σύστημα είναι πιο πιθανό να οδηγήσουν σε καλύτερη κατανόηση του τρόπου λειτουργίας του συστήματος.
Συγκριτική απεικόνιση
Μια άλλη χρήσιμη απεικόνιση θα ήταν μια συγκριτική απεικόνιση. Επί του παρόντος, τα ίχνη δεν είναι πολύ κατάλληλα για συγκρίσεις δίπλα-δίπλα, επομένως οι συγκρίσεις είναι συνήθως εκτείνεται. Και η κύρια ιδέα αυτού του άρθρου είναι ακριβώς ότι τα διαστήματα είναι πολύ χαμηλού επιπέδου για να εξαγάγουμε τις πιο πολύτιμες πληροφορίες από τα αποτελέσματα ιχνών.
Η σύγκριση δύο ιχνών δεν απαιτεί θεμελιωδώς νέες οπτικοποιήσεις. Στην πραγματικότητα, αρκεί κάτι σαν ένα ιστόγραμμα που αντιπροσωπεύει τις ίδιες πληροφορίες με μια ανίχνευση. Παραδόξως, ακόμη και αυτή η απλή μέθοδος μπορεί να αποφέρει πολύ περισσότερους καρπούς από την απλή μελέτη δύο ιχνών χωριστά. Ακόμα πιο ισχυρή θα ήταν η δυνατότητα απεικονίζω σύγκριση των ιχνών Συνολικά. Θα ήταν εξαιρετικά χρήσιμο να δούμε πώς μια αλλαγή στη διαμόρφωση της βάσης δεδομένων που αναπτύχθηκε πρόσφατα για να ενεργοποιηθεί η GC (συλλογή σκουπιδιών) επηρεάζει τον χρόνο απόκρισης μιας κατάντη υπηρεσίας σε κλίμακα αρκετών ωρών. Αν αυτό που περιγράφω εδώ ακούγεται σαν ανάλυση A/B του αντίκτυπου των αλλαγών υποδομής σε πολλές υπηρεσίες χρησιμοποιώντας τα αποτελέσματα του ίχνους, τότε δεν είστε πολύ μακριά από την αλήθεια.
Συμπέρασμα
Δεν αμφισβητώ τη χρησιμότητα της ίδιας της ανίχνευσης. Πιστεύω ειλικρινά ότι δεν υπάρχει άλλη μέθοδος συλλογής δεδομένων τόσο πλούσια, αιτιολογική και συμφραζόμενη όσο αυτή που περιέχεται σε ένα ίχνος. Ωστόσο, πιστεύω επίσης ότι όλες οι λύσεις ανίχνευσης χρησιμοποιούν αυτά τα δεδομένα εξαιρετικά αναποτελεσματικά. Όσο τα εργαλεία ανίχνευσης παραμένουν κολλημένα στην αναπαράσταση παρακολούθησης παρακολούθησης, θα είναι περιορισμένα στην ικανότητά τους να αξιοποιούν στο έπακρο τις πολύτιμες πληροφορίες που μπορούν να εξαχθούν από τα δεδομένα που περιέχονται στα ίχνη. Επιπλέον, υπάρχει ο κίνδυνος περαιτέρω ανάπτυξης μιας εντελώς μη φιλικής και μη διαισθητικής οπτικής διεπαφής που θα περιορίσει σημαντικά τη δυνατότητα του χρήστη να αντιμετωπίζει σφάλματα στην εφαρμογή.
Ο εντοπισμός σφαλμάτων σύνθετων συστημάτων, ακόμη και με τα πιο πρόσφατα εργαλεία, είναι απίστευτα δύσκολος. Τα εργαλεία θα πρέπει να βοηθούν τον προγραμματιστή να διατυπώσει και να ελέγξει μια υπόθεση, παρέχοντας ενεργά σχετικές πληροφορίες, προσδιορίζοντας ακραίες τιμές και σημειώνοντας χαρακτηριστικά στην κατανομή των καθυστερήσεων. Προκειμένου η ανίχνευση να γίνει το εργαλείο επιλογής για προγραμματιστές κατά την αντιμετώπιση προβλημάτων παραγωγής ή την επίλυση προβλημάτων που εκτείνονται σε πολλές υπηρεσίες, απαιτούνται πρωτότυπες διεπαφές χρήστη και απεικονίσεις που να συνάδουν περισσότερο με το νοητικό μοντέλο των προγραμματιστών που δημιουργούν και λειτουργούν αυτές τις υπηρεσίες.
Θα χρειαστεί σημαντική διανοητική προσπάθεια για να σχεδιαστεί ένα σύστημα που θα αντιπροσωπεύει τα διάφορα σήματα που είναι διαθέσιμα στα αποτελέσματα ιχνών με τρόπο που να είναι βελτιστοποιημένος για να διευκολύνει την ανάλυση και τα συμπεράσματα. Πρέπει να σκεφτείτε πώς να αφαιρέσετε την τοπολογία του συστήματος κατά τον εντοπισμό σφαλμάτων με τρόπο που να βοηθά τον χρήστη να ξεπεράσει τα τυφλά σημεία χωρίς να κοιτάξει μεμονωμένα ίχνη ή διαστήματα.
Χρειαζόμαστε καλές δυνατότητες αφαίρεσης και layering (ειδικά στο UI). Αυτά που θα ταίριαζαν καλά σε μια διαδικασία εντοπισμού σφαλμάτων που βασίζεται σε υποθέσεις, όπου μπορείτε να κάνετε επαναληπτικά ερωτήσεις και να δοκιμάσετε υποθέσεις. Δεν θα λύσουν αυτόματα όλα τα προβλήματα παρατηρητικότητας, αλλά θα βοηθήσουν τους χρήστες να βελτιώσουν τη διαίσθησή τους και να διατυπώσουν πιο έξυπνες ερωτήσεις. Ζητώ μια πιο στοχαστική και καινοτόμο προσέγγιση στην οπτικοποίηση. Υπάρχει μια πραγματική προοπτική εδώ να επεκταθούν οι ορίζοντες.
ΥΓ από τον μεταφραστή
Διαβάστε επίσης στο blog μας:
- «"?
- «"?
- «».
Πηγή: www.habr.com