Γεια σε όλους! Στο δικό του τελευταίο άρθρο Έγραψα για την οργάνωση ενός αρθρωτού συστήματος παρακολούθησης για μια αρχιτεκτονική μικροϋπηρεσιών. Τίποτα δεν παραμένει στάσιμο, το έργο μας αυξάνεται συνεχώς, όπως και ο αριθμός των αποθηκευμένων μετρήσεων. Πώς οργανώσαμε τη μετάβαση από το Graphite + Whisper στο Graphite + ClickHouse υπό συνθήκες υψηλού φορτίου, διαβάστε για τις προσδοκίες από αυτό και τα αποτελέσματα της μετεγκατάστασης κάτω από την περικοπή.

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

Προβλήματα Graphite+Whisper

1. Υψηλό φορτίο στο υποσύστημα δίσκου

Τη στιγμή της μετάβασης, περίπου 1.5 εκατομμύριο μετρήσεις ανά λεπτό πετούσαν σε εμάς. Με αυτή τη ροή, η χρήση του δίσκου στους διακομιστές ήταν ~30%. Γενικά, ήταν αρκετά αποδεκτό - όλα λειτουργούσαν σταθερά, γράφτηκαν γρήγορα, διαβάζονταν γρήγορα ... Μέχρι που μια από τις ομάδες ανάπτυξης κυκλοφόρησε μια νέα δυνατότητα και άρχισε να μας στέλνει 10 εκατομμύρια μετρήσεις ανά λεπτό. Τότε ήταν που το υποσύστημα του δίσκου σφίχτηκε και είδαμε 100% χρήση. Το πρόβλημα λύθηκε γρήγορα, αλλά το ίζημα παρέμεινε.

2. Έλλειψη αντιγραφής και συνέπειας

Πιθανότατα, όπως όλοι όσοι χρησιμοποιούν / χρησιμοποίησαν Graphite + Whisper, χύσαμε την ίδια ροή μετρήσεων σε πολλούς διακομιστές Graphite ταυτόχρονα για να δημιουργήσουμε ανοχή σφαλμάτων. Και δεν υπήρχαν ειδικά προβλήματα με αυτό - μέχρι τη στιγμή που ένας από τους διακομιστές δεν έπεσε για κάποιο λόγο. Μερικές φορές καταφέραμε να εμφανίσουμε τον πεσμένο διακομιστή αρκετά γρήγορα και το carbon-c-relay κατάφερε να τον γεμίσει με μετρήσεις από την κρυφή μνήμη του, και μερικές φορές όχι. Και μετά υπήρχε μια τρύπα στις μετρήσεις, την οποία καλύψαμε με rsync. Η διαδικασία ήταν αρκετά μεγάλη. Σώθηκε μόνο από το γεγονός ότι αυτό συνέβη πολύ σπάνια. Παίρναμε επίσης περιοδικά ένα τυχαίο σύνολο μετρήσεων και τις συγκρίναμε με άλλες παρόμοιες σε γειτονικούς κόμβους του συμπλέγματος. Στο 5% περίπου των περιπτώσεων διέφεραν αρκετές τιμές, κάτι που δεν μας χαροποίησε ιδιαίτερα.

3. Μεγάλος χώρος που καταλαμβάνεται

Δεδομένου ότι γράφουμε στο Graphite όχι μόνο υποδομές, αλλά και μετρήσεις επιχειρήσεων (και τώρα επίσης μετρήσεις από την Kubernetes), έχουμε πολύ συχνά μια κατάσταση στην οποία υπάρχουν μόνο λίγες τιμές στη μέτρηση και το αρχείο .wsp δημιουργείται λαμβάνοντας λαμβάνοντας υπόψη ολόκληρη την περίοδο διατήρησης και καταλαμβάνει ένα προκατανεμημένο χώρο, τον οποίο είχαμε ~ 2 MB. Το πρόβλημα επιδεινώνεται από το γεγονός ότι υπάρχουν πολλά τέτοια αρχεία με την πάροδο του χρόνου και κατά τη δημιουργία αναφορών σε αυτά, η ανάγνωση κενών σημείων απαιτεί πολύ χρόνο και πόρους.

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

Έχοντας όλα τα παραπάνω (λαμβάνοντας υπόψη τα προηγούμενα Άρθρο), καθώς και μια σταθερή αύξηση του αριθμού των ληφθέντων μετρήσεων, η επιθυμία μεταφοράς όλων των μετρήσεων σε διάστημα αποθήκευσης 30 δευτερολέπτων. (έως και 10 δευτερόλεπτα εάν είναι απαραίτητο), αποφασίσαμε να δοκιμάσουμε το Graphite+ClickHouse ως μια πολλά υποσχόμενη εναλλακτική του Whisper.

Graphite+ClickHouse. προσδοκίες

Έχοντας επισκεφτεί αρκετές συναντήσεις των ανδρών από το Yandex, έχοντας διαβάσει μερικά άρθρα για το Habré, αφού περάσαμε από την τεκμηρίωση και βρήκαμε λογικά στοιχεία για τη σύνδεση του ClickHouse κάτω από το Graphite, αποφασίσαμε να δράσουμε!

Θα θέλατε να λάβετε τα ακόλουθα:

μείωση της χρήσης του υποσυστήματος του δίσκου από 30% σε 5%.
μειώστε τον χώρο που καταλαμβάνεται από 1 TB σε 100 GB.
να μπορεί να λαμβάνει 100 εκατομμύρια μετρήσεις ανά λεπτό στον διακομιστή.
αναπαραγωγή δεδομένων και ανοχή σφαλμάτων έξω από το κουτί.
Μην κάθεστε σε αυτό το έργο για ένα χρόνο και κάνετε τη μετάβαση για κάποια λογική περίοδο.
διακόπτη χωρίς διακοπή λειτουργίας.

Αρκετά φιλόδοξο, σωστά;

Graphite+ClickHouse. Συστατικά

Για να λάβω δεδομένα μέσω του πρωτοκόλλου Graphite και μετά να τα γράψω στο ClickHouse, επέλεξα carbon-clickhouse (γκολάνγκ).

Η τελευταία έκδοση ClickHouse της σταθερής έκδοσης 1.1.54253 επιλέχθηκε ως βάση δεδομένων για την αποθήκευση χρονοσειρών. Κατά την εργασία με αυτό, υπήρχαν προβλήματα: ένα βουνό από σφάλματα χύθηκε στα κούτσουρα και δεν ήταν απολύτως σαφές τι να κάνει με αυτά. Σε συζήτηση με Ρομάν Λομονόσοφ (συγγραφέας του carbon-clickhouse, graphite-clickhouse και πολλών άλλων) επιλέχθηκε το παλαιότερο έκδοση 1.1.54236. Τα σφάλματα εξαφανίστηκαν - όλα άρχισαν να λειτουργούν με ένα κτύπημα.

Επιλέχθηκε η ανάγνωση δεδομένων από το ClickHouse γραφίτης-κλικ (γκολάνγκ). Ως API για Graphite − καρμπονάπι (γκολάνγκ). Για την οργάνωση της αναπαραγωγής μεταξύ των πινάκων, χρησιμοποιήθηκε το ClickHouse ζωοφύλακας. Για τις μετρήσεις δρομολόγησης, αφήσαμε την αγαπημένη μας carbon-c-relay (Γ) (δείτε προηγούμενο άρθρο).

Graphite+ClickHouse. Δομή πίνακα

Το "graphite" είναι μια βάση δεδομένων που δημιουργήσαμε για την παρακολούθηση πινάκων.

Το "graphite.metrics" είναι ένας πίνακας με τη μηχανή ReplicatedReplacingMergeTree (αναπαράγεται Αντικατάσταση του MergeTree). Αυτός ο πίνακας αποθηκεύει τα ονόματα των μετρήσεων και τις διαδρομές προς αυτές.

CREATE TABLE graphite.metrics ( Date Date, Level UInt32, Path String, Deleted UInt8, Version UInt32 ) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.metrics', ‘r1’, Date, (Level, Path), 8192, Version);

Το "graphite.data" είναι ένας πίνακας με τη μηχανή ReplicatedGraphiteMergeTree (αναπαράγεται GraphiteMergeTree). Αυτός ο πίνακας αποθηκεύει τιμές μετρήσεων.

CREATE TABLE graphite.data ( Path String, Value Float64, Time UInt32, Date Date, Timestamp UInt32 ) ENGINE = ReplicatedGraphiteMergeTree('/clickhouse/tables/replicator/graphite.data', 'r1', Date, (Path, Time), 8192, 'graphite_rollup')

Το "graphite.date_metrics" είναι ένας πίνακας που συμπληρώνεται υπό όρους με τη μηχανή ReplicatedReplacingMergeTree. Αυτός ο πίνακας περιέχει τα ονόματα όλων των μετρήσεων που συναντήθηκαν κατά τη διάρκεια της ημέρας. Οι λόγοι δημιουργίας περιγράφονται στην ενότητα "Προβλήματα" στο τέλος αυτού του άρθρου.

CREATE MATERIALIZED VIEW graphite.date_metrics ( Path String,  Level UInt32,  Date Date) ENGINE = ReplicatedReplacingMergeTree('/clickhouse/tables/replicator/graphite.date_metrics', 'r1', Date, (Level, Path, Date), 8192) AS SELECT toUInt32(length(splitByChar('.', Path))) AS Level, Date, Path FROM graphite.data

Το "graphite.data_stat" είναι ένας πίνακας υπό όρους με τη μηχανή ReplicatedAggregatingMergeTree (αναπαράγεται AggregatingMergeTree). Αυτός ο πίνακας καταγράφει τον αριθμό των εισερχόμενων μετρήσεων, κατανεμημένων σε 4 επίπεδα ένθεσης.

CREATE MATERIALIZED VIEW graphite.data_stat ( Date Date,  Prefix String,  Timestamp UInt32,  Count AggregateFunction(count)) ENGINE = ReplicatedAggregatingMergeTree('/clickhouse/tables/replicator/graphite.data_stat', 'r1', Date, (Timestamp, Prefix), 8192) AS SELECT toStartOfMonth(now()) AS Date, replaceRegexpOne(Path, '^([^.]+.[^.]+.[^.]+).*$', '1') AS Prefix, toUInt32(toStartOfMinute(toDateTime(Timestamp))) AS Timestamp, countState() AS Count FROM graphite.data  GROUP BY Timestamp, Prefix

Graphite+ClickHouse. Σχέδιο αλληλεπίδρασης εξαρτημάτων

Graphite+ClickHouse. Μετανάστευση δεδομένων

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

Προστέθηκε ένας κανόνας στο carbon-c-relay για την αποστολή μιας πρόσθετης ροής μετρήσεων στο carbon-clickhouse ενός από τους διακομιστές που εμπλέκονται στην αναπαραγωγή πινάκων ClickHouse.
Γράψαμε ένα μικρό σενάριο python που, χρησιμοποιώντας τη βιβλιοθήκη whisper-dump, διάβαζε όλα τα αρχεία .wsp από τον αποθηκευτικό μας χώρο και έστειλε αυτά τα δεδομένα στο carbon-clickhouse που περιγράφεται παραπάνω σε 24 νήματα. Ο αριθμός των αποδεκτών μετρικών τιμών στο carbon-clickhouse έφτασε τα 125 εκατομμύρια / λεπτό και το ClickHouse δεν ίδρωσε καν.
Δημιουργήσαμε ένα ξεχωριστό DataSource στο Grafana για τον εντοπισμό σφαλμάτων των συναρτήσεων που χρησιμοποιούνται σε υπάρχοντες πίνακες εργαλείων. Αποκαλύφθηκε μια λίστα με χαρακτηριστικά που χρησιμοποιήσαμε, αλλά δεν εφαρμόστηκαν στο carbonapi. Τελειώσαμε αυτές τις λειτουργίες και στείλαμε PR στους συντάκτες του carbonapi (ιδιαίτερες ευχαριστίες σε αυτούς).
Για να αλλάξουμε το φορτίο ανάγνωσης στις ρυθμίσεις του εξισορροπητή, αλλάξαμε τα τελικά σημεία από graphite-api (διεπαφή API για Graphite+Whisper) σε carbonapi.

Graphite+ClickHouse. Αποτελέσματα

μείωσε τη χρήση του υποσυστήματος δίσκου από 30% σε 1%.
μείωσε τον χώρο που καταλαμβάνεται από 1 TB σε 300 GB.
έχουμε τη δυνατότητα να λαμβάνουμε 125 εκατομμύρια μετρήσεις ανά λεπτό ανά διακομιστή (αιχμές τη στιγμή της μετεγκατάστασης).
μετέφερε όλες τις μετρήσεις σε διάστημα αποθήκευσης τριάντα δευτερολέπτων.
λαμβανόμενη αναπαραγωγή δεδομένων και ανοχή σφαλμάτων·
άλλαξε χωρίς χρόνο διακοπής λειτουργίας.
Χρειάστηκαν περίπου 7 εβδομάδες για όλα.

Graphite+ClickHouse. Προβλήματα

Στην περίπτωσή μας υπήρχαν κάποιες παγίδες. Να τι συναντήσαμε μετά τη μετάβαση.

Το ClickHouse δεν ξαναδιαβάζει πάντα τις ρυθμίσεις παραμέτρων, μερικές φορές χρειάζεται να επαναφορτωθεί. Για παράδειγμα, στην περίπτωση της περιγραφής του συμπλέγματος zookeeper στη ρύθμιση παραμέτρων ClickHouse, δεν εφαρμόστηκε μέχρι να επανεκκινηθεί ο διακομιστής clickhouse.
Δεν υπήρχαν μεγάλα αιτήματα ClickHouse, επομένως στο graphite-clickhouse, η συμβολοσειρά σύνδεσης ClickHouse μοιάζει με αυτό:
```
url = "http://localhost:8123/?max_query_size=268435456&max_ast_elements=1000000"
```
Το ClickHouse κυκλοφορεί αρκετά συχνά νέες εκδόσεις σταθερών εκδόσεων, μπορεί να περιέχουν εκπλήξεις: να είστε προσεκτικοί.
Τα δυναμικά δημιουργημένα κοντέινερ στα kubernetes στέλνουν μεγάλο αριθμό μετρήσεων με σύντομη και τυχαία διάρκεια ζωής. Δεν υπάρχουν πολλά σημεία σύμφωνα με τέτοιες μετρήσεις και δεν υπάρχουν προβλήματα με το μέρος. Αλλά κατά τη δημιουργία ερωτημάτων, το ClickHouse συγκεντρώνει έναν τεράστιο αριθμό από αυτές τις ίδιες μετρήσεις από τον πίνακα «μετρήσεις». Στο 90% των περιπτώσεων, δεν υπάρχουν δεδομένα για αυτούς εκτός παραθύρου (24 ώρες). Αλλά ο χρόνος που δαπανάται για την αναζήτηση αυτών των δεδομένων στον πίνακα «δεδομένων» δαπανάται και τελικά εξαρτάται από ένα χρονικό όριο. Για να λύσουμε αυτό το πρόβλημα, αρχίσαμε να διατηρούμε μια ξεχωριστή προβολή με πληροφορίες για τις μετρήσεις που συναντήθηκαν κατά τη διάρκεια της ημέρας. Έτσι, κατά τη δημιουργία αναφορών (γραφημάτων) για κοντέινερ που δημιουργούνται δυναμικά, ρωτάμε μόνο εκείνες τις μετρήσεις που συναντήθηκαν στο καθορισμένο παράθυρο και όχι για όλη την ώρα, γεγονός που επιτάχυνε σημαντικά τη δημιουργία αναφορών για αυτά. Για το παραπάνω διάλυμα συλλέχθηκε γραφίτης-κλικ (πιρούνι), το οποίο περιλαμβάνει την υλοποίηση της εργασίας με τον πίνακα date_metrics.

Graphite+ClickHouse. ετικέτες

Από την έκδοση 1.1.0 Graphite έγινε επίσημη ετικέτες υποστήριξης. Και σκεφτόμαστε ενεργά τι και πώς να κάνουμε για να υποστηρίξουμε αυτήν την πρωτοβουλία στη στοίβα graphite+clickhouse.

Graphite+ClickHouse. Ανιχνευτής ανωμαλιών

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

Εγγραφείτε, πατήστε το επάνω βέλος και μείνετε χαρούμενοι!

Πηγή: www.habr.com

Αποθηκευτικός χώρος μετρήσεων: πώς μετακινηθήκαμε από το Graphite+Whisper στο Graphite+ClickHouse