🥇Kogume Loki kaudu logisid

Me Badoo's jälgime pidevalt uusi tehnoloogiaid ja hindame, kas nende kasutamine meie süsteemis on põhjendatud. Ühe sellise uuringuga soovime jagada kogukonnaga. See on pühendatud Lokile — logide kogumise süsteemile.

Loki on lahendus logide salvestamiseks ja vaatamiseks, samuti pakub see paindlikku süsteemi logide analüüsimiseks ja andmete saatmiseks Prometheusesse. Mais ilmus järgmine värskendus, mida arendajad aktiivselt edendavad. Meid huvitas, mida Loki suudab, milliseid võimalusi see pakub ja kui hästi võib see asendada ELK-i — tehnoloogiat, mida kasutame praegu.

Mis on Loki

Grafana Loki on komponentide kogum, mis moodustab täieliku süsteemi logidega töötamiseks. Erinevalt teistest sarnastest süsteemidest põhinevad Lokis ideel indekseerida ainult logide metainformatsiooni — labels (nagu Prometheus), samas kui logid ise surutakse kokku eraldi chunk'idena.

Avaleht, GitHub

Enne kui räägin Loki funktsioonidest, soovin selgitada, mida tähendab 'ainult metaandmete indekseerimise idee'. Vaatleme Loki lähenemist ja traditsioonilisi meetodeid nagu Elasticsearch, kasutades näitena nginx logirida:

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

Traditsioonilised süsteemid parsivad rida tervikuna, sealhulgas väljad, kus on palju unikaalseid väärtusi user_id ja item_id, ja salvestavad kõik suurtesse indeksitesse. Selle lähenemise eeliseks on see, et keerulisi päringuid saab kiiresti teostada, kuna peaaegu kõik andmed on indeksis. Kuid selle eest tuleb maksta: indeks muutub suureks, mis suurendab mälu nõudmisi. Lõppkokkuvõttes on logide täisteksti indeks võrreldav logide enda suurusega. Selleks, et kiiresti otsida, peab indeks olema mälus. Ja mida rohkem logisid on, seda kiiremini indeks suureneb ja seda rohkem mälu see vajab.

Loki lahendus nõuab, et rea põhjal eraldataks ainult vajalikud andmed, mille väärtuste arv on väike. Nii saame väikese indeksi ja saame andmeid otsida, filtreerides neid aja ja indekseeritud väljade järgi ning skaneerides seejärel jääkidest regulaaravaldiste või alamstringide kaudu. Protsess ei tundu kõige kiirem, kuid Loki jagab päringu mitmeks osaks ja täidab need paralleelselt, töötledes suurt hulka andmeid lühikese aja jooksul. Shardide ja nende paralleelsete päringute arv on konfigureeritav; seega sõltub ajaühikus töödeldavate andmete hulk lineaarelt pakutud ressurssidest.

See kompromiss suure kiire indeksi ja väikese indeksi vahel paralleelse täisotsimisega võimaldab Lokil hallata süsteemi kulusid. Seda saab paindlikult kohandada ja laiendada vastavalt vajadustele.

Loki-stek koosneb kolmest komponendist: Promtail, Loki ja Grafana. Promtail kogub logisid, töötleb neid ja saadab Loki-sse. Loki salvestab need. Grafana oskab küsida andmeid Loki-st ja neid kuvada. Üldiselt saab Loki’t kasutada mitte ainult logide salvestamiseks ja nende järgi otsimiseks. Kogu stek pakub suuri võimalusi saabuva info töötlemiseks ja analüüsimiseks, kasutades Prometheuse lähenemist.
Installeerimise protsessi kirjeldus on saadaval siit.

Otsi logisid

Logides saab otsida spetsiaalses Grafana kasutajaliideses — Explorer. Küsitavate andmete jaoks kasutatakse LogQL keelt, mis on väga sarnane PromQL-ile, mida kasutatakse Prometheuses. Põhimõtteliselt võib seda vaadelda kui jaotatud grep'i.

Otsingu liides näeb välja selline:

Iga päring koosneb kahest osast: selector ja filter. Selector on otsimine indekseeritud metandmete (siltide) põhjal, mis on logidele omistatud, ja filter on otsingurea või regulaarne väljend, millega filtreeritakse sissekanded, mida määratleb selector. Antud näites: Koorikute sises olev — selector, kõik, mis järgneb, on filter.

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

Loki tööpõhimõtte tõttu ei saa päringuid teha ilma selectorita, kuid silte saab teha nii üldiseks, kui soovite.

Selektor on key-value väärtused sulgudes. Saate kombinatsioonide abil luua selektoreid ja määrata erinevaid otsingu tingimusi, kasutades operaattoreid =, != või regulaaravaldisi:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Leiab logid, millel on instance'i silt, mille väärtuseks on kafka-2, kafka-3, ja välistab dev

Filter on tekst või regulaaravaldis, mis filtreerib kõik andmed, mis saadakse selektorist.

On võimalik saada ad-hoc- graafikuid saadud andmete kohta režiimis metrics. Näiteks saab teada, kui sageli esineb nginx logides rida, mis sisaldab fraasi index:

Kogu võimaluste kirjeldus on saadaval dokumendis. LogQL.

Logide parsimine

Logide kogumiseks on mitu viisi:

Kasutades Promtail'i, mis on standardne komponent logide kogumisel.
Otseselt Docker-konteinerist, kasutades Loki Docker Logging Driver.
Kasutada Fluentd või Fluent Bit, mis oskavad saata andmeid Loki. Erinevalt Promtail'ist on neil valmispakitud parsijad praktiliselt igasuguste logide jaoks ja nad suudavad hakkama saada ka multiline-logidega.

Tavaliselt kasutatakse parsimiseks Promtail'i. See teeb kolme asja:

Leiab andmeallikad.
Kinnitavad neile silte.
Saadab andmed Loki.

Hetkel suudab Promtail lugeda logisid kohalikest failidest ja systemd journalist. See tuleb paigaldada igale masinale, millest logisid kogutakse.

Kubernetesega on olemas integreerimine: Promtail tuvastab automaatselt Kubernetes REST API kaudu klastriseisundi ja kogub logisid sõlmelt, teenusest või podist, riputades samal ajal sildid põhinedes Kubernetesest saadud metaandmetele (pod'i nimi, faili nimi jne).

Samuti saab silte riputada logiandmete põhjal Pipeline'i abil. Promtaili Pipeline võib koosneda neljast tüüpi etappidest. Rohkem detaile — ametlikus dokumentatsioonis, mainin siin mõned nüansid.

Parsing stages. See on RegEx ja JSON etapp. Sellel etapil ekstraheerime andmed logidest nii nimetatud extracted map'i. Andmeid saab ekstraktida JSON-ist, kopeerides lihtsalt vajalikud väljad extracted map'i, või regulaarselt väljendite (RegEx) kaudu, kus extracted map'is “mapitakse” named groups. Extracted map on key-value salvestus, kus key on välja nimi ja value on selle väärtus logidest.
Transform stages. Sellel etapil on kaks valikut: transform, kus määrame transformatsiooni reeglid, ja source — andmeallikas transformatsiooniks extracted map'ist. Kui extracted map'is sellist välja ei ole, siis see luuakse. Nii saab luua silte, mis ei põhine extracted map'il. Sellel etapil saame manipuleerida andmetega extracted map'is, kasutades piisavalt võimsat Golang Template. Samuti tuleks meeles pidada, et extracted map laaditakse täielikult parsimisel, mis võimaldab näiteks kontrollida väärtust: “{{if .tag}tag value exists{end}}”. Mall toetab tingimusi, tsükleid ja mõningaid stringi funktsioone, nagu Replace ja Trim.
Action stages. Sellel etapil saab teha midagi väljatrükkidega:
- Luua silt extracted data'st, mis indekseeritakse Loki.
- Muutke või seadke logi sündmuse aeg.
- Muutke andmeid (logi tekst), mis saadetakse Loki.
- Looge mõõdikud.
Filtering stages. Match etapp, kus saab kas suunata /dev/null-sse salvestusi, mida me ei vaja, või suunata need edasisele töötlemisele.

Näitan näite kaudu tavaliste nginx-logide töötlemise kohta, kuidas logisid Promtaili abil parssida.

Testimiseks kasutame nginx-proxy't, modifitseeritud dockeripilti nginx jwilder/nginx-proxy:alpine ja väikest demonit, mis oskab endalt HTTP kaudu küsida. Demonil on seadistatud mitu lõpp-punkti, millele ta võib vastata erineva suuruse, erinevate HTTP staatuste ja erineva viivitusega.

Kogume logisid docker-konteineritest, mida saab leida teelt /var/lib/docker/containers//-json.log

docker-compose.yml failis seadistame Promtaili ja määrame tee konfigureerimise juurde:

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'
 // ...

Lisame promtail.yml'sse tee logideni (konfiguratsioonis on olemas valik "docker", mis teeb sama ühe reaga, kuid see ei oleks nii selge):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # ainult linuxile

Käivitades sellise konfiguratsiooni, satuvad Loki'sse logid kõigist konteineritest. Selle vältimiseks muudame testimise nginx seadeid docker-compose.yml — lisame logimise sildi väljad:

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

Muudame promtail.yml ja seadistame Pipeline'i. Sisendiks on järgmise vorminguga logid:

{"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"}

Pipeline'i etapp:

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

Ekstraheerime tulenevatest JSON-väljadest stream, attrs, attrs.tag (kui need olemas) ja paneme need extracted map'i.

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

Kui saime tag'i välja panna extracted map'i, siis kasutame regex'i pildi ja konteineri nimede ekstraheerimiseks.

 - labels:
     image_name:
     container_name:

Määrame sildid. Kui extracted data's leitakse võtmed image_name ja container_name, siis nende väärtused omistatakse vastavatele siltidele.

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

Korraga viskame kõik logid välja, millel ei leidu määratud silte image_name ja container_name.

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

Kõigi logide puhul, kus image_name on nginx.promtail.test, ekstraktime algsest logist välja välja log ja paneme selle extracted kaardile võtmega row.

  - regex:
         # välistame forego värvid
         expression: .+nginx.+|.+[0m(?P[a-z_.-]+) +(?P.+)
         source: logrow

Puhastame sisendi rea regulaaravaldistega ja ekstraheerime nginx virtuaalse hosti ja nginx logi rea.

     - regex:
         source: nginxlog
         expression: ^(?P[w.]+) - (?P[^ ]*) [(?P[^ ]+).*] "(?P[^ ]*) (?P[^ ]*) (?P[^ ]*)" (?P[d]+) (?P[d]+) "(?P[^"]*)" "(?P[^"]*)"( "(?P[d.]+)")?

Parsim nginx-logi regulaaravaldistega.

    - regex:
           source: request_url
           expression: ^.+\.(?Pjpg|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[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P[^/?.]+).*$

Uurime request_url-i. Regulaaravaldiste abil määrame päringu sihtkoha: staatilisele, fotodele, API-le ja salvestame extracted kaardile vastava võtme.

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

Template'i tingimuste operaatorite abil kontrollime extracted map'is seadistatud välju ja määrame request_type väljale vajalikud väärtused: photo, static, API. Määrame other, kui see ei õnnestu. Nüüd sisaldab request_type päringu tüüpi.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Seame api_request, virtual_host, request_type ja staatuse (HTTP staatuse) väärtused vastavalt sellele, mis on õnnestunud extracted map'i sisestada.

       - output:
           source: nginx_log_row

Muudame output'i. Nüüd saadetakse Loki'sse puhastatud nginx-log extracted map'ist.

Pärast antud konfiguratsiooni käivitamist võib näha, et igale kirjele on lisatud märgid logi andmete põhjal.

Peab meeles pidama, et erinevate väärtustega (cardinality) märkide ekstraheerimine võib oluliselt aeglustada Loki toimimist. See tähendab, et näiteks user_id ei tohiks indeksisse panna. Täiendavalt lugege sellest artiklist “How labels in Loki can make log queries faster and easier”. Kuid see ei tähenda, et user_id põhjal ei saaks otsida ilma indeksiteta. Otsingul tuleks kasutada filtreid (andmete „grepimise” kaudu), kusjuures indeks toimib identifikaatorina.

Logide visualiseerimine

Loki saab olla andmeallikaks Grafana diagrammidele, kasutades LogQL-i. Toetatud on järgmised funktsioonid:

rate — sündmuste arv sekundis;
count over time — sündmuste arv määratud ajavahemikus.

Samuti on olemas agregatsioonifunktsioonid nagu Sum, Avg ja teised. Saame koostada piisavalt keerulisi diagramme, näiteks HTTP-veeremiste arvu diagrammi:

Tavapärane andmeallikas Loki on funktsionaalsuses mõnevõrra piiratud võrreldes andmeallikaga Prometheus (näiteks ei saa muudada legendi), kuid Loki saab lisada allikana tüübi Prometheus. Ma ei ole kindel, kas see on dokumenteeritud käitumine, aga arendajate vastuse põhjal “How to configure Loki as Prometheus datasource? · Issue #1222 · grafana/loki”, näib, et see on täiesti seaduslik ning Loki on täielikult ühilduv PromQL-iga.

Lisame Loki andmeallikana tüübi Prometheus ja täiendame URL-i /loki:

Ja saame koostada diagramme nagu siis, kui töötaksime Prometheus-i mõõdikute kallal:

Ma arvan, et funktsionaalsuse erinevus on ajutine ja arendajad parandavad selle tulevikus.

Mõõdikud

Loki pakub võimalust ekstraktida numbrilisi mõõdikud logidest ja saata need Prometheusele. Näiteks nginx logis sisaldub vastuse baitide arv ning teatud modifikatsiooniga standardformaadi logis ka aeg sekundites, mis kulus vastamiseks. Need andmed saab ekstraktida ja saata Prometheusele.

Lisame promtail.yml faili veel ühe sektsiooni:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "vastuse aeg 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: "vastuse baitide summa"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "vastuse baitide arv"
           source: bytes_out
           config:
             action: inc

Valik võimaldab defineerida ja uuendada meetrikat, tuginedes extracted map andmetele. Need meetrikad ei saadeta Lokisse — need ilmuvad Promtaili /metrics lõpp-punkti. Prometheus peab olema konfigureeritud nii, et saada andmeid, mis on saadud sellel etapil. Antud näites, kui request_type= "api", kogume me histogrammi meetrikat. Sellise meetrikaga on mugav saada protsente. Staatika ja piltide jaoks kogume me byte'ide summa ja ridade arvu, kus me byte'e saime, et arvutada keskmine väärtus.

Rohkem teavet meetrikate kohta loe siit.

Avame pordi Promtailile:

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

Veendume, et prefiksiga promtail_custom meetrikad on ilmunud:

Konfigureerime Prometheuse. Lisame promtaili töö:

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

Ja joonistame diagrammi:

Nii saab näiteks teada neli aeglastest päringut. Samuti saab nendele meetrikatele seadistada monitorimise.

Mastaapimine

Loki võib töötada nii üksi (üksiku binaarsena) kui ka jagatuna (horisontaalselt skaleeritavana). Teises variandis võib ta salvestada andmeid pilve, kusjuures plokid ja indeksid hoitakse eraldi. Versioonis 1.5 on võimalik salvestada ühte kohta, kuid seda ei soovitata veel tootmises kasutada.

Plokke saab salvestada S3 ühilduvatesse ladudesse, indeksite salvestamiseks on soovitatav kasutada horisontaalselt skaleeritavaid andmebaase nagu Cassandra, BigTable või DynamoDB. Loki teised osad — Distributors (kirjutamiseks) ja Querier (päringute jaoks) — on olekuta ja samuti skaleeritavad horisontaalselt.

Konverentsil DevOpsDays Vancouver 2019 tõi üks osaleja Callum Styan välja, et tema projekt on Loki abil kogunud petabaitide kaupa logisid, mille indeks on vähem kui 1% kogu suurusest: “Kuidas Loki seob mõõdikud ja logid — ning säästab raha”.

Loki ja ELK võrdlus

Indeksi suurus

Indeksi saadud suuruse testimiseks võtsin logid Nginx konteinerist, mille jaoks seadistati ülaltoodud Pipeline. Logifail sisaldas 406 624 rida, kokku 109 MB. Logisid genereeriti tunni jooksul, umbes 100 kirjet sekundis.

Näide kahest reast logist:

ELK indekseerimise korral andis see indeksi suuruseks 30,3 MB:

Loki puhul oli see umbes 128 KB indeksit ja ligikaudu 3,8 MB andmeid plokkides. Tuleb märkida, et logi oli kunstlikult genereeritud ning see ei erinenud suurest andmete mitmekesisusest. Lihtne gzip algse dockeri JSON-logi andmete peal andis 95,4% surumise, ja arvestades, et Loki sai ainult puhastatud nginx-logi, on 4 MB surumine mõistetav. Loki märgiste koguarv oli 35, mis selgitab väikest indeksi suurust. ELK logi oli samuti puhas. Seega surus Loki algandmed kokku 96% ja ELK 70%.

Mälu tarbimine

Kui võrrelda kogu Prometheuse ja ELK steki, siis Loki „tarbib“ mitu korda vähem. On selge, et Go teenus tarbib vähem kui Java teenus, ja Elasticsearchi JVM Heap'i ja Loki eraldatud mälu suuruse võrdlemine pole korrektne, kuid siiski on märkimisväärne, et Loki kasutab palju vähem mälu. Tema CPU eelis ei ole nii ilmselge, kuid see on samuti olemas.

Kiirus

Loki suudab logisid töötlemisel olla kiirem. Kiirus sõltub paljusid teguritest — näiteks logide tüübist, meie töötlemise keerukusest, loogikast, diskist jne — aga see on kindlasti kõrgem kui ELK-il (minu testides umbes kaks korda kiirem). Seda seletab asjaolu, et Loki salvestab indeksi vähem andmeid ja seega kulutab indekseerimisele vähem aega. Otsimise kiirus on seevastu vastupidine: Loki aeglustub märgatavalt, kui andmed ületavad mitut gigabaiti, samas kui ELK-i otsimise kiirus ei sõltu andmete suurusest.

Otsi logisid

Loki on otsinguvõimete osas ELK-le olulisel määral alla jäänud. Grep regulaarsete väljenditega on tõhus, kuid jääb alla täiskasvanud andmebaasile. Range-päringute puudumine, aggregeerimine ainult siltide järgi ja võimaluse puudumine otsida ilma siltideta — kõik need piiravad meid olulise teabe leidmisel Loki kaudu. See ei tähenda, et Loki abil ei saa midagi leida, kuid see määratleb meie töövoo logidega, kus esmalt leiate probleemi Prometheuse graafikutelt ja seejärel otsite nende siltide põhjal logidest, mis juhtus.

Liides

Esiteks, see on ilus (vabandust, ma ei suutnud ennast tagasi hoida). Grafanal on silmale meeldiv liides, kuid Kibana on palju funktsionaalne.

Loki plussid ja miinused

Plusside seas võib märkida, et Loki integreerub Prometheusega, seetõttu saame mõõtmised ja häired valmis kujul. See on mugav logide kogumiseks ja salvestamiseks Kubernetes Podide juures, kuna tal on pärandina Prometheusest teenuse avastamine ja ta lisab automaatselt silte.

Miinusteks on nõrk dokumentatsioon. Mõningaid asju, näiteks Promtaili omadusi ja võimalusi, avastasin alles koodi uurimise käigus, õnneks on see avatud koodiga. Veel üks miinus on nõrgad tõlgendamisvõimalused. Näiteks ei oska Loki tõlgendada mitmerealisi logisid. Samuti võib puudustena märkida, et Loki on suhteliselt noor tehnoloogia (1.0 versioon ilmus novembris 2019).

Kokkuvõte

Loki on 100% huvitav tehnoloogia, mis sobib väikestele ja keskmise suurusega projektidele, võimaldades lahendada mitmeid logide kogumise, logide otsimise, logide jälgimise ja analüüsi ülesandeid.

Me ei kasuta Loki't Badoo's, kuna meil on ELK-stack, mis vastab meie vajadustele ja on aastate jooksul saanud erinevate kohandatud lahenduste kogumiks. Meie jaoks on logide otsimine tõeline väljakutse. Peaaegu 100 GB loge päevas tähendab, et on oluline leida kõike ja veidi rohkem ning seda kiiresti. Graafikute koostamiseks ja jälgimiseks kasutame muid lahendusi, mis on kohandatud meie vajadustele ja omavahel integreeritud. Loki stack'il on omad plussid, kuid see ei paku meile rohkem, kui me juba omame, ning selle eelised ei kata ülemineku kulusid.

Ja kuigi uurimise käigus selgus, et me ei saa Loki't kasutada, loodame, et see postitus aitab teil valikut teha.

Artiklis kasutatud koodi hoidla asub siin.

Allikas: habr.com