🥇Συλλέγοντας κορμούς από τον Loki

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

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

Τι είναι ο Λόκι

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

Αρχική σελίδα, GitHub

Πριν προχωρήσω σε μια περιγραφή του τι μπορείτε να κάνετε με το Loki, θέλω να διευκρινίσω τι σημαίνει "η ιδέα της ευρετηρίασης μόνο μεταδεδομένων". Ας συγκρίνουμε την προσέγγιση Loki και την προσέγγιση ευρετηρίασης σε παραδοσιακές λύσεις, όπως το Elasticsearch, χρησιμοποιώντας το παράδειγμα μιας γραμμής από το αρχείο καταγραφής nginx:

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&amp;item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

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

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

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

Η στοίβα Loki αποτελείται από τρία στοιχεία: Promtail, Loki, Grafana. Το Promtail συλλέγει αρχεία καταγραφής, τα επεξεργάζεται και τα στέλνει στο Loki. Ο Λόκι τα κρατάει. Και η Grafana μπορεί να ζητήσει δεδομένα από τον Loki και να τα δείξει. Γενικά, το Loki μπορεί να χρησιμοποιηθεί όχι μόνο για την αποθήκευση αρχείων καταγραφής και την αναζήτηση μέσω αυτών. Ολόκληρη η στοίβα παρέχει εξαιρετικές ευκαιρίες για επεξεργασία και ανάλυση εισερχόμενων δεδομένων χρησιμοποιώντας τον τρόπο Prometheus.
Μπορείτε να βρείτε μια περιγραφή της διαδικασίας εγκατάστασης εδώ.

Αναζήτηση καταγραφής

Μπορείτε να αναζητήσετε τα αρχεία καταγραφής σε μια ειδική διεπαφή Grafana — Explorer. Τα ερωτήματα χρησιμοποιούν τη γλώσσα LogQL, η οποία μοιάζει πολύ με τη PromQL που χρησιμοποιεί ο Prometheus. Κατ 'αρχήν, μπορεί να θεωρηθεί ως ένα κατανεμημένο grep.

Η διεπαφή αναζήτησης μοιάζει με αυτό:

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

{image_name="nginx.promtail.test"} |= "index"

Λόγω του τρόπου λειτουργίας του Loki, δεν μπορείτε να υποβάλετε αιτήματα χωρίς επιλογέα, αλλά οι ετικέτες μπορούν να γίνουν αυθαίρετα γενικές.

Ο επιλογέας είναι το κλειδί-τιμή της τιμής στα σγουρά άγκιστρα. Μπορείτε να συνδυάσετε επιλογείς και να καθορίσετε διαφορετικές συνθήκες αναζήτησης χρησιμοποιώντας τους τελεστές =, != ή κανονικές εκφράσεις:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev

Ένα φίλτρο είναι ένα κείμενο ή regexp που θα φιλτράρει όλα τα δεδομένα που λαμβάνονται από τον επιλογέα.

Είναι δυνατή η λήψη γραφημάτων ad-hoc με βάση τα δεδομένα που λαμβάνονται στη λειτουργία μετρήσεων. Για παράδειγμα, μπορείτε να μάθετε τη συχνότητα εμφάνισης στα αρχεία καταγραφής nginx μιας καταχώρισης που περιέχει τη συμβολοσειρά ευρετηρίου:

Μια πλήρης περιγραφή των χαρακτηριστικών μπορεί να βρεθεί στην τεκμηρίωση LogQL.

Ανάλυση ημερολογίου

Υπάρχουν διάφοροι τρόποι συλλογής κορμών:

Με τη βοήθεια του Promtail, ενός τυπικού στοιχείου της στοίβας για τη συλλογή κορμών.
Απευθείας από το δοχείο βάσης χρησιμοποιώντας Πρόγραμμα οδήγησης Loki Docker Logging.
Χρησιμοποιήστε Fluentd ή Fluent Bit που μπορούν να στείλουν δεδομένα στον Loki. Σε αντίθεση με την Promtail, έχουν έτοιμους αναλυτές για σχεδόν κάθε τύπο αρχείου καταγραφής και μπορούν επίσης να χειριστούν πολυγραμμικά αρχεία καταγραφής.

Συνήθως το Promtail χρησιμοποιείται για ανάλυση. Κάνει τρία πράγματα:

Βρίσκει πηγές δεδομένων.
Κολλήστε ετικέτες σε αυτά.
Στέλνει δεδομένα στον Loki.

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

Υπάρχει ενοποίηση με το Kubernetes: Το Promtail ανακαλύπτει αυτόματα την κατάσταση του συμπλέγματος μέσω του Kubernetes REST API και συλλέγει αρχεία καταγραφής από έναν κόμβο, μια υπηρεσία ή μια ομάδα, δημοσιεύοντας αμέσως ετικέτες με βάση τα μεταδεδομένα από το Kubernetes (όνομα pod, όνομα αρχείου κ.λπ.).

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

Στάδια ανάλυσης. Αυτό είναι το στάδιο του RegEx και του JSON. Σε αυτό το στάδιο, εξάγουμε δεδομένα από τα αρχεία καταγραφής στον λεγόμενο εξαγόμενο χάρτη. Μπορείτε να εξαγάγετε από το JSON αντιγράφοντας απλώς τα πεδία που χρειαζόμαστε στον εξαγόμενο χάρτη ή μέσω κανονικών εκφράσεων (RegEx), όπου οι ομάδες με το όνομα "αντιστοιχίζονται" στον εξαγόμενο χάρτη. Ο χάρτης που εξάγεται είναι ένας χώρος αποθήκευσης κλειδιού-τιμής, όπου κλειδί είναι το όνομα του πεδίου και τιμή είναι η τιμή του από τα αρχεία καταγραφής.
Μεταμόρφωση σταδίων. Αυτό το στάδιο έχει δύο επιλογές: μετασχηματισμό, όπου ορίζουμε τους κανόνες μετασχηματισμού, και πηγή - την πηγή δεδομένων για τον μετασχηματισμό από τον εξαγόμενο χάρτη. Εάν δεν υπάρχει τέτοιο πεδίο στον εξαγόμενο χάρτη, τότε θα δημιουργηθεί. Έτσι, είναι δυνατή η δημιουργία ετικετών που δεν βασίζονται στον εξαγόμενο χάρτη. Σε αυτό το στάδιο, μπορούμε να χειριστούμε τα δεδομένα στον εξαγόμενο χάρτη χρησιμοποιώντας ένα αρκετά ισχυρό πρότυπο golang. Επιπλέον, πρέπει να θυμόμαστε ότι ο εξαγόμενος χάρτης φορτώνεται πλήρως κατά τη διάρκεια της ανάλυσης, γεγονός που καθιστά δυνατό, για παράδειγμα, τον έλεγχο της τιμής σε αυτόν: "{{if .tag}τιμή ετικέτας υπάρχει{end}}". Το πρότυπο υποστηρίζει συνθήκες, βρόχους και ορισμένες συναρτήσεις συμβολοσειράς, όπως Αντικατάσταση και Περικοπή.
Στάδια δράσης. Σε αυτό το στάδιο, μπορείτε να κάνετε κάτι με το εξαγόμενο:
- Δημιουργήστε μια ετικέτα από τα εξαγόμενα δεδομένα, η οποία θα ευρετηριαστεί από τον Loki.
- Αλλάξτε ή ορίστε την ώρα συμβάντος από το αρχείο καταγραφής.
- Αλλάξτε τα δεδομένα (κείμενο καταγραφής) που θα μεταβούν στο Loki.
- Δημιουργία μετρήσεων.
Στάδια φιλτραρίσματος. Το στάδιο αντιστοίχισης, όπου μπορούμε είτε να στείλουμε εγγραφές που δεν χρειάζεται να /dev/null, είτε να τις στείλουμε για περαιτέρω επεξεργασία.

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

Για τη δοκιμή, ας πάρουμε μια τροποποιημένη εικόνα nginx jwilder/nginx-proxy:alpine και έναν μικρό δαίμονα που μπορεί να ρωτήσει τον εαυτό του μέσω HTTP ως nginx-proxy. Ο δαίμονας έχει πολλά τελικά σημεία, στα οποία μπορεί να δώσει απαντήσεις διαφορετικών μεγεθών, με διαφορετικές καταστάσεις HTTP και με διαφορετικές καθυστερήσεις.

Θα συλλέξουμε αρχεία καταγραφής από κοντέινερ docker, τα οποία μπορούν να βρεθούν κατά μήκος της διαδρομής /var/lib/docker/containers/ / -json.log

Στο docker-compose.yml ρυθμίζουμε το Promtail και καθορίζουμε τη διαδρομή προς τη διαμόρφωση:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

Προσθέστε τη διαδρομή στα αρχεία καταγραφής στο promtail.yml (υπάρχει μια επιλογή "docker" στη διαμόρφωση που κάνει το ίδιο σε μία γραμμή, αλλά δεν θα ήταν τόσο προφανές):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

Όταν αυτή η διαμόρφωση είναι ενεργοποιημένη, ο Loki θα λάβει αρχεία καταγραφής από όλα τα κοντέινερ. Για να αποφευχθεί αυτό, αλλάζουμε τις ρυθμίσεις του δοκιμαστικού nginx στο docker-compose.yml - προσθέστε καταγραφή στο πεδίο ετικέτας:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

Επεξεργαστείτε το promtail.yml και ρυθμίστε το Pipeline. Τα αρχεία καταγραφής είναι τα εξής:

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

στάδια του αγωγού:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

Εξάγουμε τα πεδία ροής, attrs, attrs.tag (αν υπάρχουν) από το εισερχόμενο JSON και τα τοποθετούμε στον εξαγόμενο χάρτη.

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

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

 - labels:
     image_name:
     container_name:

Αποδίδουμε ετικέτες. Εάν τα κλειδιά image_name και container_name βρίσκονται στα εξαγόμενα δεδομένα, τότε οι τιμές τους θα αντιστοιχιστούν στις κατάλληλες ετικέτες.

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

Απορρίπτουμε όλα τα αρχεία καταγραφής που δεν έχουν σύνολο ετικετών image_name και container_name.

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

Για όλα τα αρχεία καταγραφής των οποίων το image_name είναι ίσο με το nginx.promtail.test, εξάγουμε το πεδίο καταγραφής από το αρχείο καταγραφής προέλευσης και το βάζουμε στον εξαγόμενο χάρτη με το πλήκτρο γραμμής.

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

Καθαρίζουμε τη συμβολοσειρά εισόδου με κανονικές εκφράσεις και βγάζουμε τον εικονικό κεντρικό υπολογιστή nginx και τη γραμμή καταγραφής nginx.

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

Αναλύστε το αρχείο καταγραφής nginx με κανονικές εκφράσεις.

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

Ανάλυση request_url. Με τη βοήθεια του regexp, προσδιορίζουμε τον σκοπό του αιτήματος: στα στατικά, στις φωτογραφίες, στο API και ορίζουμε το αντίστοιχο κλειδί στον εξαγόμενο χάρτη.

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

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

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Ορίσαμε τις ετικέτες api_request, virtual_host, request_type και status (HTTP status) με βάση αυτά που καταφέραμε να βάλουμε στον εξαγόμενο χάρτη.

       - output:
           source: nginx_log_row

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

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

Λάβετε υπόψη ότι η εξαγωγή ετικετών με μεγάλο αριθμό τιμών (cardinality) μπορεί να επιβραδύνει σημαντικά το Loki. Δηλαδή, δεν πρέπει να βάλετε στο ευρετήριο, για παράδειγμα, user_id. Διαβάστε περισσότερα για αυτό στο άρθροΠώς οι ετικέτες στο Loki μπορούν να κάνουν τα ερωτήματα καταγραφής πιο γρήγορα και ευκολότερα". Αλλά αυτό δεν σημαίνει ότι δεν μπορείτε να κάνετε αναζήτηση με user_id χωρίς ευρετήρια. Είναι απαραίτητο να χρησιμοποιείτε φίλτρα κατά την αναζήτηση ("αρπάξτε" σύμφωνα με τα δεδομένα) και το ευρετήριο εδώ λειτουργεί ως αναγνωριστικό ροής.

Οπτικοποίηση ημερολογίου

Το Loki μπορεί να λειτουργήσει ως πηγή δεδομένων για γραφήματα Grafana χρησιμοποιώντας το LogQL. Υποστηρίζονται οι ακόλουθες δυνατότητες:

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

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

Η προεπιλεγμένη πηγή δεδομένων του Loki είναι λίγο λιγότερο λειτουργική από την πηγή δεδομένων Prometheus (για παράδειγμα, δεν μπορείτε να αλλάξετε το υπόμνημα), αλλά το Loki μπορεί να συνδεθεί ως πηγή τύπου Prometheus. Δεν είμαι σίγουρος αν αυτή είναι τεκμηριωμένη συμπεριφορά, αλλά αν κρίνω από την απάντηση από τους προγραμματιστές "Πώς να ρυθμίσετε το Loki ως πηγή δεδομένων Prometheus; · Τεύχος #1222 · grafana/loki”, για παράδειγμα, είναι απολύτως νόμιμο και το Loki είναι πλήρως συμβατό με το PromQL.

Προσθέστε το Loki ως πηγή δεδομένων με τον τύπο Prometheus και προσαρτήστε το URL /loki:

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

Νομίζω ότι η ασυμφωνία στη λειτουργικότητα είναι προσωρινή και οι προγραμματιστές θα τη διορθώσουν στο μέλλον.

Μετρήσεις

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

Προσθήκη άλλης ενότητας στο promtail.yml:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

Η επιλογή σάς επιτρέπει να ορίζετε και να ενημερώνετε μετρήσεις βάσει δεδομένων από τον εξαγόμενο χάρτη. Αυτές οι μετρήσεις δεν αποστέλλονται στο Loki - εμφανίζονται στο τελικό σημείο Promtail /metrics. Ο Προμηθέας πρέπει να ρυθμιστεί ώστε να λαμβάνει δεδομένα από αυτό το στάδιο. Στο παραπάνω παράδειγμα, για request_type="api" συλλέγουμε μια μέτρηση ιστογράμματος. Με αυτόν τον τύπο μετρήσεων είναι βολικό να λαμβάνετε εκατοστημόρια. Για στατικά και φωτογραφίες, συλλέγουμε το άθροισμα των byte και τον αριθμό των σειρών στις οποίες λάβαμε byte για να υπολογίσουμε τον μέσο όρο.

Διαβάστε περισσότερα για τις μετρήσεις εδώ.

Ανοίξτε μια θύρα στο Promtail:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

Βεβαιωνόμαστε ότι έχουν εμφανιστεί οι μετρήσεις με το πρόθεμα promtail_custom:

Στήνοντας τον Προμηθέα. Προσθήκη promtail εργασίας:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

Και σχεδιάστε ένα γράφημα:

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

Κλιμάκωση

Το Loki μπορεί να είναι τόσο σε μονή δυαδική λειτουργία όσο και σε κοινόχρηστο (οριζόντια-κλιμακούμενη λειτουργία). Στη δεύτερη περίπτωση, μπορεί να αποθηκεύσει δεδομένα στο cloud και τα κομμάτια και το ευρετήριο αποθηκεύονται χωριστά. Στην έκδοση 1.5, εφαρμόζεται η δυνατότητα αποθήκευσης σε ένα μέρος, αλλά δεν συνιστάται ακόμη η χρήση της στην παραγωγή.

Τα κομμάτια μπορούν να αποθηκευτούν σε χώρο αποθήκευσης συμβατό με S3, για αποθήκευση ευρετηρίων, χρησιμοποιήστε βάσεις δεδομένων με οριζόντια κλιμάκωση: Cassandra, BigTable ή DynamoDB. Άλλα μέρη του Loki - Διανομείς (για γράψιμο) και Querier (για ερωτήματα) - είναι ανιθαγενείς και επίσης κλιμακώνονται οριζόντια.

Στο συνέδριο DevOpsDays Vancouver 2019, ένας από τους συμμετέχοντες ο Callum Styan ανακοίνωσε ότι με τον Loki το έργο του έχει petabytes κούτσουρων με δείκτη μικρότερο από το 1% του συνολικού μεγέθους:Πώς ο Loki συσχετίζει μετρήσεις και αρχεία καταγραφής — και σας εξοικονομεί χρήματα".

Σύγκριση Λόκι και ΕΛΚ

Μέγεθος ευρετηρίου

Για να δοκιμάσω το προκύπτον μέγεθος ευρετηρίου, πήρα αρχεία καταγραφής από το κοντέινερ nginx για το οποίο είχε διαμορφωθεί ο παραπάνω αγωγός. Το αρχείο καταγραφής περιείχε 406 γραμμές με συνολικό όγκο 624 MB. Τα αρχεία καταγραφής δημιουργήθηκαν μέσα σε μία ώρα, περίπου 109 εγγραφές ανά δευτερόλεπτο.

Ένα παράδειγμα δύο γραμμών από το αρχείο καταγραφής:

Όταν ευρετηριάστηκε από το ELK, αυτό έδωσε μέγεθος ευρετηρίου 30,3 MB:

Στην περίπτωση του Loki, αυτό έδωσε περίπου 128 KB ευρετηρίου και περίπου 3,8 MB δεδομένων σε κομμάτια. Αξίζει να σημειωθεί ότι το αρχείο καταγραφής δημιουργήθηκε τεχνητά και δεν διέθετε μεγάλη ποικιλία δεδομένων. Ένα απλό gzip στο αρχικό αρχείο καταγραφής Docker JSON με δεδομένα έδωσε συμπίεση 95,4% και δεδομένου ότι μόνο το καθαρισμένο αρχείο καταγραφής nginx στάλθηκε στον ίδιο τον Loki, η συμπίεση στα 4 MB είναι κατανοητή. Ο συνολικός αριθμός μοναδικών τιμών για τις ετικέτες Loki ήταν 35, γεγονός που εξηγεί το μικρό μέγεθος του ευρετηρίου. Για τα ΕΛΚ εκκαθαρίστηκε και το ημερολόγιο. Έτσι, ο Loki συμπίεσε τα αρχικά δεδομένα κατά 96%, και το ELK κατά 70%.

Κατανάλωση μνήμης

Αν συγκρίνουμε ολόκληρο το stack του Prometheus και του ELK, τότε ο Loki «τρώει» αρκετές φορές λιγότερο. Είναι σαφές ότι η υπηρεσία Go καταναλώνει λιγότερο από την υπηρεσία Java και η σύγκριση του μεγέθους του Heap Elasticsearch JVM και της εκχωρημένης μνήμης για το Loki είναι εσφαλμένη, αλλά, ωστόσο, αξίζει να σημειωθεί ότι η Loki χρησιμοποιεί πολύ λιγότερη μνήμη. Το πλεονέκτημα της CPU δεν είναι τόσο προφανές, αλλά είναι επίσης παρόν.

ταχύτητα

Ο Λόκι «καταβροχθίζει» τα κούτσουρα πιο γρήγορα. Η ταχύτητα εξαρτάται από πολλούς παράγοντες - τι είδους αρχεία καταγραφής, πόσο εξελιγμένα τα αναλύουμε, δίκτυο, δίσκος κ.λπ. - αλλά είναι σίγουρα υψηλότερη από αυτή του ELK (στη δοκιμή μου - περίπου δύο φορές). Αυτό εξηγείται από το γεγονός ότι ο Loki τοποθετεί πολύ λιγότερα δεδομένα στο ευρετήριο και, κατά συνέπεια, ξοδεύει λιγότερο χρόνο στην ευρετηρίαση. Σε αυτήν την περίπτωση, η κατάσταση αντιστρέφεται με την ταχύτητα αναζήτησης: Ο Loki επιβραδύνει αισθητά σε δεδομένα μεγαλύτερα από μερικά gigabyte, ενώ για το ELK, η ταχύτητα αναζήτησης δεν εξαρτάται από το μέγεθος των δεδομένων.

Αναζήτηση καταγραφής

Ο Loki είναι σημαντικά κατώτερος του ELK όσον αφορά τις δυνατότητες αναζήτησης αρχείων καταγραφής. Το Grep με κανονικές εκφράσεις είναι ένα δυνατό πράγμα, αλλά είναι κατώτερο από μια βάση δεδομένων για ενήλικες. Η έλλειψη ερωτημάτων εύρους, η συγκέντρωση μόνο κατά ετικέτες, η αδυναμία αναζήτησης χωρίς ετικέτες - όλα αυτά μας περιορίζουν στην αναζήτηση πληροφοριών που μας ενδιαφέρουν στο Loki. Αυτό δεν σημαίνει ότι δεν μπορεί να βρεθεί τίποτα χρησιμοποιώντας το Loki, αλλά καθορίζει τη ροή εργασίας με αρχεία καταγραφής, όταν πρώτα βρίσκετε ένα πρόβλημα στα γραφήματα του Prometheus και μετά αναζητάτε τι συνέβη στα αρχεία καταγραφής χρησιμοποιώντας αυτές τις ετικέτες.

διεπαφή

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

Λόκι υπέρ και κατά

Από τα πλεονεκτήματα, μπορεί να σημειωθεί ότι ο Loki ενσωματώνεται με τον Prometheus, αντίστοιχα, λαμβάνουμε μετρήσεις και ειδοποιήσεις από το κουτί. Είναι βολικό για τη συλλογή κορμών και την αποθήκευση τους με το Kubernetes Pods, καθώς έχει μια ανακάλυψη υπηρεσίας που κληρονομήθηκε από τον Prometheus και επικολλά αυτόματα ετικέτες.

Από τα μειονεκτήματα - κακή τεκμηρίωση. Κάποια πράγματα, όπως τα χαρακτηριστικά και οι δυνατότητες του Promtail, ανακάλυψα μόνο στη διαδικασία μελέτης του κώδικα, το όφελος του ανοιχτού κώδικα. Ένα άλλο μειονέκτημα είναι οι αδύναμες δυνατότητες ανάλυσης. Για παράδειγμα, ο Loki δεν μπορεί να αναλύσει τα αρχεία καταγραφής πολλών γραμμών. Επίσης, τα μειονεκτήματα περιλαμβάνουν το γεγονός ότι το Loki είναι μια σχετικά νέα τεχνολογία (η κυκλοφορία 1.0 ήταν τον Νοέμβριο του 2019).

Συμπέρασμα

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

Δεν χρησιμοποιούμε το Loki στο Badoo, επειδή έχουμε μια στοίβα ELK που μας ταιριάζει και που έχει κατακλυστεί με διάφορες προσαρμοσμένες λύσεις όλα αυτά τα χρόνια. Για εμάς, το εμπόδιο είναι η αναζήτηση στα αρχεία καταγραφής. Με σχεδόν 100 GB αρχείων καταγραφής την ημέρα, είναι σημαντικό για εμάς να μπορούμε να βρίσκουμε τα πάντα και λίγο περισσότερο και να το κάνουμε γρήγορα. Για χαρτογράφηση και παρακολούθηση, χρησιμοποιούμε άλλες λύσεις που είναι προσαρμοσμένες στις ανάγκες μας και ενσωματωμένες μεταξύ τους. Η στοίβα Loki έχει απτά οφέλη, αλλά δεν θα μας δώσει περισσότερα από αυτά που έχουμε και τα οφέλη της δεν θα υπερβαίνουν ακριβώς το κόστος της μετεγκατάστασης.

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

Βρίσκεται το αποθετήριο με τον κωδικό που χρησιμοποιείται στο άρθρο εδώ.

Πηγή: www.habr.com

Συλλογή κορμών από τον Loki