🥇Όχι μόνο το New Relic: μια ματιά στο Datadog και το Atatus

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

Και στη λύπη και στη χαρά…

Έτυχε να έχουμε από καιρό και βαθιά ερωτευτεί το New Relic. Ήταν και παραμένει ένα εξαιρετικό εργαλείο για την παρακολούθηση της απόδοσης της εφαρμογής, και σας επιτρέπει επίσης να οργανώνετε την αρχιτεκτονική microservice (χρησιμοποιώντας τον αντιπρόσωπό της) και πολλά, πολλά άλλα. Και όλα θα μπορούσαν να ήταν υπέροχα αν δεν υπήρχαν αλλαγές στην τιμολογιακή πολιτική της υπηρεσίας: αυτό κόστος από το έτος 2013 μεγάλωσε 3+ φορές. Επιπλέον, από πέρυσι, η απόκτηση δοκιμαστικού λογαριασμού απαιτεί επικοινωνία με έναν προσωπικό διαχειριστή, γεγονός που δυσχεραίνει την παρουσίαση του προϊόντος σε υποψήφιο πελάτη.

Η συνήθης κατάσταση: Το New Relic δεν χρειάζεται σε «μόνιμη βάση»· το θυμούνται μόνο τη στιγμή που αρχίζουν τα προβλήματα. Ωστόσο, πρέπει να πληρώνετε τακτικά (140 USD ανά διακομιστή ανά μήνα) και σε μια υποδομή cloud που κλιμακώνεται αυτόματα τα ποσά είναι αρκετά μεγάλα. Αν και υπάρχει μια επιλογή Pay-As-You-Go, η ενεργοποίηση του New Relic θα απαιτήσει από εσάς να επανεκκινήσετε την εφαρμογή, κάτι που μπορεί να οδηγήσει στην απώλεια της προβληματικής κατάστασης για την οποία ξεκίνησαν όλα. Πριν από λίγο καιρό, η New Relic παρουσίασε ένα νέο πρόγραμμα χρέωσης - ESSENTIALS, - το οποίο εκ πρώτης όψεως μοιάζει με μια λογική εναλλακτική του Professional... αλλά μετά από πιο προσεκτική εξέταση αποδείχθηκε ότι λείπουν ορισμένες σημαντικές λειτουργίες (κυρίως, δεν έχει Βασικές Συναλλαγές, Cross Application Tracing, Κατανεμημένη ανίχνευση).

Ως αποτέλεσμα, αρχίσαμε να σκεφτόμαστε να αναζητούμε μια φθηνότερη εναλλακτική και η επιλογή μας έπεσε σε δύο υπηρεσίες: Datadog και Atatus. Γιατί πάνω τους;

Σχετικά με τους ανταγωνιστές

Επιτρέψτε μου να πω αμέσως ότι υπάρχουν και άλλες λύσεις στην αγορά. Εξετάσαμε ακόμη και επιλογές Ανοιχτού Κώδικα, αλλά δεν έχει κάθε πελάτης δωρεάν δυνατότητα φιλοξενίας αυτο-φιλοξενούμενων λύσεων... - επιπλέον, θα απαιτήσουν πρόσθετη συντήρηση. Το ζευγάρι που επιλέξαμε αποδείχθηκε το πιο κοντινό τις ανάγκες μας:

ενσωματωμένη και ανεπτυγμένη υποστήριξη για εφαρμογές PHP (η στοίβα των πελατών μας είναι πολύ διαφορετική, αλλά αυτή είναι μια σαφής ηγετική θέση στο πλαίσιο της αναζήτησης μιας εναλλακτικής λύσης στο New Relic).
προσιτό κόστος (λιγότερο από 100 USD ανά μήνα ανά κεντρικό υπολογιστή).
αυτόματα όργανα?
ενσωμάτωση με Kubernetes?
Η ομοιότητα με τη διεπαφή New Relic είναι ένα αξιοσημείωτο πλεονέκτημα (επειδή οι μηχανικοί μας το έχουν συνηθίσει).

Ως εκ τούτου, στο αρχικό στάδιο επιλογής, καταργήσαμε πολλές άλλες δημοφιλείς λύσεις, και συγκεκριμένα:

Tideways, AppDynamics και Dynatrace - για το κόστος.
Το Stackify είναι αποκλεισμένο στη Ρωσική Ομοσπονδία και εμφανίζει πολύ λίγα δεδομένα.

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

Παρουσίαση επιλεγμένων διαγωνιζομένων

επί Νέο Relic, μάλλον όλοι έχουν ακούσει; Αυτή η υπηρεσία ξεκίνησε την ανάπτυξή της πριν από περισσότερα από 10 χρόνια, το 2008. Το χρησιμοποιούμε ενεργά από το 2012 και δεν είχαμε προβλήματα με την ενσωμάτωση ενός πραγματικά μεγάλου αριθμού εφαρμογών σε PHP, Ruby και Python, και είχαμε επίσης εμπειρία ενσωμάτωσης με C# και Go. Οι δημιουργοί της υπηρεσίας έχουν λύσεις για την παρακολούθηση εφαρμογών, υποδομών, ιχνηλάτησης υποδομών μικροϋπηρεσιών, δημιούργησαν βολικές εφαρμογές για συσκευές χρήστη και πολλά άλλα.

Ωστόσο, ο παράγοντας New Relic εκτελείται σε ιδιόκτητα πρωτόκολλα και δεν υποστηρίζει το OpenTracing. Τα προηγμένα όργανα απαιτούν επεξεργασίες ειδικά για το New Relic. Τέλος, η υποστήριξη Kubernetes είναι ακόμα πειραματική.

Ξεκίνησε την ανάπτυξή του το 2010 datadog φαίνεται αισθητά πιο ενδιαφέρον από το New Relic ακριβώς όσον αφορά τη χρήση σε περιβάλλοντα Kubernetes. Συγκεκριμένα, υποστηρίζει την ενοποίηση με τα πρωτόκολλα NGINX Ingress, συλλογή αρχείων καταγραφής, statsd και OpenTracing, τα οποία σας επιτρέπουν να παρακολουθείτε ένα αίτημα χρήστη από τη στιγμή που θα συνδεθεί μέχρι την ολοκλήρωσή του, καθώς και να βρείτε αρχεία καταγραφής για αυτό το αίτημα (τόσο από την πλευρά του διακομιστή ιστού και στον καταναλωτή).

Όταν χρησιμοποιούσαμε το Datadog, συναντήσαμε ότι μερικές φορές κατασκεύαζε λανθασμένα τον χάρτη microservice και ορισμένες τεχνικές ελλείψεις. Για παράδειγμα, αναγνώρισε εσφαλμένα τον τύπο της υπηρεσίας (παρερμηνεύοντας το Django για μια υπηρεσία προσωρινής αποθήκευσης) και προκάλεσε 500 σφάλματα σε μια εφαρμογή PHP που χρησιμοποιεί τη δημοφιλή βιβλιοθήκη Predis.

Atatus — το νεότερο όργανο· η υπηρεσία ξεκίνησε το 2014. Ο προϋπολογισμός μάρκετινγκ του είναι σαφώς κατώτερος από τους εισηγμένους ανταγωνιστές, οι αναφορές είναι πολύ λιγότερο συχνές. Ωστόσο, το ίδιο το εργαλείο μοιάζει πολύ με το New Relic, όχι μόνο στις δυνατότητές του (APM, παρακολούθηση προγράμματος περιήγησης κ.λπ.), αλλά και στην εμφάνιση.

Ένα σημαντικό μειονέκτημα είναι ότι υποστηρίζει μόνο Node.js και PHP. Από την άλλη πλευρά, υλοποιείται αισθητά καλύτερα από το Datadog. Σε αντίθεση με το τελευταίο, το Atatus δεν απαιτεί από τις εφαρμογές να κάνουν τροποποιήσεις ή να προσθέτουν πρόσθετες ετικέτες στον κώδικα.

Πώς δουλεύουμε με το New Relic

Τώρα ας δούμε πώς χρησιμοποιούμε γενικά το New Relic. Ας πούμε ότι έχουμε ένα πρόβλημα που χρειάζεται λύση:

Είναι εύκολο να το δει κανείς στο γράφημα βουτιά - Ας το αναλύσουμε. Στο New Relic, οι συναλλαγές ιστού επιλέγονται αμέσως για μια εφαρμογή web, όλα τα στοιχεία υποδεικνύονται στο γράφημα απόδοσης, υπάρχουν πίνακες ποσοστού σφάλματος, ποσοστού αιτήματος... Αυτό που είναι πιο σημαντικό είναι ότι απευθείας από αυτούς τους πίνακες μπορείτε να μετακινηθείτε μεταξύ διαφορετικών μέρη της εφαρμογής (για παράδειγμα, κάνοντας κλικ στο MySQL θα οδηγήσει στην ενότητα της βάσης δεδομένων).

Δεδομένου ότι στο υπό εξέταση παράδειγμα βλέπουμε μια αύξηση της δραστηριότητας PHP, κάντε κλικ σε αυτό το γράφημα και μεταβείτε αυτόματα σε Συναλλαγές:

Η λίστα των συναλλαγών, που είναι ουσιαστικά ελεγκτές από το μοντέλο MVC, έχει ήδη ταξινομηθεί κατά Πιο χρονοβόρα, που είναι πολύ βολικό: βλέπουμε αμέσως τι κάνει η εφαρμογή. Ακολουθούν παραδείγματα μεγάλων ερωτημάτων που συλλέγονται αυτόματα από τη New Relic. Με την εναλλαγή ταξινόμησης, είναι εύκολο να βρείτε:

ο πιο φορτωμένος ελεγκτής εφαρμογών.
πιο συχνά ζητούμενος ελεγκτής.
ο πιο αργός από τους ελεγκτές.

Επιπλέον, μπορείτε να επεκτείνετε κάθε συναλλαγή και να δείτε τι έκανε η εφαρμογή τη στιγμή που εκτελούνταν ο κώδικας:

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

Μπορεί να φανεί ότι δύο μέθοδοι απαιτούν πολύ χρόνο και ταυτόχρονα εμφανίζεται ο χρόνος εκτέλεσης του αιτήματος, το URI και ο τομέας του. Πολύ συχνά αυτό βοηθά στην εύρεση του αιτήματος στα αρχεία καταγραφής. Πηγαίνω σε Λεπτομέρειες ιχνών, μπορείτε να δείτε από πού καλούνται αυτές οι μέθοδοι:

Και σε Ερωτήματα βάσης δεδομένων — αξιολογήστε ερωτήματα σε βάσεις δεδομένων που εκτελέστηκαν κατά την εκτέλεση της εφαρμογής:

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

πολύ PDO::Construct μας οδήγησε στην περίεργη λειτουργία του pgpoll.
αστάθεια στο χρόνο Memcache::Get πρότεινε ότι η εικονική μηχανή δεν έχει ρυθμιστεί σωστά.
Ένας ύποπτα αυξημένος χρόνος για την επεξεργασία του προτύπου οδήγησε σε έναν ένθετο βρόχο που ελέγχει την παρουσία 500 avatar στην αποθήκευση αντικειμένων.
και ούτω καθεξής…

Συμβαίνει επίσης ότι αντί να εκτελείται κώδικας, κάτι που σχετίζεται με την εξωτερική αποθήκευση δεδομένων αυξάνεται στην κύρια οθόνη - και δεν έχει σημασία τι θα είναι: Redis ή PostgreSQL - είναι όλα κρυμμένα στην καρτέλα Βάσεις Δεδομένων.

Μπορείτε να επιλέξετε μια συγκεκριμένη βάση για έρευνα και να ταξινομήσετε ερωτήματα - παρόμοια με τον τρόπο που γίνεται στις Συναλλαγές. Και μεταβαίνοντας στην καρτέλα αιτήματος, μπορείτε να δείτε πόσες φορές εμφανίζεται αυτό το αίτημα σε κάθε έναν από τους ελεγκτές εφαρμογής και επίσης να υπολογίσετε πόσο συχνά καλείται. Είναι πολύ άνετο:

Η καρτέλα περιέχει παρόμοια δεδομένα Εξωτερικές υπηρεσίες, το οποίο αποκρύπτει αιτήματα σε εξωτερικές υπηρεσίες HTTP, όπως πρόσβαση στον χώρο αποθήκευσης αντικειμένων, αποστολή συμβάντων σε φρουρό ή παρόμοια. Το περιεχόμενο της καρτέλας είναι εντελώς παρόμοιο με τις βάσεις δεδομένων:

Ανταγωνιστές: ευκαιρίες και εντυπώσεις

Τώρα το πιο ενδιαφέρον είναι να συγκρίνετε τις δυνατότητες του New Relic με αυτό που προσφέρουν οι ανταγωνιστές. Δυστυχώς, δεν μπορέσαμε να δοκιμάσουμε και τα τρία εργαλεία σε μία έκδοση μιας εφαρμογής που εκτελείται σε παραγωγή. Ωστόσο, προσπαθήσαμε να συγκρίνουμε καταστάσεις/διαμορφώσεις που ήταν όσο το δυνατόν πανομοιότυπες.

1.Datadog

Το Datadog μας υποδέχεται με ένα πάνελ με έναν τοίχο υπηρεσιών:

Προσπαθεί να χωρίσει τις εφαρμογές σε στοιχεία/μικροϋπηρεσίες, οπότε στο παράδειγμα της εφαρμογής Django θα δούμε 2 συνδέσεις με την PostgreSQL (defaultdb и postgres), καθώς και οι Celery, Redis. Η εργασία με το Datadog απαιτεί να έχετε ελάχιστη γνώση των αρχών MVC: πρέπει να κατανοήσετε από πού προέρχονται γενικά τα αιτήματα των χρηστών. Αυτό συνήθως βοηθάει χάρτης υπηρεσιών:

Παρεμπιπτόντως, υπάρχει κάτι παρόμοιο στο New Relic:

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

Ας επιστρέψουμε στο Datadog: από τον χάρτη υπηρεσιών μπορούμε να δούμε ότι τα αιτήματα των χρηστών έρχονται στο Django. Ας πάμε στην υπηρεσία Django και επιτέλους να δούμε τι περιμέναμε:

Δυστυχώς, δεν υπάρχει γράφημα εδώ από προεπιλογή Χρόνος διαδικτυακής συναλλαγής, παρόμοιο με αυτό που βλέπουμε στον κύριο πίνακα New Relic. Ωστόσο, μπορεί να ρυθμιστεί στη θέση του χρονοδιαγράμματος % του χρόνου που δαπανήθηκε. Αρκεί να το αλλάξετε σε Μέσος χρόνος ανά αίτημα ανά τύπο... και τώρα μας κοιτάζει το γνωστό γράφημα!

Το γιατί η Datadog επέλεξε ένα διαφορετικό γράφημα είναι ένα μυστήριο για εμάς. Ένα άλλο απογοητευτικό πράγμα είναι ότι το σύστημα δεν θυμάται την επιλογή του χρήστη (σε αντίθεση με τους δύο ανταγωνιστές) και επομένως η μόνη λύση είναι να δημιουργήσει προσαρμοσμένα πάνελ.

Αλλά ήμουν ικανοποιημένος με τη δυνατότητα του Datadog να αλλάζει από αυτά τα γραφήματα στις μετρήσεις των σχετικών διακομιστών, να διαβάζει τα αρχεία καταγραφής και να αξιολογεί το φορτίο στους χειριστές διακομιστών ιστού (Gunicorn). Όλα είναι σχεδόν ίδια όπως στο New Relic... και μάλιστα λίγο παραπάνω (κούτσουρα)!

Κάτω από τα γραφήματα εμφανίζονται συναλλαγές εντελώς παρόμοιες με το New Relic:

Στο Datadog, οι συναλλαγές καλούνται πόροι. Μπορείτε να ταξινομήσετε τους ελεγκτές με βάση τον αριθμό των αιτημάτων, τον μέσο χρόνο απόκρισης και τον μέγιστο χρόνο που δαπανήθηκε για μια επιλεγμένη χρονική περίοδο.

Μπορείτε να επεκτείνετε τον πόρο και να δείτε όλα όσα έχουμε ήδη παρατηρήσει στο New Relic:

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

Οποιοσδήποτε πόρος παράδειγμα στο Datadog μπορεί να ανοίξει και να μελετηθεί:

Παρουσιάζονται οι παράμετροι αιτήματος, ένα συνοπτικό γράφημα του χρόνου που αφιερώθηκε σε κάθε στοιχείο και ένα διάγραμμα καταρράκτη που δείχνει τη σειρά των κλήσεων. Μπορείτε επίσης να μεταβείτε σε μια προβολή δέντρου του γραφήματος καταρράκτη:

Και το πιο ενδιαφέρον πράγμα είναι η προβολή του φορτίου του κεντρικού υπολογιστή στον οποίο εκτελέστηκε το αίτημα και η προβολή των αρχείων καταγραφής αιτημάτων.

Μεγάλη ενσωμάτωση!

Ίσως αναρωτιέστε πού βρίσκονται οι καρτέλες Βάσεις Δεδομένων и Εξωτερικές υπηρεσίες, όπως στο New Relic. Δεν υπάρχει κανένα εδώ: δεδομένου ότι το Datadog αποσυνθέτει την εφαρμογή σε στοιχεία, το PostgreSQL θα ληφθεί υπόψη ξεχωριστή υπηρεσία, και αντί για Εξωτερικές Υπηρεσίες αξίζει να το αναζητήσετε aws.storage (θα είναι παρόμοια για κάθε άλλη εξωτερική υπηρεσία στην οποία μπορεί να έχει πρόσβαση η εφαρμογή).

Εδώ είναι ένα παράδειγμα με postgres:

Ουσιαστικά υπάρχουν όλα όσα θέλαμε:

Μπορείτε να δείτε από ποια «υπηρεσία» προήλθε το αίτημα.

Δεν θα ήταν λάθος να σας υπενθυμίσουμε ότι το Datadog ενσωματώνεται τέλεια με το NGINX Ingress και σας επιτρέπει να πραγματοποιείτε ανίχνευση από άκρο σε άκρο από τη στιγμή που φθάνει ένα αίτημα στο σύμπλεγμα και επίσης σας επιτρέπει να λαμβάνετε μετρήσεις statsd, να συλλέγετε αρχεία καταγραφής και μετρήσεις φιλοξενίας .

Ένα τεράστιο πλεονέκτημα του Datadog είναι ότι η τιμή του διπλώνει από παρακολούθηση υποδομής, APM, Log Management και Synthetics test, π.χ. Μπορείτε να επιλέξετε το πρόγραμμά σας με ευελιξία.

2.Atatus

Η ομάδα Atatus ισχυρίζεται ότι η υπηρεσία τους είναι «η ίδια με τη New Relic, αλλά καλύτερη». Ας δούμε αν είναι όντως έτσι.

Ο κύριος πίνακας φαίνεται παρόμοιος, αλλά δεν ήταν δυνατός ο προσδιορισμός του Redis και του memcached που χρησιμοποιούνται στην εφαρμογή.

Το APM επιλέγει όλες τις συναλλαγές από προεπιλογή, αν και συνήθως χρειάζονται μόνο συναλλαγές στο Web. Όπως και το Datadog, δεν υπάρχει τρόπος πλοήγησης στην επιθυμητή υπηρεσία από τον κεντρικό πίνακα. Επιπλέον, οι συναλλαγές παρατίθενται μετά από σφάλματα, κάτι που δεν φαίνεται πολύ λογικό για την APM.

Στις συναλλαγές Atatus, όλα είναι όσο το δυνατόν παρόμοια με το New Relic. Το μειονέκτημα είναι ότι η δυναμική για κάθε ελεγκτή δεν είναι άμεσα ορατή. Πρέπει να το αναζητήσετε στον πίνακα ελεγκτή, ταξινομώντας κατά Ο περισσότερος χρόνος που καταναλώνεται:

Η συνήθης λίστα ελεγκτών είναι διαθέσιμη στην καρτέλα Δείτε περισσοτερα:

Κατά κάποιο τρόπο, αυτός ο πίνακας θυμίζει Datadog και μου αρέσει περισσότερο από τον αντίστοιχο στο New Relic.

Μπορείτε να επεκτείνετε κάθε συναλλαγή και να δείτε τι έκανε η εφαρμογή:

Το πάνελ θυμίζει επίσης περισσότερο το Datadog: υπάρχει μια σειρά από αιτήματα, μια γενική εικόνα των κλήσεων. Ο επάνω πίνακας παρέχει μια καρτέλα σφάλματος Αποτυχίες HTTP και παραδείγματα αργών ερωτημάτων Ίχνη συνεδρίας:

Εάν μεταβείτε σε μια συναλλαγή, μπορείτε να δείτε ένα παράδειγμα ίχνους, μπορείτε να λάβετε μια λίστα αιτημάτων στη βάση δεδομένων και να δείτε τις κεφαλίδες αιτημάτων. Όλα είναι παρόμοια με το New Relic:

Σε γενικές γραμμές, ο Atatus ευχαριστήθηκε με λεπτομερή ίχνη - χωρίς την τυπική συγκόλληση κλήσεων New Relic σε ένα μπλοκ υπενθύμισης:

Ωστόσο, του λείπει ένα φίλτρο που (όπως το New Relic) θα έκοψε τα εξαιρετικά γρήγορα αιτήματα (<5ms). Από την άλλη, μου άρεσε η εμφάνιση της τελικής απόκρισης συναλλαγής (επιτυχία ή σφάλμα).

Πίνακας Βάσεις Δεδομένων θα σας βοηθήσει να μελετήσετε τα αιτήματα σε εξωτερικές βάσεις δεδομένων που κάνει η εφαρμογή. Να σας υπενθυμίσω ότι η Atatus βρήκε μόνο τις PostgreSQL και MySQL, αν και οι Redis και memcached συμμετέχουν επίσης στο έργο.

Τα αιτήματα ταξινομούνται σύμφωνα με τα συνήθη κριτήρια: συχνότητα απόκρισης, μέσος χρόνος απόκρισης και ούτω καθεξής. Θα ήθελα επίσης να αναφέρω την καρτέλα με τα πιο αργά ερωτήματα - είναι πολύ βολικό. Επιπλέον, τα δεδομένα σε αυτήν την καρτέλα για το PostgreSQL συνέπεσαν με τα δεδομένα από την επέκταση pg_stat_statements - εξαιρετικό αποτέλεσμα!

Αυτί Εξωτερικά αιτήματα εντελώς πανομοιότυπο με τις βάσεις δεδομένων.

Ευρήματα

Και τα δύο εργαλεία που παρουσιάστηκαν απέδωσαν καλά στο ρόλο του APM. Οποιοσδήποτε από αυτούς μπορεί να προσφέρει το απαιτούμενο ελάχιστο. Οι εντυπώσεις μας μπορούν να συνοψιστούν εν συντομία ως εξής:

datadog

Πλεονεκτήματα:

βολικό πρόγραμμα τιμολόγησης (το APM κοστίζει 31 USD ανά κεντρικό υπολογιστή).
δούλεψε καλά με την Python.
Δυνατότητα ενσωμάτωσης με το OpenTracing
ενσωμάτωση με Kubernetes?
ενσωμάτωση με το NGINX Ingress.

Μειονεκτήματα:

το μόνο APM που έκανε την εφαρμογή να μην είναι διαθέσιμη λόγω σφάλματος μονάδας (predis).
αδύναμη αυτόματη οργάνωση PHP.
εν μέρει περίεργος ορισμός των υπηρεσιών και ο σκοπός τους.

Atatus