Μετρικές, παρακολούθηση, ειδοποιήσεις

Περιεχόμενα:

Περίληψη
Λεπτομέρειες
Σχετικά
Σημειώσεις

Περίληψη

Ζήτημα

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

Απόφαση

Σε εξέλιξη (WIP).

Κατάσταση

Συλλογή πληροφοριών. Ξεκινάμε από τα πιθανά άκρα του φάσματος: το πιο προτεινόμενο παλαιότερο δωρεάν εργαλείο (Nagios) και το πιο προτεινόμενο νεότερο επί πληρωμή εργαλείο (New Relic).

Λεπτομέρειες

Παραδοχές

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

Θέλουμε να αγοράζουμε και όχι να χτίζουμε.

Περιορισμοί

Θέλουμε εργαλεία που λειτουργούν καλά με τη ροή devops μας και με τα cloud ανάπτυξής μας.

Θέσεις

Ερευνούμε αυτή τη στιγμή τις θέσεις.

AlertManager
AppDynamics
AppOptics
Azure Monitor/Analytics/Insights/Dashboards
Bosun
Checkly
Circonus
Cloudwatch
EFK
ELK
Grafana
Grafana
Graphite
Graylog
Healthchecks.io
Heroku
icinga2
InfluxDB
Instana
Kafka
Logagent
Logz.io
Loki
Monitis
Nagios
Nagios
Nagiosgraph
NewRelic
OpsGenie
Outlyer
PagerDuty
Pagerduty
PagerDuty
Papertrail
Prometheus
Rollbar
Scalyr
Sematext Metrics, Logs, Experience, Tracing
Sensu
SignalFX
Slack
Splunk
Stackdriver
Stackstorm
Telegraf
Telegraf
Thanos
VictorOps
Wavefront
Zabbix

Επιχείρημα

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

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

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

Μέχρι στιγμής, το Prometheus + Grafana έχουν την καλύτερη δημοφιλία.

Επιπτώσεις

TODO.

Σχετικά

Σχετικές αποφάσεις

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

Σχετικές απαιτήσεις

TODO.

Σχετικά τεχνουργήματα

TODO.

Σχετικές αρχές

Εύκολα αναστρέψιμο.

Ανάγκη για ταχύτητα.

Σημειώσεις

Μια αρκετά καλή στοίβα ανοικτού κώδικα είναι:

Prometheus για μετρικές και ειδοποιήσεις βασισμένες σε μετρικές
Grafana για την εμφάνιση μετρικών
Elasticsearch/Logstash/Kibana (ELK) για αρχεία καταγραφής και δομημένα γεγονότα
Pushover για ειδοποιήσεις σε κινητά

Μηνύματα κειμένου ελεύθερης μορφής έναντι δομημένων μηνυμάτων γεγονότων

Μηνύματα κειμένου ελεύθερης μορφής: για παράδειγμα, το είδος των τυχαίων πραγμάτων που θα βρείτε στο /var/log/messages, και κάτι που παράγεται σκόπιμα από την εφαρμογή. Τα μηνύματα είναι χρήσιμα για τον εντοπισμό άλλων πραγμάτων που συμβαίνουν στο μηχάνημα, όπως έλλειψη μνήμης ή σφάλματα υλικού, αλλά έχουν πολλά σκουπίδια.

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

Γενικά, είναι ωραίο να καταγράφονται λεπτομέρειες για κάθε αίτημα με τρόπο που να μπορείτε να εμβαθύνετε βάσει χαρακτηριστικών. Έτσι η προσθήκη π.χ. ενός userid ή sessionid σε όλα σάς επιτρέπει να ιχνηλατείτε. Η ρητή ιχνηλάτηση (tracing) είναι επίσης καλή, φυσικά. Η χρήση του ELK γι' αυτό είναι κάτι σαν το φτωχό αντίστοιχο του https://www.honeycomb.io/

Το Graylog είναι ευκολότερο

Το Graylog είναι ευκολότερο να σηκωθεί από την εμπειρία μου.

Το Prometheus θέλει λίγο συντονισμό

Είμαι γενικά ικανοποιημένος με το Prometheus για μετρικές. Οι ειδοποιήσεις θέλουν λίγο συντονισμό, αλλά είναι αρκετά καλές. Εξαρτάται από την εφαρμογή σας. Νομίζω ότι είναι καλύτερα να ειδοποιείτε για συνθήκες ορατές στον τελικό χρήστη, όχι για υποκείμενες αιτίες. Για παράδειγμα, ο χρόνος φόρτωσης σελίδας είναι καλός, ο αριθμός αιτημάτων ανά δευτερόλεπτο όχι. Αν και μηδέν αιτήματα ανά δευτερόλεπτο υποδεικνύει ότι κάτι δεν πάει καλά.

Το πλεονέκτημα μιας υπηρεσίας είναι ότι προσφέρει πρόσθετη ευφυΐα έτοιμη προς χρήση. Γενικά μου αρέσει το Datadog. Οι υπηρεσίες μπορεί να είναι τρομακτικά ακριβές αν έχετε πολλά δεδομένα και μερικές φορές έχουν μοντέλα τιμολόγησης που δεν είναι φιλικά προς το cloud, π.χ. χρέωση ανά στιγμιότυπο, όταν τα στιγμιότυπα είναι δυναμικά. Υπάρχει επίσης διαφορά μεταξύ υπηρεσιών όπου κάθε αίτημα προέρχεται από πληρωμένο χρήστη και εκείνων που σχετίζονται με διαφήμιση, όπου μόνο ένα μικρό ποσοστό των αιτημάτων σας φέρνει χρήματα. Μπορεί να καταλήξετε με πολλά δεδομένα και όχι τόσο μεγάλο προϋπολογισμό.

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

Οι υπηρεσίες της AWS είναι μικτές

Η εμπειρία μου με τις υπηρεσίες της AWS ήταν μικτή. Η υπηρεσία Elasticsearch τους ήταν ασταθής, οπότε τρέχουμε δικά μας στιγμιότυπα. Οι μετρικές του CloudWatch είναι ακριβές, οπότε γενικά τις χρησιμοποιούμε μόνο για μετρικές επιπέδου «υποδομής» και όχι εφαρμογής, δηλαδή μετρικές σχετικές με την υγεία όπου η AWS μπορεί να γνωρίζει καλύτερα τι συμβαίνει από το λογισμικό που τρέχει στο στιγμιότυπο. Τα CloudWatch Logs μπορεί να ενημερώνονται αργά και δεν έχουν πολλά μεταδεδομένα. Η εκτέλεση του ELK βοηθά σε αυτό. Αν θέλω πραγματικά δεδομένα σε πραγματικό χρόνο, η χρήση του Kafka ως μεταφορέα καταγραφών είναι καλύτερη. Αυτό υποστηρίζεται αρκετά καλά από το Logstash. Η διαχείριση μιας συστοιχίας Kafka δεν είναι όμως για αδύναμες καρδιές, υπάρχουν πολλές εκτεθειμένες σωληνώσεις.

Kafka

Σχόλιο: Το Kafka μπορεί να είναι υπερβολικά δύσκολο κατά περιόδους, ή μπορεί να είναι συμπαγές σαν βράχος και σχεδόν να ξεχνάτε ότι είναι εκεί και δένει τα πάντα.

Σχόλιο: Το Kafka ήταν σταθερό, αλλά χρειάστηκε εκπληκτικά πολλή δουλειά για να ξεκινήσει. Το σκέφτομαι σαν μια σχεσιακή βάση δεδομένων αλλά όπου δουλεύετε μόνο στο «φυσικό» επίπεδο, π.χ. χώρους πινάκων, αρχεία και κατατμήσεις. Υπήρχαν στιγμές στην αρχή όπου έλειπαν τα βοηθητικά εργαλεία διαχείρισης και έπρεπε να γράψουμε προγράμματα π.χ. για την επαναφορά μιας ομάδας καταναλωτών. http://howfuckedismydatabase.com/nosql/

Σχόλιο: Χρησιμοποιούμε το Kafka ως «ενδιάμεση μνήμη» για μηνύματα καταγραφής και ως χώρο όπου μπορούμε να κάνουμε επεξεργασία ροής σε πραγματικό χρόνο σε δεδομένα που έρχονται από πολλούς διακομιστές. Αν δεχτούμε επίθεση DDOS, χρειαζόμαστε τρόπο ανάλυσης δεδομένων σε πολλά στιγμιότυπα. Αν καταγράφουμε απευθείας από τους διακομιστές στο ELK, το φορτίο μπορεί να καταρρίψει τη συστοιχία Elasticsearch.

Σχόλιο: Το Kafka είναι καλό για εμάς διότι, αν δεχτούμε επίθεση DDOS, χρειαζόμαστε τρόπο ανάλυσης δεδομένων σε πολλά στιγμιότυπα. Αν καταγράφουμε απευθείας από τους διακομιστές στο ELK, το φορτίο μπορεί να καταρρίψει τη συστοιχία Elasticsearch.

Σχόλιο: Το Kafka κάνει λιγότερη δουλειά και είναι πιο αποδοτικό, οπότε αντέχει καλύτερα το φορτίο. Και βάζουμε σε ουρά τη δουλειά του Kafka και την επαναλαμβάνουμε. Και το να είναι υπερφορτωμένο το Kafka δεν επηρεάζει τους χρήστες που προσπαθούν να δουλέψουν διαδραστικά με το Kibana, όπως θα συνέβαινε αν το Elasticsearch δυσκολευόταν.

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

Σχόλιο: Το πρόσθετο logstash-output-kafka είναι ωστόσο αρκετά αναξιόπιστο αυτή τη στιγμή. Με έχουν δαγκώσει αρκετά από τα προβλήματα στη σελίδα issues του στο GitHub, που φαίνεται να μην διορθώνονται ποτέ. Θέλω να σταματήσω να το χρησιμοποιώ και να στέλνω απευθείας από τις εφαρμογές μας στο Kafka.

Σχόλιο: Τώρα στέλνουμε δομημένα γεγονότα απευθείας από την εφαρμογή στο Kafka. Το βασικό κίνητρο ήταν να αγγίζουμε τα δεδομένα καταγραφής λιγότερες φορές και να αποφεύγουμε να διαβάζουμε και να γράφουμε στον δίσκο πολλές φορές. Σε συστήματα υψηλού όγκου, η καταγραφή μπορεί να απαιτεί περισσότερη δουλειά από την ίδια την εφαρμογή. Σκέφτομαι να κάνω το journald να στέλνει επίσης απευθείας καταγραφές, από πρόγραμμα C.

Loki

Παρακολουθήστε στενά το Loki. Δεν είναι ακόμη έτοιμο, αλλά όταν είναι, θα περίμενα να ταιριάζει καλύτερα σε αυτή τη στοίβα. Το Loki είναι ένας συσσωρευτής καταγραφών που δημιουργήθηκε από την Grafana Labs και χρησιμοποιεί παρόμοια σύνταξη συλλογής και ετικετών με το Prometheus.

Prometheus + alertmanager + Rollbar + Graylog + Grafana

Prometheus + alertmanager για μετρικές. <3 Prometheus.

Rollbar/Graylog για καταγραφή/αναφορά σφαλμάτων (υπάρχει κάποια επικάλυψη εδώ· μια μικρή υπηρεσία πιθανώς δεν χρειάζεται και τα δύο).

Προς το παρόν, οι ειδοποιήσεις πηγαίνουν απλώς σε ένα από λίγα κανάλια Slack για τα οποία τα ενδιαφερόμενα μέρη έχουν ενεργοποιημένες τις ειδοποιήσεις. Αν ήμασταν πιο σοβαροί με την εφημερία (on-call), θα πήγαιναν σε PagerDuty/VictorOps κ.λπ.

Grafana για γραφήματα και πίνακες ελέγχου. Περιμένω επίσης με ανυπομονησία να δω αν οι επερχόμενες δυνατότητες καταγραφής τους θα καταστήσουν περιττό το Graylog.

Thanos

Χρησιμοποιούμε το Thanos ως front-end για τη ρύθμιση HA. Ξέρει να αποδιπλασιάζει ζεύγη HA.

Προς το παρόν κρατάμε 6 μήνες τοπικών δεδομένων Prometheus. Αυτό λειτουργεί αρκετά καλά για εμάς. Αλλά είμαι ακριβώς στη μέση της υλοποίησης αποθήκευσης bucket στη ρύθμιση Thanos για μακροπρόθεσμη αποθήκευση δεδομένων. Θεωρητικά, η αποθήκευση GCS θα είναι περίπου 30% φθηνότερη από τον τυπικό μόνιμο δίσκο GCE που χρησιμοποιούμε τώρα.

Προς το παρόν δεν κρατάμε αντίγραφα ασφαλείας των δεδομένων Prometheus. Τα δεδομένα απλώς δεν είναι πραγματικά σημαντικά για εμάς πέρα από το να έχουμε αρκετά για ειδοποιήσεις. Η συνολική ανάπτυξη του στόλου μας αλλάζει τόσο πολύ από χρόνο σε χρόνο που τα ιστορικά δεδομένα παλαιότερα από λίγους μήνες δεν είναι πραγματικά ενδιαφέροντα. Θα μπορούσε να είναι ενδιαφέρον να έχουμε μερικά βασικά στατιστικά από χρόνο σε χρόνο· ίσως στήσω ένα σύνολο κανόνων καταγραφής βασικών στατιστικών και να τα αποθηκεύσω με Federation ή απλώς να αφήσω το Thanos να το φροντίσει.

EDIT: Μια μικρή δήλωση: είμαι προγραμματιστής του Prometheus.

Prometheus HA

Το HA στο Prometheus γίνεται με αντιγραφή — τρέχετε πολλαπλά στιγμιότυπα συλλογής και υπάρχουν τρόποι να ερωτάτε πολλά και να αποδιπλασιάζετε τα δεδομένα

Η κλιμάκωση γίνεται με τον διαχωρισμό του δικτύου και την ανάθεση σε διαφορετικά Prometheus της ερώτησης διαφορετικών τμημάτων του δικτύου

Η μακροπρόθεσμη αποθήκευση δεν είναι το δυνατό σημείο του Prometheus, αλλά μεταφέρεται σε κάτι σαν Influx ή timescaledb (που τεχνικά τσεκάρει κι αυτό το HA) άρθρο που διάβασα γι' αυτό https://blog.timescale.com/prometheus-ha-postgresql-8de68d19b6f5?gi=7df160f10e07

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

Datadog + PagerDuty + Threat Stack

Χρησιμοποιούμε Datadog (με PagerDuty) και Threat Stack και δεν θα μπορούσαμε να είμαστε πιο ευχαριστημένοι. Το μόνο μου παράπονο για το DD είναι το σχετικά υψηλό κόστος αποθήκευσης μετρικών.

Zabbix

Zabbix με προσαρμοσμένα σενάρια για την παρακολούθηση σχεδόν των πάντων. Λειτουργεί υπέροχα.

Outlyer

Χρησιμοποιώ το Outlyer, αλλά πρέπει να δηλώσω ότι δουλεύω εδώ και ότι η χρήση του δικού μας προϊόντος είναι υποχρεωτική.

Χρειάζομαι ακόμη Graylog, Sentry και Statuscake για ενίσχυση.

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

Nagios + Nagiosgraph

Τρέχουμε Nagios για όλη την παρακολούθηση και τις ειδοποιήσεις. Οι ειδοποιήσεις γίνονται μέσω email (προειδοποιήσεις και κρίσιμες ειδοποιήσεις) και ηχητικών ειδοποιήσεων εφαρμογής (για κρίσιμες ειδοποιήσεις).

Το Nagiosgraph χρησιμοποιείται για οπτικοποιήσεις.

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

Θα ήθελα επίσης να συγκεντρώνω κάποια στιγμή καταγραφές με Graylog ή ELK.

Prometheus + Grafana + AlertManager

Prometheus + Grafana + AlertManager μέσω του εξαιρετικού helm chart Prometheus Operator. Οι καταγραφές εξακολουθούν να πηγαίνουν στο πλάνο birch του LogDNA, καθώς παρατηρήσαμε ότι το ELK είναι υπερβολικά βαρύ για τη μετριοπαθή συστοιχία μας με ελάχ. 3 και μέγ. 5 κόμβους στο GKE.

DataDog + Sentry + PagerDuty.

Παλιά έτρεχα όλες τις δικές μου λύσεις παρακολούθησης χρησιμοποιώντας κάθε είδους λογισμικό, συμπεριλαμβανομένων των Nagios, Icinga, Zabbix, ELK, Greylog2, Influx και πολλών άλλων εργαλείων, αλλά η αλήθεια είναι ότι υπάρχει υπερβολική προσπάθεια στην εκτέλεση της δικής σας υποδομής παρακολούθησης, ειδικά όταν μπορείτε να πληρώσετε κάποιον άλλο με τόσο χαμηλές τιμές να το κάνει για εσάς!

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

Sensu + Graphite + ELK

Η εταιρεία μου δίνει μεγάλη έμφαση στα αυτο-φιλοξενούμενα.

Sensu -> PagerDuty

Graphite/Grafana

ELK (Elasticsearch, Logstash, Kibana)

Prometheus + Alertmanager

Prometheus + Alertmanager για ειδοποιήσεις, η ομάδα μου πιστεύει ότι η απλή παρακολούθηση είναι καλή παρακολούθηση.

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

Sensu + Grafana + Graylog + Kibana + NewRelic.

Sensu, grafana, graylog, kibana, newrelic.

Prometheus + Circonus

Υπηρεσίες με εργαλειοθήκη Prometheus => ανάλυση και οπτικοποίηση Circonus

icinga2 + VictorOps + NewRelic + Sentry + Slack

Χρησιμοποιούμε τις παρακάτω υπηρεσίες:

icinga2 για παρακολούθηση και VictorOps για ειδοποιήσεις

NewRelic για λεπτομερή παρακολούθηση της υπηρεσίας

Sentry για ιχνηλάτηση σφαλμάτων στην υπηρεσία

Slack/Email είναι μέρος των ειδοποιήσεων που πυροδοτούνται από το NewRelic ή το icinga2

AppDynamics + Papertrail + PagerDuty + Healthchecks.io + Stackdriver

AppDynamics

Papertrail

PagerDuty

Healthchecks.io

Stackdriver

icinga2 + elasticsearch

icinga2 με ενσωμάτωση elasticsearch για ανάλυση και ενσωμάτωση graphite+grafana για γραφήματα.

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

και μέσω του icinga2 director, οι προγραμματιστές μπορούν εύκολα να ορίσουν τους δικούς τους ελέγχους (πράγμα που κάνουν, κάθε λίγες μέρες - βγαίνουν 100 έλεγχοι, μπαίνουν άλλοι 100) σε μεγάλη κλίμακα χωρίς καμία φασαρία.

DataDog + New Relic + ELK + EFK + Sentry + Alertmanager + VictorOps

Τι έχουμε τώρα:

DataDog για μετρικές

New Relic για παρακολούθηση εφαρμογών

ELK (Elastic Search + Logstash + Kibana) για τις καταγραφές

Sentry (αυτο-φιλοξενούμενο) για καταγραφή εξαιρέσεων

Emails + Slack + VictorOps για ειδοποιήσεις (ανάλογα με τη σοβαρότητα)

Τι θέλουμε να έχουμε:

Prometheus για μετρικές (Grafana για οπτικοποίηση)

New Relic (πιθανώς Elastic Search APM) για την παρακολούθηση εφαρμογών

EFK (elastic search + fluentd + kibana) για καταγραφή. Πιθανώς το Loki της Grafana θα είναι έτοιμο για παραγωγή μέχρι να φτάσουμε εκεί

Sentry για τις εξαιρέσεις

Alertmanager + email + VictorOps για τις ειδοποιήσεις

Wavefront + Scalyr + PagerDuty + Stackstorm + Slack

Wavefront + Scalyr + PagerDuty + Stackstorm + Slack (Δήλωση: δουλεύω στη VMware)

Telegraf + Prometheus + InfluxDB + Grafana

Telegraf για μετρικές διακομιστή όπως CPU, δίσκος, μνήμη και δίκτυο. Χρησιμοποιούμε επίσης το Telegraf για παρακολούθηση SNMP των συσκευών δικτύου μας.

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

InfluxDB για αποθήκευση χρονοσειρών. Εκεί στέλνονται τα δεδομένα του Telegraf.

Grafana για πίνακες ελέγχου και ειδοποιήσεις. Η μηχανή ειδοποιήσεων δεν είναι εξαιρετικά ισχυρή, αλλά κάνει τη δουλειά. Στέλνουμε επίσης ειδοποιήσεις στο Slack.

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

Sematext + Logagent + Experience

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

Για την αποστολή καταγραφών χρησιμοποιούσαμε το rsyslog και έπειτα περάσαμε στο Logagent.

Για αναφορά κρασαρισμάτων front-end χρησιμοποιούμε το Sentry, αλλά σύντομα θα περάσουμε στο Experience.

Δήλωση: είμαι Sematextan (υπάλληλος της Sematext).

Azure Monitor/Analytics + OpsGenie

Μακάρι το Log Analytics να είχε καλύτερη διεπαφή. Απομακρυνόμαστε από το Splunk, στο οποίο ήταν πολύ πιο εύκολη η πλοήγηση.

Prometheus + Alertmanager + Grafana + Splunk + PagerDuty

Prometheus, Alertmanager, Grafana, Splunk, PagerDuty

Πραγματικά δεν θέλετε να τρέχετε το δικό σας σύστημα ειδοποιήσεων. Μπορείτε να αντικαταστήσετε το Splunk με ELK εκτός αν η ομάδα ασφαλείας σας προτιμά το Splunk.

Telegraf + Prometheus + Grafana + Alertmanager

Telegraf ως συλλέκτης, Prometheus + Alertmanager για παρακολούθηση και ειδοποιήσεις, ενσωματωμένα με κανάλια slack και pagerduty για κρίσιμες ειδοποιήσεις. Grafana για οπτικοποίηση μετρικών υπολογιστών.

Prometheus + Grafana + Cloudwatch + sentry + kibana + elasticsearch

Prometheus για μετρικές + ειδοποιήσεις

Grafana για πίνακες ελέγχου του Prometheus

Cloudwatch που παρακολουθεί στιγμιότυπα Prometheus

sentry για ιχνηλάτηση εξαιρέσεων

kibana + elasticsearch

graylog

prometheus Push Gateway για εργασίες batch/cronjobs

SOP https://github.com/rapidloop/sop για «ώθηση/προώθηση» μετρικών από ένα στιγμιότυπο Prometheus σε άλλο

οι πελάτες χρησιμοποιούν τους πελάτες Prometheus. Προσπαθούμε να χρησιμοποιούμε το opencensus.io στην πλευρά του πελάτη

PagerDuty + Monitis

PagerDuty + Monitis. Επίσης μερικές προσαρμοσμένες Azure Functions για τον έλεγχο της υγείας ορισμένων υπηρεσιών.

Σκοπεύουμε να εισαγάγουμε Prometheus και Grafana φέτος

Prometheus + Grafana + Bosun

Prometheus για αποθήκευση των δεδομένων χρονοσειρών. Grafana για οπτικοποίηση. Bosun για διαχείριση ειδοποιήσεων.

Azure Monitor/Analytics/Insights/Dashboards

Μόνο Azure: Azure Monitor, Log Analytics, App Insights, Azure Dashboards + Pager Duty

Grafana + Monitis + OpsGenie + Slack

Grafana για την παρακολούθηση υπηρεσιών κοντέινερ στο Kubernetes μέσω Prometheus

Monitis για παρακολούθηση υπηρεσιών end-to-end κυρίως για API ιστού και εφαρμογές ιστού

OpsGenie για διαχείριση ειδοποιήσεων

Slack για λήψη πληροφοριών κατάστασης από τα συστήματά μας

Checkly + AppOptics + Cloudwatch + Heroku + Pagerduty + Papertrail

Μακροχρόνιος μηχανικός (dev)ops εδώ. Μεγάλωσα με το Nagios. Θα ήθελα πολύ να ακούσω απόψεις για το bootstrapped SaaS μου https://checklyhq.com. Κάνουμε παρακολούθηση API και συναλλαγών ιστότοπου με αρκετά εις βάθος ειδοποιήσεις.

Ξεκίνησα το Checkly επειδή η ενεργή / συνθετική παρακολούθηση στον χώρο των API ήταν κάπως περιορισμένη (και ακριβή). Η παρακολούθηση βάσει προγράμματος περιήγησης / σεναρίων είναι ακόμη πιο ιδιοκτησιακή και ακριβή. Χρησιμοποιούμε Puppeteer και κρατάμε τις τιμές όσο πιο χαμηλά γίνεται.

Η στοίβα παρακολούθησής μας:

Checkly (τρώμε το δικό μας φαγητό...)

AppOptics (προσαρμοσμένα γραφήματα)

AWS Cloudwatch και SNS για μηνύματα SMS.

ενσωματωμένες ειδοποιήσεις Heroku.

Pagerduty

Papertrail

Instana + Logz.io + slack

Το Instana μας ειδοποιεί στο slack για προβλήματα υποδομής ή υποβάθμιση απόδοσης, και έχουμε ρυθμίσει το logz.io να ειδοποιεί στο slack για συγκεκριμένο όγκο καταγραφών επιπέδου σφάλματος από το επίπεδο εφαρμογής.

SignalFX + Splunk + PagerDuty + Slack

Αυτή τη στιγμή χρησιμοποιούμε: SignalFX, Splunk, PagerDuty και Slack. Δεν είμαι μεγάλος θαυμαστής του SignalFX, αν και η ομάδα υποστήριξής τους είναι πολύ φιλική και ανταποκρίνεται άμεσα. Μου αρέσουν τα Splunk (αξίζει αν μπορείτε να το πληρώσετε), PagerDuty και Slack.

Παλιά χρησιμοποιούσα τη στοίβα TICK όπου το περισσότερο C ήταν στην πραγματικότητα G, δηλαδή Grafana, αν και χρησιμοποίησα λίγο και το Chronograf. Ήταν υπέροχο αλλά πόνος να το διαχειρίζεσαι. Το κλασικό δίλημμα SaaS έναντι αυτο-φιλοξενίας.

Έχω χρησιμοποιήσει DataDog, New Relic, Graylog, ELK και BugSnag. Μου αρέσουν πολύ τα DataDog και New Relic, το Graylog είναι αρκετά καλό. Δεν είμαι μεγάλος θαυμαστής του ELK. Το BugSnag είναι ωραίο, στην πραγματικότητα νιώθω ότι η ιχνηλάτηση σφαλμάτων/εξαιρέσεων είναι σε πολλές περιπτώσεις αρκετά καλός αντικαταστάτης της πλήρους παρακολούθησης καταγραφών.

ELK + Prometheus + Grafana

Όπως και άλλοι, χρησιμοποιούμε ELK για καταγραφές και Prometheus+Grafana για όλα τα υπόλοιπα.

Η συντήρηση αυτής της ρύθμισης είναι εύκολη αν επιτρέψετε στον εαυτό σας να χάνει περιστασιακά δεδομένα. Για παράδειγμα, αν η βάση δεδομένων ElasticSearch μας μπει σε κακή φάση (που συμβαίνει κάθε 2-3 μήνες δυστυχώς), δεν μπαίνουμε στον κόπο με HA και αντ' αυτού πετάμε τα δεδομένα και συνεχίζουμε τη ζωή μας. Αν πρέπει οπωσδήποτε να έχετε HA ή μακροπρόθεσμη διατήρηση, καλή τύχη.

Datadog + Prometheus + Grafana

Έστησα το Datadog με μηνιαία συνδρομή επειδή όταν ήρθα εδώ δεν υπήρχε παρακολούθηση ούτε ειδοποιήσεις. Μόνο μερικοί από τους ιστότοπούς μας παρακολουθούνταν κάθε 5 λεπτά για διαθεσιμότητα. Το Datadog είναι αναμφισβήτητα το ευκολότερο στη ρύθμιση. Όταν τελειώσω με όλα τα άλλα ζητήματα, θα αλλάξω σε Prometheus+Grafana. Δεν είμαι 100% αποφασισμένος ακόμη για τη διαχείριση καταγραφών.

Nagios + ELK

Υποστηρίζουμε πάνω από 100 προϊόντα.

Για on-prem, είναι κυρίως Nagios και ELK. Για το cloud, μεταναστεύουμε από DataDog σε NewRelic.

Datadog vs. Site24x7 + StatusCake + PagerDuty + SumoLogic + Slack

Παλιά χρησιμοποιούσαμε datadog αλλά το βρήκαμε υπερβολικά ακριβό για τις ανάγκες μας. Μη με παρεξηγήσετε, είναι καταπληκτικό, αλλά έχει τεράστιο κόστος. Καταφέραμε να στήσουμε το site24x7.com με ετήσια συνδρομή περίπου 2-3 μηνών του κόστους του DD.

Η στοίβα παρακολούθησής μας:

Site24x7 - APM, παρακολούθηση εξωτερικών URL, παρακολούθηση ροής αλληλογραφίας SMTP, λήξεις ssl και παρακολούθηση διεργασιών.

StatusCake - για παρακολούθηση και επιβεβαίωση URL - είναι το εφεδρικό μας σε περίπτωση που το site24x7 χάσει κάτι (δεν χάνει) αλλά το SC είναι πιο ευέλικτο για εξωτερικές θύρες και παρακολούθηση υπηρεσιών για τις ανάγκες μας.

Και τα δύο εργαλεία κλιμακώνουν στο PagerDuty και έπειτα λαμβάνουμε τις κλιμακώσεις στο slack.

SumoLogic - για παρακολούθηση καταγραφών (είναι εξαιρετικό εργαλείο αλλά λίγο περίπλοκο για τις ανάγκες μας)

Από το slack μπορούμε να επιβεβαιώσουμε ή να αποκαταστήσουμε την ειδοποίηση.

Έχουμε έπειτα πολλούς αυτοματισμούς site24x7 που συνδέονται με το commando.io για το «BedOps» όπως το λέμε — όπου μια ειδοποίηση πυροδοτείται, εκκινούμε μερικά σενάρια ή αυτοματισμούς σε μια απόπειρα αποκατάστασης της κατάστασης (στο 99% των περιπτώσεων ο αυτοματισμός + τα σενάριά μας μας κρατούν μακριά από προβλήματα).

Έχουμε εσωτερικά runbooks στη βάση γνώσεών μας για όταν οι αυτοματισμοί αποτυγχάνουν ή αν υπάρχει κάτι εκτός εύρους που πρέπει να διορθωθεί.

Prometheus + AlertManager + Grafana + Stackdriver

Prometheus (Operator) / AlertManager / Grafana για μετρικές στις συστοιχίες GKE και τις εικονικές μηχανές μας.

Google Stackdriver για καταγραφές (καθώς περιλαμβάνεται και είναι ενεργό από προεπιλογή και προς το παρόν επαρκεί για τις ανάγκες μας).

Zabbix

Zabbix για όλα. Δεν χρειάζεται επιπλέον λογισμικό.