Kogume logisid Loki'ga

Meie Badoo-s jälgime pidevalt uusimaid tehnoloogiaid ja hindame, kas neid tuleks meie süsteemis kasutada. Ühe sellise uuringuga soovime jagada kogukonnaga. See on pühendatud Loki-le — logide koondamise süsteemile.

Loki on lahendus logide salvestamiseks ja vaatamiseks, samuti pakub see paindlikku süsteemi nende analüüsimiseks ja andmete eksportimiseks Prometheusesse. Mais ilmus uus värskendus, mida loojad aktiivselt propageerivad. Meid huvitas, mida Loki suudab, milliseks võimalustega see pakub ja kuivõrd see võib olla alternatiiv ELK-ile — sellele tehnoloogiapakile, mida me praegu kasutame.

Mis on Loki?

Grafana Loki on komponentide kogum täisväärtuslikuks logidega töötamise süsteemiks. Erinevalt teistest sarnastest süsteemidest põhineb Loki ideel indekseerida ainult logide metaandmed — labels (nagu Prometheuses), samas kui logid ise pigistatakse alates eraldi chunkidesse.

Avaleht, GitHub

Enne kui liigume edasi soovitud tegevuste kirjeldamise juurde Loki abil, tahaksin selgitada, mida mõistetakse allpool „ideena indekseerida ainult metaandmeid“. Võrdleme Loki lähenemist traditsiooniliste lahenduste, nagu Elasticsearch, indekseerimise lähenemisega, kasutades näitena nginx logi rida:

172.19.0.4 - - [01/Juun/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 suured indeksitesse. Selle lähenemise eeliseks on see, et keerulisi päringuid saab kiiresti teha, kuna peaaegu kõik andmed on indeksis. Kuid selle eest tuleb maksta sellega, et indeks kasvab suureks, mis toob kaasa mälu nõudmised. Lõpuks on logide täisteksti indeks võrreldav logide endaga. Kiireks otsimiseks peab indeks olema laaditud mällu. Ja mida rohkem logisid, seda kiiremini indeks suureneb ja seda rohkem mälu see tarbib.

Loki lähenemine nõuab, et stringist ekstraheeritaks ainult vajalikud andmed, mille väärtuste hulk on väike. Nii saame väikese indeksi ja saame andmeid otsida, filtreerides neid aja ja indekseerimise alusel ning seejärel skaneerides järelejäänud regulaarsmõistete või alamstringside kaudu. Protsess võib tunduda mitte kõige kiirem, kuid Loki jagab päringu mitmeks osaks ja täidab need paralleelselt, töötledes lühikese aja jooksul suurt andmehulka. Sharide ja paralleelsete päringute arv neis on konfigureeritav; seega sõltub aega, mille jooksul andmeid saab töödelda, otseselt pakutud ressurssidest.

See kompromiss suure kiire indeksi ja väikese indeksi vahel, millel on paralleelne täielik läbivaatamine, võimaldab Lokil kontrollida süsteemi kulusid. Seda saab paindlikult seadistada ja laiendada vastavalt vajadustele.

Loki piirkond koosneb kolmest komponendist: Promtail, Loki, Grafana. Promtail kogub logisid, töötleb neid ja saadab Loki. Loki salvestab need. Grafana suudab küsida andmeid Lokist ja neid kuvada. Üldiselt saab Loki kasutada mitte ainult logide salvestamiseks ja nende otsimiseks. Kogu piirkond pakub suurt potentsiaali saabuvate andmete töötlemiseks ja analüüsimiseks, kasutades Prometheuse meetodit.
Installatsiooniprotsessi kirjeldust saab leida siin.

Logide otsimine

Logide otsimine on võimalik erilisel Grafana liidese – Explorer kaudu. Päringutes kasutatakse LogQL-i keelt, mis sarnaneb väga PromQL-iga, mida kasutatakse Prometheuses. Põhimõtteliselt saab seda käsitleda kui jaotatud grep’i.

Otsingu liides näeb välja selline:

Igal päringul on kaks osa: selector ja filter. Selector on otsing indekseeritud metaandmete (siltide) alusel, mis on logidele määratud, ja filter on otsingurida või regulaarne väljend, millega filtreeritakse need kirjed, mille määrab selektor. Antud näites: Kahe suure kaare sees on selektor, 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 selektorita, kuid silte saab teha nii üldiseks kui soovite.

Selector on key-value väärtused suurte kaarte sees. Saate kombineerida valijaid ja seada erinevaid otsingu tingimusi, kasutades operaatorit =, != või regulaarseid väljendeid:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Leiab teadaolevate instance'ide logid, mis sisaldavad väärtusi kafka-2, kafka-3, ja välistavad dev 

Filter on tekst või regex, mis filtreerib kõik andmed, mis on saadud valijatest.

On võimalik saada ad-hoc graafikuid saadud andmetest metrics režiimis. Näiteks võib teada saada, kui tihti ilmub nginx logides kirje, mis sisaldab stringi index:

Täpse võimaluste kirjelduse leiate dokumentatsioonist LogQL.

Logide parsimine

Logide kogumiseks on mitu võimalust:

• Promtaili abil, mis on logide kogumise standardkomponent.
• Otseselt Docker konteinerist kasutades Loki Docker Logging Driverit.
• Kasutada Fluentd või Fluent Bit, millel on võime saata andmeid Loki'sse. Erinevalt Promtailist on neil valmispakendatud parserid praktiliselt igasuguste logide jaoks ja nad saavad hakkama ka multiline logidega.

Tavaliselt kasutatakse parsimiseks Promtaili. See teeb kolme asja:

• Otsib andmeallikaid.
• Lisab neile labelid.
• Saab andmed Loki'sse.

Hetkel suudab Promtail lugeda logisid kohalikest failidest ja systemd journalist. See peab olema paigaldatud igasse masinasse, millest logisid kogutakse.

Kubernetes'e integreerimine: Promtail sai automaatselt Kubernetes REST API kaudu teavet klastri oleku kohta ja kogub logisid sõlmedest, teenustest või podidest, jaotades labelid metainfo põhjal Kubernetes'e andmetest (pod'i nimi, faili nimi jne).

Samuti on võimalik jaotada labelid logi andmete põhjal kasutades Pipeline'i. Promtail'i Pipeline võib koosneda neljast tüüpi etapist. Üksikasjalikumalt — ametlikust dokumentatsioonist, siin mainin mõned nüansid.

1. Parsimise etapid. See on RegEx ja JSON etapp. Sellel etapil ekstraktime andmed logidest nii nimetatud extracted map'i. Ekstraktimist on võimalik teha JSON'ist, kopeerides lihtsalt vajalikud väljad extracted map'i, või regulaaravaldite (RegEx) kaudu, kus extracted map'is “kaardistatakse” nimetatud grupid. Extracted map on key-value salvestus, kus key on välja nimi ja value on selle väärtus logidest.
2. Transformatsiooni etapid. Sellel etapil on kaks võimalust: transform, kus määrame transformatsiooni reeglid, ja source — andmeallikas transformatsiooni jaoks extracted map'ist. Kui extracted map'is ei ole sellist väljade, siis see luuakse. Seega on võimalik luua labelid, mis ei põhine extracted map'il. Selles etapis saame andmeid extracted map'is manipuleerida, kasutades piisavalt võimsat Golang Template. Pealegi tuleb meeles pidada, et extracted map laaditakse täielikult parsimise käigus, mis annab võimaluse näiteks väärtuse kontrollimiseks: “{{if .tag}tag value exists{end}}”. Mall toetab tingimusi, sildu ja mõningaid stringi funktsioone, nagu Replace ja Trim.
3. Tegevuste etapid. Sel etapil saab midagi teha eraldatud andmetega:
   • Loo silt extracted data'st, mida indekseeritakse Lokis.
   • Muuda või määra sündmuse aega logis.
   • Muuda andmeid (logi sisu), mis saadetakse Lokisse.
   • Loo mõõdikud.
4. Filtreerimise etapid. Match etapp, kus saab kas saata /dev/null salvestusi, mida me ei vaja, või suunata need edasiseks töötlemiseks.

Näitan oma näo puhul, kuidas saab tavalisi nginx logisid Promtaili abil töödelda.

Katsetamiseks kasutame muutunud pilti nginx jwilder/nginx-proxy:alpine ja väikest deemonit, mis oskab iseendalt HTTP kaudu küsida. Deemonil on määratud mitu lõpp-punkti, mille kaudu ta saab vastata erineva suuruse, erinevate HTTP staatuste ja eri viivitustega.

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

docker-compose.yml failis seadistame Promtaili ja määrame teed konfiguratsioonini:

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 failis logide tee (konfiguratsioonis on valik "docker", mis teeb sama ühe rea kuid see ei oleks nii arusaadav):

scrape_configs:
 - job_name: containers

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

Selle konfiguratsiooni sisselülitamisel jõuavad Loki'sse logid kõikidest konteineritest. Selle vältimiseks muudame testimis-nginx seadeid docker-compose.yml failis – lisame logimise sildivälja:

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

Muudame promtail.yml ja seadistame Pipeline'i. Sisendiks on logid järgmises vormis:

{"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 etapp:

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

Ekstraktime sissetulevast JSON-st voodist stream, attrs, attrs.tag (kui need on olemas) ja paneme need eraldatud kaardile.

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

Kui õnnestub field tag eraldatud kaardile panna, kasutame regex'i, et eraldada pildi ja konteineri nimed.

 - labels:
     image_name:
     container_name:

Määrame sildid. Kui eraldatud andmetes leitatakse võtmed image_name ja container_name, siis nende väärtused määratakse vastavatele siltidele.

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

Kustutame kõik logid, millel ei ole leitud kehtivaid silte image_name ja container_name.

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

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

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

Kohandame sisendstringi regulaaravaldistega ja ekstraktime nginx virtuaalse hosti ja nginx logirida.

     - 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[^/?.]+).*$

Analüüsime request_url-i. Kasutades regex'i, määrame päringu eesmärgi: staatika, fotod, API ja määrame eraldatud kaardile vastava võti.

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

Kasutades tingimuslikke operaatorid Template's, kontrollime eraldatud kaardi väljad ja määrame välja request_type vajalikud väärtused: photo, static, API. Määrame other, kui ei õnnestu. Nüüd sisaldab request_type päringu tüüpi.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Määrame sildid api_request, virtual_host, request_type ja staatus (HTTP staatus) selle alusel, mis õnnestus eraldatud kaardile panna.

       - output:
           source: nginx_log_row

Muudame väljundit. Nüüd saadetakse Loki'sse puhastatud nginx-logi eraldatud kaardilt.

Pärast antud konfi käivitamist on nähtav, et igale kirjele on määratud sildid logist saadud andmete põhjal.

Oluline on meeles pidada, et suures koguses väärtustega (kardinaalsus) märgiste väljavõtmine võib oluliselt vähendada Loki tegevuse kiirus. Ehk teisisõnu, ei tasu näiteks indekseerida user_id. Lisainfot selle kohta leiate artiklist "Kuidas märgid Loki's muudavad logiküsimusi kiiremini ja lihtsamaks". Kuid see ei tähenda, et user_id peale indekseid ei saaks otsida. Otsingus tuleb kasutada filtreid (andmete "grepimine"), samas kui indeks toimib siinkohal voogude identifikaatorina.

Logide visualiseerimine

Loki saab olla andmeallikas Grafana diagrammide jaoks, kasutades LogQL. Toetatud funktsioonid on järgmised:

• rate — kirjeid sekundis;
• count over time — kirjeid määratud ajavahemikus.

Lisaks on olemas agregatsioonifunktsioonid Sum, Avg ja teised. Saame luua suhteliselt keerulisi diagramme, näiteks HTTP-vea arvu diagrammi:

Standardsed andmeallikad Loki kohta on mõnes mõttes piiratud võrreldes Prometheuse andmeallikaga (näiteks ei saa legendi muuta), kuid Loki saab ühendata Prometheuse tüüpi allikana. Ma ei ole kindel, kas see on dokumenteeritud käitumine, kuid arendajate vastuse põhjal "Kuidas seadistada Loki Prometheuse andmeallikana? · Küsimus #1222 · grafana/loki", on see täiesti seaduslik ning Loki on täielikult ühilduv PromQL-iga.

Lisame Loki andmeallikana, mille tüüp on Prometheus ja täiendame URL-i /loki:

Ja saame luua diagramme nagu siis, kui töötaksime Prometheuse mõõtmistega:

Ma arvan, et funktsionaalsuse erinevused on ajutised ja arendajad parandavad seda tulevikus.

Mõõtmised

Loki-s on saadaval võimalus numbriliste mõõtmiste väljavõtmiseks logidest ja nende edastamiseks Prometheusesse. Näiteks sisaldab nginx logis vastuse baitide arvu ning teatud variatsiooni isegi vastuseaja sekundeid. Need andmed saab väljavõtta ja saata Prometheusesse.

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 määrata ja uuendada mõõdikuid, mis põhinevad andmetel extracted map'ist. Need mõõdikud ei saadeta Lokisse — need ilmuvad Promtaili /metrics endpoint'is. Prometheusi tuleb konfigureerida nii, et see saaks anda andmeid, mis on saadud sellel etapil. Antud näites kogume request_type=“api” puhul mõõdik-graafikuid. Sellega tüübi mõõdikutega on mugav saada protsente. Statistika ja piltide jaoks kogume byte'ide summa ja ridade arvu, kus me byte’id saime, et arvutada keskmine väärtus.

Rohkem teavet mõõdikute kohta leiate siit siin.

Ava port Promtailis:

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

Veendume, et mõõdikud, millel on eeskirja promtail_custom eel, on ilmnenud:

Seame üles Prometheusi. Lisame töö promtail:

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

Ja joonistame diagrammi:

Nii saab teada näiteks neli aeglasemat päringut. Samuti saab nende mõõdikute jaoks seada üles jälgimise.

Mastaabis

Loki võib olla kas ühebitine režiim (single binary mode) või jaotatud (horizontally-scalable mode). Teises reas võib ta salvestada andmeid pilve, samas, kui chunkid ja indeks hoitakse eraldi. Versioonis 1.5 on realiseeritud võimalus salvestada ühte kohta, kuid seda ei soovitata veel tootmises kasutada.

Chunk'e võib salvestada S3-ühtse salvestusse, indeksite jaoks — kasutada horisontaalselt skaleeritavaid andmebaase: Cassandra, BigTable või DynamoDB. Loki muud osad — Distributors (kirjutamiseks) ja Querier (päringute jaoks) — on stateless ja samuti skaleeritavad horisontaalselt.

DevOpsDays Vancouver 2019 konverentsil ütles üks osaleja Callum Styan, et koos Lokiga on tema projekt saanud petabaite logisid, mille indeks on alla 1% kogusummast: “How Loki Correlates Metrics and Logs — And Saves You Money”.

Loki ja ELK võrdlemine

Indeksi suurus

Saadud indeksisuuruse testimiseks võtsin logid nginx konteinerist, millele eelnevalt seati üles Pipeline. Logifail sisaldas 406 624 rida kogusummas 109 MB. Logisid genereeriti tunni jooksul, ligikaudu 100 kirje sekundis.

Kaks näidet logist:

ELK indekseerimise korral andis see indeksisuuruseks 30,3 MB:

Loki puhul oli see umbes 128 KB indeksit ja umbes 3,8 MB andmeid plokkides. Tasub märkida, et logi oli kunstlikult genereeritud ja see ei erinenud suurest andmete mitmekesisusest. Lihtne gzip algse Dockeri JSON-logi andmetele andis 95,4% tihenduse, ja arvestades, et Loki'sse saadeti ainult puhastatud nginx-logi, on tihendamine 4 MB tasemele mõistetav. Loki jaoks oli unikaalsete väärtuste koguhulk siltide osas 35, mis selgitab väikese indeksi suuruse. ELK-i logi puhastati samuti. Nii et Loki tihendas algandmeid 96% võrra, ELK aga 70% võrra.

Mälu kasutamine

Kui võrrelda kogu Prometheuse ja ELK-i steeki, siis Loki 'tarbib' mitu korda vähem. On arusaadav, et Go-l põhinev teenus kasutab vähem ressursse kui Java-l põhinev teenus, ja JVM Heap Elasticsearch'i ja Loki eraldatud mälu suuruse võrdlemine ei ole korrektne, kuid tasub siiski märkida, et Loki kasutab tõeliselt vähem mälu. Tema eelis CPU osas ei ole nii ilmne, kuid on siiski olemas.

Kiirus

Loki 'neelab' logisid kiiremini. Kiirus sõltub paljuski erinevatest teguritest — millised on logid, kui keeruliselt me neid parsimme, võrk, kõvaketas jne — kuid see on kindlasti kiirem kui ELK (minu testis umbes kaks korda). See tuleneb sellest, et Loki paneb indeksi palju vähem andmeid ja seega kulutab indekseerimisele vähem aega. Otsingu kiirus on aga vastupidine: Loki aeglustub märkimisväärselt andmete puhul, mis ületavad mõnda gigabaiti, ELK-i otsingukiirus ei sõltu aga andmete suurusest.

Logide otsimine

Loki jääb oluliselt alla ELK-ile logide otsingu võimaluste poolest. Grep regulaarselt väljendite tegemiseks on tugev tööriist, kuid see jääb alla täielikule andmebaasile. Vahemiku päringute puudumine, agregatsioon ainult siltide alusel ja võimetus otsida ilma silte — kõik need piirangud takistavad meid otsimisel huvipakkuva teabe leidmisel Loki-s. See ei tähenda, et Loki abil midagi ei saa leida, vaid määrab tööhäda logidega, kus esmalt leid tõrge Prometheuse graafikutelt ja seejärel nende siltide alusel otsitakse, mis logides juhtus.

Liides

Esiteks, see on ilus (vabandan, ei saanud ennast tagasi hoida). Grafana omab meeldivat liidest, kuid Kibana on palju funktsionaalsem.

Loki plussid ja miinused

Plusside on see, et Loki integreerub Prometheus'ega, seega saame mõõdikud ja häired kohe välja. See on mugav logide kogumiseks ja nende salvestamiseks Kubernetes Podide juures, kuna see omab Prometheuselt pärit teenuste avastamise funktsiooni ja automaatselt lisab silte.

Miinustest - nõrk dokumentatsioon. Mõningaid asju, näiteks Promtaili omadusi ja võimalusi, avastasin alles koodi uurimise käigus, õnneks on see avatud lähtekoodiga. Veel üks miinus - nõrgad parsimise võimalused. Näiteks ei suuda Loki mitmerealisi logisid parseerida. Samuti on miinuseks see, et Loki on suhteliselt noor tehnoloogia (vabastamine 1.0 toimus novembris 2019).

Kokkuvõte

Loki on 100% huvitav tehnoloogia, mis sobib väikestele ja keskmistele projektidele, võimaldades lahendada mitmeid logide agregatsiooni, nende otsingu, jälgimise ja analüüsi ülesandeid.

Me ei kasuta Loki-d Badoos, kuna meil on ELK-stack, mis meid rahuldab ja mis on aastate jooksul kogunud erinevaid kohandatud lahendusi. Meie jaoks on piduriks logide otsing. Peaaegu 100 GB logisid päevas on oluline, et suudaksime leida kõik ja pisut rohkem ning teha seda kiiresti. Graafikute valmistamiseks ja jälgimiseks kasutame teisi lahendusi, mis on kohandatud meie vajadustele ja omavahel integreeritud. Loki stack'il on märkimisväärsed eelised, kuid see ei paku meile rohkem kui meil juba olemas on, ja selle eelised ei kata migratsioonikulusid.

Ja kuigi uurimise järel selgus, et me ei saa Loki-d kasutada, loodame, et see postitus aitab teid valiku tegemisel.

Artiklis kasutatud koodilehe hoidla asub siit.

Allikas: habr.com