Η μετάφραση του άρθρου ετοιμάστηκε ειδικά για τους φοιτητές του μαθήματος .
είναι προγραμματιστής λογισμικού, Go fanatic και λύτης προβλημάτων. Είναι επίσης συντηρητής του Prometheus και συνιδρυτής της Kubernetes SIG instrumentation. Στο παρελθόν, ήταν μηχανικός παραγωγής στο SoundCloud και ηγήθηκε της ομάδας παρακολούθησης στο CoreOS. Αυτήν τη στιγμή εργάζεται στην Google.
- Μηχανικός Υποδομής στο Improbable. Ενδιαφέρεται για τις νέες τεχνολογίες και τα προβλήματα των κατανεμημένων συστημάτων. Έχει εμπειρία προγραμματισμού χαμηλού επιπέδου στην Intel, εμπειρία συνεργάτη στη Mesos και παγκόσμιας κλάσης εμπειρία παραγωγής SRE στο Improbable. Αφιερωμένο στη βελτίωση του κόσμου των μικροϋπηρεσιών. Οι τρεις του αγάπες: Golang, open source και βόλεϊ.
Εξετάζοντας το κορυφαίο προϊόν μας SpatialOS, μπορείτε να μαντέψετε ότι το Improbable απαιτεί μια εξαιρετικά δυναμική, παγκόσμιας κλίμακας υποδομή cloud με δεκάδες συμπλέγματα Kubernetes. Ήμασταν από τους πρώτους που χρησιμοποιήσαμε σύστημα παρακολούθησης . Ο Prometheus είναι σε θέση να παρακολουθεί εκατομμύρια μετρήσεις σε πραγματικό χρόνο και διαθέτει μια ισχυρή γλώσσα ερωτημάτων που σας επιτρέπει να εξάγετε τις πληροφορίες που χρειάζεστε.
Η απλότητα και η αξιοπιστία του Prometheus είναι ένα από τα κύρια πλεονεκτήματά του. Ωστόσο, μόλις ξεπεράσαμε μια συγκεκριμένη κλίμακα, αντιμετωπίσαμε πολλά μειονεκτήματα. Για να λύσουμε αυτά τα προβλήματα έχουμε αναπτύξει είναι ένα έργο ανοιχτού κώδικα που δημιουργήθηκε από την Improbable για να μετατρέψει απρόσκοπτα τα υπάρχοντα συμπλέγματα Prometheus σε ένα ενιαίο σύστημα παρακολούθησης με απεριόριστη αποθήκευση ιστορικών δεδομένων. Το Thanos είναι διαθέσιμο στο Github .
Οι στόχοι μας με τον Θάνο
Σε μια συγκεκριμένη κλίμακα, προκύπτουν προβλήματα που ξεπερνούν τις δυνατότητες του Vanilla Prometheus. Πώς να αποθηκεύσετε αξιόπιστα και οικονομικά petabyte ιστορικών δεδομένων; Μπορεί να γίνει αυτό χωρίς συμβιβασμούς στον χρόνο απόκρισης; Είναι δυνατή η πρόσβαση σε όλες τις μετρήσεις που βρίσκονται σε διαφορετικούς διακομιστές Prometheus με ένα μόνο αίτημα API; Υπάρχει κάποιος τρόπος να συνδυαστούν τα αναπαραγόμενα δεδομένα που συλλέγονται χρησιμοποιώντας το Prometheus HA;
Για να αντιμετωπίσουμε αυτά τα ζητήματα, δημιουργήσαμε το Thanos. Οι ακόλουθες ενότητες περιγράφουν πώς προσεγγίσαμε αυτά τα ζητήματα και εξηγούν τους στόχους μας.
Ερώτηση δεδομένων από πολλές περιπτώσεις Prometheus (σφαιρικό ερώτημα)
Ο Prometheus προσφέρει μια λειτουργική προσέγγιση στο Sharding. Ακόμη και ένας διακομιστής Prometheus παρέχει αρκετή επεκτασιμότητα για να απελευθερώσει τους χρήστες από την πολυπλοκότητα του οριζόντιου διαμοιρασμού σε όλες σχεδόν τις περιπτώσεις χρήσης.
Αν και αυτό είναι ένα εξαιρετικό μοντέλο ανάπτυξης, είναι συχνά απαραίτητο να έχετε πρόσβαση σε δεδομένα σε διαφορετικούς διακομιστές Prometheus μέσω ενός μόνο API ή UI - μια καθολική προβολή. Φυσικά, είναι δυνατή η εμφάνιση πολλών ερωτημάτων σε έναν πίνακα Grafana, αλλά κάθε ερώτημα μπορεί να εκτελεστεί μόνο σε έναν διακομιστή Prometheus. Από την άλλη πλευρά, με το Thanos μπορείτε να κάνετε ερωτήσεις και να συγκεντρώνετε δεδομένα από πολλούς διακομιστές Prometheus, καθώς είναι όλοι προσβάσιμοι από ένα μόνο τελικό σημείο.
Προηγουμένως, για να έχουμε μια συνολική εικόνα στο Improbable, οργανώσαμε τις εμφανίσεις μας Prometheus σε ένα πολυεπίπεδο . Αυτό σήμαινε τη δημιουργία ενός διακομιστή meta Prometheus που συλλέγει ορισμένες από τις μετρήσεις από κάθε διακομιστή φύλλου.
Αυτή η προσέγγιση αποδείχθηκε προβληματική. Αυτό είχε ως αποτέλεσμα πιο περίπλοκες διαμορφώσεις, την προσθήκη ενός επιπλέον πιθανού σημείου αστοχίας και την εφαρμογή πολύπλοκων κανόνων για να διασφαλιστεί ότι το ενοποιημένο τελικό σημείο λαμβάνει μόνο τα δεδομένα που χρειάζεται. Επιπλέον, αυτού του είδους η ομοσπονδία δεν σας επιτρέπει να αποκτήσετε μια πραγματική καθολική προβολή, καθώς δεν είναι διαθέσιμα όλα τα δεδομένα από ένα μόνο αίτημα API.
Στενά συνδεδεμένη με αυτό είναι μια ενοποιημένη προβολή των δεδομένων που συλλέγονται σε διακομιστές Prometheus υψηλής διαθεσιμότητας (HA). Το μοντέλο HA του Προμηθέα συλλέγει ανεξάρτητα δεδομένα δύο φορές, κάτι που είναι τόσο απλό που δεν θα μπορούσε να είναι απλούστερο. Ωστόσο, η χρήση μιας συνδυασμένης και μη διπλής προβολής και των δύο ροών θα ήταν πολύ πιο βολική.
Φυσικά, υπάρχει ανάγκη για εξαιρετικά διαθέσιμους διακομιστές Prometheus. Στο Improbable, παίρνουμε πολύ σοβαρά την παρακολούθηση δεδομένων λεπτό προς λεπτό, αλλά το να έχουμε μία παρουσία του Prometheus ανά σύμπλεγμα είναι ένα μόνο σημείο αποτυχίας. Οποιοδήποτε σφάλμα διαμόρφωσης ή αποτυχία υλικού μπορεί ενδεχομένως να οδηγήσει σε απώλεια σημαντικών δεδομένων. Ακόμη και μια απλή ανάπτυξη μπορεί να προκαλέσει μικρές διακοπές στη συλλογή μετρήσεων, επειδή οι επανεκκινήσεις μπορεί να είναι σημαντικά μεγαλύτερες από το διάστημα απόξεσης.
Αξιόπιστη αποθήκευση ιστορικών δεδομένων
Η φθηνή, γρήγορη, μακροπρόθεσμη αποθήκευση μετρήσεων είναι το όνειρό μας (που μοιράζονται οι περισσότεροι χρήστες του Prometheus). Στο Απίθανο, αναγκαστήκαμε να διαμορφώσουμε την περίοδο διατήρησης μετρήσεων σε εννέα ημέρες (για το Prometheus 1.8). Αυτό προσθέτει προφανή όρια στο πόσο πίσω μπορούμε να κοιτάξουμε.
Το Prometheus 2.0 έχει βελτιωθεί από αυτή την άποψη, καθώς ο αριθμός των χρονοσειρών δεν επηρεάζει πλέον τη συνολική απόδοση του διακομιστή (βλ. ). Ωστόσο, ο Prometheus αποθηκεύει δεδομένα σε τοπικό δίσκο. Παρόλο που η συμπίεση δεδομένων υψηλής απόδοσης μπορεί να μειώσει σημαντικά την τοπική χρήση SSD, τελικά εξακολουθεί να υπάρχει ένα όριο στην ποσότητα των ιστορικών δεδομένων που μπορούν να αποθηκευτούν.
Επιπλέον, στο Improbable νοιαζόμαστε για την αξιοπιστία, την απλότητα και το κόστος. Οι μεγάλοι τοπικοί δίσκοι είναι πιο δύσκολο να λειτουργήσουν και να δημιουργήσουν αντίγραφα ασφαλείας. Κοστίζουν περισσότερο και απαιτούν περισσότερα εργαλεία δημιουργίας αντιγράφων ασφαλείας, με αποτέλεσμα περιττή πολυπλοκότητα.
Μείωση δειγματοληψίας
Μόλις ξεκινήσαμε να εργαζόμαστε με ιστορικά δεδομένα, συνειδητοποιήσαμε ότι υπάρχουν θεμελιώδεις δυσκολίες με το big-O που κάνουν τα ερωτήματα πιο αργά και πιο αργά καθώς εργαζόμαστε με εβδομάδες, μήνες και χρόνια δεδομένων.
Η τυπική λύση σε αυτό το πρόβλημα θα ήταν (downsampling) - μείωση της συχνότητας δειγματοληψίας σήματος. Με τη μείωση δειγματοληψίας, μπορούμε να «προσαρμόσουμε» σε μεγαλύτερο χρονικό εύρος και να διατηρήσουμε τον ίδιο αριθμό δειγμάτων, διατηρώντας τα ερωτήματα ανταποκρινόμενα.
Η μείωση δειγματοληψίας παλαιών δεδομένων είναι αναπόφευκτη απαίτηση οποιασδήποτε λύσης μακροπρόθεσμης αποθήκευσης και είναι πέρα από το πεδίο εφαρμογής της Vanilla Prometheus.
Πρόσθετοι στόχοι
Ένας από τους αρχικούς στόχους του έργου Thanos ήταν η απρόσκοπτη ενσωμάτωση με οποιεσδήποτε υπάρχουσες εγκαταστάσεις του Prometheus. Ο δεύτερος στόχος ήταν η ευκολία λειτουργίας με ελάχιστα εμπόδια εισόδου. Τυχόν εξαρτήσεις θα πρέπει να ικανοποιούνται εύκολα τόσο για μικρούς όσο και για μεγάλους χρήστες, πράγμα που σημαίνει επίσης χαμηλό βασικό κόστος.
Θάνος αρχιτεκτονική
Αφού απαριθμήσουμε τους στόχους μας στην προηγούμενη ενότητα, ας τους επεξεργαστούμε και ας δούμε πώς ο Thanos λύνει αυτά τα προβλήματα.
Σφαιρική άποψη
Για να έχουμε μια συνολική προβολή πάνω από τις υπάρχουσες περιπτώσεις Prometheus, πρέπει να συνδέσουμε ένα μόνο σημείο εισόδου αιτήματος σε όλους τους διακομιστές. Αυτό ακριβώς κάνει το στοιχείο Thanos. . Αναπτύσσεται δίπλα σε κάθε διακομιστή Prometheus και λειτουργεί ως διακομιστής μεσολάβησης, εξυπηρετώντας τοπικά δεδομένα του Prometheus μέσω του gRPC Store API, επιτρέποντας την ανάκτηση δεδομένων χρονοσειρών ανά ετικέτα και χρονικό εύρος.
Από την άλλη πλευρά είναι το ανεπτυγμένο, χωρίς πολιτεία στοιχείο Querier, το οποίο κάνει λίγα περισσότερα από το να απαντά απλώς σε ερωτήματα PromQL μέσω του τυπικού Prometheus HTTP API. Το Querier, το Sidecar και άλλα στοιχεία Thanos επικοινωνούν μέσω .
- Η Querier, μόλις λάβει ένα αίτημα, συνδέεται με τον αντίστοιχο διακομιστή API του Store, δηλαδή με τα Sidecars μας και λαμβάνει δεδομένα χρονοσειρών από τους αντίστοιχους διακομιστές Prometheus.
- Μετά από αυτό, συνδυάζει τις απαντήσεις και εκτελεί ένα ερώτημα PromQL σε αυτές. Το Querier μπορεί να συγχωνεύσει τόσο χωριστά δεδομένα όσο και διπλότυπα δεδομένα από διακομιστές Prometheus HA.
Αυτό λύνει ένα σημαντικό κομμάτι του παζλ μας - συνδυάζοντας δεδομένα από απομονωμένους διακομιστές Prometheus σε μια ενιαία προβολή. Στην πραγματικότητα, το Thanos μπορεί να χρησιμοποιηθεί μόνο για αυτήν τη λειτουργία. Δεν χρειάζεται να γίνουν αλλαγές στους υπάρχοντες διακομιστές Prometheus!
Απεριόριστη διάρκεια ζωής!
Ωστόσο, αργά ή γρήγορα θα θέλουμε να αποθηκεύσουμε δεδομένα πέρα από τον κανονικό χρόνο διατήρησης του Prometheus. Επιλέξαμε την αποθήκευση αντικειμένων για την αποθήκευση ιστορικών δεδομένων. Είναι ευρέως διαθέσιμο σε οποιοδήποτε cloud, καθώς και σε κέντρα δεδομένων εσωτερικής χρήσης και είναι πολύ αποδοτικό. Επιπλέον, σχεδόν κάθε αποθήκευση αντικειμένων είναι διαθέσιμη μέσω του γνωστού S3 API.
Ο Prometheus γράφει δεδομένα από τη μνήμη RAM στο δίσκο περίπου κάθε δύο ώρες. Το μπλοκ αποθηκευμένων δεδομένων περιέχει όλα τα δεδομένα για μια καθορισμένη χρονική περίοδο και είναι αμετάβλητο. Αυτό είναι πολύ βολικό γιατί το Thanos Sidecar μπορεί απλώς να κοιτάξει τον κατάλογο δεδομένων Prometheus και, καθώς γίνονται διαθέσιμα νέα μπλοκ, να τα φορτώσει σε κάδους αποθήκευσης αντικειμένων.
Η φόρτωση στην αποθήκευση αντικειμένων αμέσως μετά την εγγραφή στο δίσκο σάς επιτρέπει επίσης να διατηρήσετε την απλότητα του ξύστρα (Prometheus και Thanos Sidecar). Κάτι που απλοποιεί την υποστήριξη, το κόστος και το σχεδιασμό του συστήματος.
Όπως μπορείτε να δείτε, η δημιουργία αντιγράφων ασφαλείας δεδομένων είναι πολύ απλή. Τι γίνεται όμως με την αναζήτηση δεδομένων στην αποθήκευση αντικειμένων;
Το στοιχείο Thanos Store λειτουργεί ως διακομιστής μεσολάβησης για την ανάκτηση δεδομένων από την αποθήκευση αντικειμένων. Όπως και ο Thanos Sidecar, συμμετέχει στο σύμπλεγμα gossip και υλοποιεί το Store API. Με αυτόν τον τρόπο, το υπάρχον Querier μπορεί να το χειριστεί σαν Sidecar, ως άλλη πηγή δεδομένων χρονοσειρών - δεν απαιτείται ειδική διαμόρφωση.
Τα μπλοκ δεδομένων χρονοσειρών αποτελούνται από πολλά μεγάλα αρχεία. Η φόρτωσή τους κατ' απαίτηση θα ήταν αρκετά αναποτελεσματική και η τοπική αποθήκευση στην προσωρινή μνήμη θα απαιτούσε τεράστιο όγκο μνήμης και χώρου στο δίσκο.
Αντίθετα, το Store Gateway ξέρει πώς να χειρίζεται τη μορφή αποθήκευσης Prometheus. Χάρη σε έναν έξυπνο προγραμματιστή ερωτημάτων και την προσωρινή αποθήκευση μόνο των απαραίτητων τμημάτων ευρετηρίου μπλοκ, είναι δυνατός ο περιορισμός σύνθετων ερωτημάτων σε έναν ελάχιστο αριθμό αιτημάτων HTTP για να αντιταχθούν τα αρχεία αποθήκευσης. Με αυτόν τον τρόπο, μπορείτε να μειώσετε τον αριθμό των αιτημάτων κατά τέσσερις έως έξι τάξεις μεγέθους και να επιτύχετε χρόνους απόκρισης που είναι γενικά δύσκολο να διακριθούν από αιτήματα σε δεδομένα σε τοπικό SSD.
Όπως φαίνεται στο παραπάνω διάγραμμα, το Thanos Querier μειώνει σημαντικά το κόστος ανά ερώτημα δεδομένων αποθήκευσης αντικειμένων αξιοποιώντας τη μορφή αποθήκευσης Prometheus και τοποθετώντας τα σχετικά δεδομένα δίπλα-δίπλα. Χρησιμοποιώντας αυτήν την προσέγγιση, μπορούμε να συνδυάσουμε πολλά μεμονωμένα αιτήματα σε έναν ελάχιστο αριθμό μαζικών λειτουργιών.
Συμπίεση και μείωση δειγματοληψίας
Μόλις ένα νέο μπλοκ δεδομένων χρονοσειρών φορτωθεί με επιτυχία στην αποθήκευση αντικειμένων, το αντιμετωπίζουμε ως "ιστορικά" δεδομένα, τα οποία είναι άμεσα διαθέσιμα μέσω του Store Gateway.
Ωστόσο, μετά από κάποιο χρονικό διάστημα, μπλοκ από μία πηγή (Prometheus with Sidecar) συσσωρεύονται και δεν χρησιμοποιούν πλέον το πλήρες δυναμικό ευρετηρίασης. Για να λύσουμε αυτό το πρόβλημα, παρουσιάσαμε ένα άλλο στοιχείο που ονομάζεται Compactor. Απλώς εφαρμόζει τη μηχανή τοπικής συμπίεσης του Prometheus σε ιστορικά δεδομένα στην αποθήκευση αντικειμένων και μπορεί να εκτελεστεί ως απλή περιοδική εργασία δέσμης.
Χάρη στην αποτελεσματική συμπίεση, η αναζήτηση της αποθήκευσης για μεγάλο χρονικό διάστημα δεν δημιουργεί πρόβλημα όσον αφορά το μέγεθος των δεδομένων. Ωστόσο, το πιθανό κόστος της αποσυσκευασίας ενός δισεκατομμυρίου τιμών και της εκτέλεσής τους μέσω ενός επεξεργαστή ερωτημάτων θα οδηγήσει αναπόφευκτα σε δραματική αύξηση του χρόνου εκτέλεσης ερωτημάτων. Από την άλλη πλευρά, δεδομένου ότι υπάρχουν εκατοντάδες σημεία δεδομένων ανά pixel στην οθόνη, καθίσταται αδύνατο να απεικονιστούν ακόμη και τα δεδομένα σε πλήρη ανάλυση. Έτσι, η μείωση δειγματοληψίας όχι μόνο είναι δυνατή, αλλά και δεν θα οδηγήσει σε αισθητή απώλεια ακρίβειας.
Για τη μείωση του δείγματος δεδομένων, το Compactor συγκεντρώνει συνεχώς δεδομένα σε ανάλυση πέντε λεπτών και μίας ώρας. Για κάθε ακατέργαστο κομμάτι που κωδικοποιείται χρησιμοποιώντας συμπίεση TSDB XOR, αποθηκεύονται διαφορετικοί τύποι συγκεντρωτικών δεδομένων, όπως το ελάχιστο, το μέγιστο ή το άθροισμα για ένα μπλοκ. Αυτό επιτρέπει στο Querier να επιλέξει αυτόματα ένα άθροισμα που είναι κατάλληλο για ένα δεδομένο ερώτημα PromQL.
Δεν απαιτείται ειδική διαμόρφωση ώστε ο χρήστης να χρησιμοποιεί δεδομένα μειωμένης ακρίβειας. Το Querier αλλάζει αυτόματα μεταξύ διαφορετικών αναλύσεων και μη επεξεργασμένων δεδομένων καθώς ο χρήστης κάνει μεγέθυνση και σμίκρυνση. Εάν είναι επιθυμητό, ο χρήστης μπορεί να το ελέγξει απευθείας μέσω της παραμέτρου «βήμα» στο αίτημα.
Δεδομένου ότι το κόστος αποθήκευσης ενός GB είναι χαμηλό, από προεπιλογή το Thanos αποθηκεύει ακατέργαστα δεδομένα, δεδομένα ανάλυσης πέντε λεπτών και μιας ώρας. Δεν χρειάζεται να διαγράψετε τα αρχικά δεδομένα.
Κανόνες εγγραφής
Ακόμη και με τον Thanos, οι κανόνες εγγραφής αποτελούν ουσιαστικό μέρος της στοίβας παρακολούθησης. Μειώνουν την πολυπλοκότητα, την καθυστέρηση και το κόστος των ερωτημάτων. Είναι επίσης βολικό για τους χρήστες να λαμβάνουν συγκεντρωτικά δεδομένα με μετρήσεις. Το Thanos βασίζεται σε περιπτώσεις βανίλιας Prometheus, επομένως είναι απολύτως αποδεκτό να αποθηκεύονται κανόνες εγγραφής και κανόνες ειδοποίησης σε έναν υπάρχοντα διακομιστή Prometheus. Ωστόσο, σε ορισμένες περιπτώσεις αυτό μπορεί να μην είναι αρκετό:
- Καθολική ειδοποίηση και κανόνας (για παράδειγμα, μια ειδοποίηση όταν μια υπηρεσία δεν λειτουργεί σε περισσότερα από δύο από τα τρία συμπλέγματα).
- Κανόνας για δεδομένα εκτός τοπικής αποθήκευσης.
- Η επιθυμία αποθήκευσης όλων των κανόνων και των ειδοποιήσεων σε ένα μέρος.
Για όλες αυτές τις περιπτώσεις, το Thanos περιλαμβάνει ένα ξεχωριστό στοιχείο που ονομάζεται Ruler, το οποίο υπολογίζει τον κανόνα και την ειδοποίηση μέσω του Thanos Queries. Παρέχοντας ένα γνωστό StoreAPI, ο κόμβος Query μπορεί να έχει πρόσβαση σε πρόσφατα υπολογισμένες μετρήσεις. Αργότερα αποθηκεύονται επίσης σε αποθήκευση αντικειμένων και διατίθενται μέσω του Store Gateway.
Η Δύναμη του Θάνου
Το Thanos είναι αρκετά ευέλικτο ώστε να προσαρμόζεται στις ανάγκες σας. Αυτό είναι ιδιαίτερα χρήσιμο κατά τη μετανάστευση από τον απλό Προμηθέα. Ας ανακεφαλαιώσουμε γρήγορα όσα μάθαμε για τα στοιχεία Thanos με ένα γρήγορο παράδειγμα. Δείτε πώς να μεταφέρετε τη βανίλια σας Prometheus στον κόσμο της «απεριόριστης αποθήκευσης μετρήσεων»:
- Προσθέστε το Thanos Sidecar στους διακομιστές σας Prometheus - για παράδειγμα, ένα κοντέινερ sidecar σε μια ομάδα Kubernetes.
- Αναπτύξτε πολλά αντίγραφα Thanos Querier για να μπορείτε να προβάλλετε δεδομένα. Σε αυτό το στάδιο είναι εύκολο να δημιουργήσετε κουτσομπολιά μεταξύ του Scraper και του Querier. Για να ελέγξετε την αλληλεπίδραση των στοιχείων, χρησιμοποιήστε τη μέτρηση "thanos_cluster_members".
Αυτά τα δύο μόνο βήματα είναι αρκετά για να παρέχουν σφαιρική προβολή και απρόσκοπτη αφαίρεση δεδομένων από πιθανά αντίγραφα του Prometheus HA! Απλώς συνδέστε τους πίνακες εργαλείων σας στο τελικό σημείο HTTP του Querier ή χρησιμοποιήστε απευθείας τη διεπαφή χρήστη Thanos.
Ωστόσο, εάν χρειάζεστε δημιουργία αντιγράφων ασφαλείας μετρήσεων και μακροπρόθεσμη αποθήκευση, θα χρειαστεί να ολοκληρώσετε τρία ακόμη βήματα:
- Δημιουργήστε έναν κάδο AWS S3 ή GCS. Διαμορφώστε το Sidecar για να αντιγράψει δεδομένα σε αυτούς τους κάδους. Η τοπική αποθήκευση δεδομένων μπορεί πλέον να ελαχιστοποιηθεί.
- Αναπτύξτε το Store Gateway και συνδέστε το με το υπάρχον σύμπλεγμα κουτσομπολιού. Τώρα μπορείτε να ρωτήσετε τα δεδομένα που έχουν δημιουργηθεί αντίγραφα ασφαλείας!
- Αναπτύξτε το Compactor για να βελτιώσετε την αποτελεσματικότητα των ερωτημάτων για μεγάλες χρονικές περιόδους χρησιμοποιώντας συμπίεση και μείωση δειγματοληψίας.
Αν θέλετε να μάθετε περισσότερα, μη διστάσετε να ρίξετε μια ματιά στο δικό μας и !
Με πέντε μόλις βήματα, μετατρέψαμε τον Prometheus σε ένα αξιόπιστο σύστημα παρακολούθησης με παγκόσμια προβολή, απεριόριστο χρόνο αποθήκευσης και πιθανή υψηλή διαθεσιμότητα μετρήσεων.
Αίτημα έλξης: σε χρειαζόμαστε!
ήταν ένα έργο ανοιχτού κώδικα από την αρχή. Η απρόσκοπτη ενσωμάτωση με τον Prometheus και η δυνατότητα χρήσης μόνο ενός τμήματος του Thanos το καθιστά εξαιρετική επιλογή για την εύκολη κλιμάκωση του συστήματος παρακολούθησης.
Πάντα καλωσορίζουμε τα αιτήματα και τα ζητήματα έλξης GitHub. Εν τω μεταξύ, μη διστάσετε να επικοινωνήσετε μαζί μας μέσω Github Issues ή slackεάν έχετε ερωτήσεις ή σχόλια ή θέλετε να μοιραστείτε την εμπειρία σας από τη χρήση του! Αν σας αρέσει αυτό που κάνουμε στο Improbable, μη διστάσετε να επικοινωνήσετε μαζί μας - !
Πηγή: www.habr.com