Rąstų rinkimas iš Lokio

Mes, Badoo, nuolat stebime naujas technologijas ir vertiname, ar naudoti jas savo sistemoje, ar ne. Vienu iš šių tyrimų norime pasidalinti su bendruomene. Jis skirtas Loki, rąstų agregavimo sistemai.

„Loki“ yra žurnalų saugojimo ir peržiūros sprendimas, o šis krūvas taip pat suteikia lanksčią sistemą, skirtą jų analizei ir duomenų siuntimui „Prometheus“. Gegužės mėnesį buvo išleistas dar vienas atnaujinimas, kurį aktyviai reklamuoja kūrėjai. Mums buvo įdomu, ką „Loki“ gali padaryti, kokias funkcijas jis suteikia ir kiek jis gali būti alternatyva ELK, dabar naudojamam kaminui.

Kas yra Lokis

„Grafana Loki“ yra komponentų rinkinys, skirtas visai registravimo sistemai. Skirtingai nuo kitų panašių sistemų, „Loki“ remiasi idėja indeksuoti tik žurnalo metaduomenis - etiketes (kaip ir „Prometheus“), o pačius rąstus suspausti vienas šalia kito į atskirus gabalus.

Домашняя страница, GitHub

Prieš pradėdamas išsiaiškinti, ką galite padaryti su Loki, noriu paaiškinti, ką reiškia „idėją indeksuoti tik metaduomenis“. Palyginkime Loki metodą ir indeksavimo metodą tradiciniuose sprendimuose, pvz., Elasticsearch, naudodami eilutės iš nginx žurnalo pavyzdį:

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

Tradicinės sistemos analizuoja visą eilutę, įskaitant laukus su daugybe unikalių user_id ir item_id reikšmių, ir viską saugo dideliuose indeksuose. Šio metodo pranašumas yra tas, kad galite greitai vykdyti sudėtingas užklausas, nes beveik visi duomenys yra indekse. Tačiau už tai turite mokėti, nes indeksas tampa didelis, o tai reiškia, kad reikia atminties. Dėl to viso teksto rąstų indeksas yra panašus į pačių rąstų dydį. Norint greitai ieškoti, indeksas turi būti įkeltas į atmintį. Ir kuo daugiau žurnalų, tuo greičiau indeksas didėja ir sunaudojama daugiau atminties.

„Loki“ metodas reikalauja, kad iš eilutės, kurios reikšmių skaičius yra mažas, būtų išgauti tik būtini duomenys. Tokiu būdu gauname nedidelį indeksą ir galime ieškoti duomenų filtruodami juos pagal laiką ir indeksuotus laukus, o likusius nuskaitydami reguliariais posakiais arba poeilėmis. Procesas neatrodo pats greičiausias, tačiau Loki padalija užklausą į kelias dalis ir jas vykdo lygiagrečiai, per trumpą laiką apdorodama didelį duomenų kiekį. Juose esančių šukių ir lygiagrečių užklausų skaičius yra konfigūruojamas; taigi duomenų, kuriuos galima apdoroti per laiko vienetą, kiekis tiesiškai priklauso nuo teikiamų išteklių kiekio.

Šis didelio greito indekso ir mažo lygiagretaus brutalios jėgos indekso kompromisas leidžia Loki kontroliuoti sistemos kainą. Jis gali būti lanksčiai konfigūruojamas ir plečiamas pagal jūsų poreikius.

„Loki“ krūvą sudaro trys komponentai: „Promtail“, „Loki“, „Grafana“. Promtail renka žurnalus, juos apdoroja ir siunčia į Loki. Lokis juos saugo. O Grafana gali prašyti duomenų iš Loki ir juos parodyti. Apskritai „Loki“ gali būti naudojamas ne tik rąstų saugojimui ir paieškai juose. Visas krūvas suteikia puikias galimybes apdoroti ir analizuoti gaunamus duomenis naudojant Prometheus būdą.
Galima rasti diegimo proceso aprašymą čia.

Žurnalų paieška

Galite ieškoti žurnalų specialioje sąsajoje „Grafana — Explorer“. Užklausose naudojama LogQL kalba, kuri labai panaši į Prometheus naudojamą PromQL. Iš esmės tai gali būti laikoma paskirstytu grep.

Paieškos sąsaja atrodo taip:

Pati užklausa susideda iš dviejų dalių: parinkiklio ir filtro. Parinkiklis yra paieška pagal indeksuotus metaduomenis (etiketes), kurie yra priskirti žurnalams, o filtras yra paieškos eilutė arba reguliarioji išraiška, kuri išfiltruoja parinkiklio apibrėžtus įrašus. Pateiktame pavyzdyje: Garbanotuose skliaustuose - parinkiklis, viskas po to - filtras.

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

Dėl „Loki“ veikimo būdo negalite pateikti užklausų be parinkiklio, tačiau etiketės gali būti savavališkai bendros.

Pasirinkiklis yra pagrindinė vertės vertė riestiniuose skliaustuose. Galite derinti parinkiklius ir nurodyti skirtingas paieškos sąlygas naudodami =, != operatorius arba reguliariąsias išraiškas:

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

Filtras yra tekstas arba reguliarioji išraiška, kuri išfiltruos visus parinkiklio gautus duomenis.

Metrikos režimu pagal gautus duomenis galima gauti ad hoc grafikus. Pavyzdžiui, įrašo, kuriame yra indekso eilutė, atsiradimo dažnį galite sužinoti nginx žurnaluose:

Išsamų funkcijų aprašymą rasite dokumentacijoje LogQL.

Žurnalų analizavimas

Yra keli žurnalų rinkimo būdai:

• Su Promtail pagalba – standartiniu rąstų rinkimo rietuvės komponentu.
• Tiesiogiai iš doko konteinerio naudojant Loki Docker registravimo tvarkyklė.
• Naudokite „Fluentd“ arba „Fluent Bit“, kurie gali siųsti duomenis į „Loki“. Skirtingai nei „Promtail“, jie turi paruoštus analizatorius beveik bet kokio tipo rąstams ir taip pat gali tvarkyti kelių eilučių žurnalus.

Paprastai analizei naudojamas Promtail. Jis atlieka tris dalykus:

• Suranda duomenų šaltinius.
• Pritvirtinkite prie jų etiketes.
• Siunčia duomenis į Loki.

Šiuo metu Promtail gali nuskaityti žurnalus iš vietinių failų ir iš sistemos žurnalo. Jis turi būti sumontuotas kiekvienoje mašinoje, iš kurios renkami rąstai.

Yra integracija su „Kubernetes“: „Promtail“ automatiškai nustato klasterio būseną per „Kubernetes REST“ API ir surenka žurnalus iš mazgo, paslaugos ar bloko, iš karto paskelbdamas etiketes pagal „Kubernetes“ metaduomenis (pod pavadinimą, failo pavadinimą ir kt.).

Taip pat galite pakabinti etiketes pagal duomenis iš žurnalo naudodami „Pupeline“. „Pupeline Promtail“ gali sudaryti keturių tipų etapai. Daugiau informacijos - į oficialius dokumentus, iš karto atkreipsiu dėmesį į kai kuriuos niuansus.

1. Analizavimo etapai. Tai yra RegEx ir JSON etapas. Šiame etape mes ištraukiame duomenis iš žurnalų į vadinamąjį išskirtą žemėlapį. Galite išgauti iš JSON, tiesiog nukopijuodami laukus, kurių mums reikia į išgautą žemėlapį, arba naudodami reguliariąsias išraiškas (RegEx), kur pavadintos grupės yra „susijusios“ su ištrauktu žemėlapiu. Išskirtas žemėlapis yra rakto vertės saugykla, kur raktas yra lauko pavadinimas, o reikšmė yra jo vertė iš žurnalų.
2. Transformacijos etapai. Šiame etape yra dvi parinktys: transformavimas, kuriame nustatome transformacijos taisykles, ir šaltinis – transformacijos duomenų šaltinis iš ištraukto žemėlapio. Jei ištrauktame žemėlapyje tokio lauko nėra, jis bus sukurtas. Taigi galima kurti etiketes, kurios nėra pagrįstos ištrauktu žemėlapiu. Šiame etape mes galime manipuliuoti ištraukto žemėlapio duomenimis naudodami gana galingą golang šablonas. Be to, turime atsiminti, kad išskleistas žemėlapis yra visiškai įkeliamas analizuojant, todėl galima, pavyzdžiui, patikrinti jame esančią reikšmę: „{{if .tag}tag value egzistuoja{end}}“. Šablonas palaiko sąlygas, kilpas ir kai kurias eilučių funkcijas, pvz., Pakeisti ir Apkarpyti.
3. Veiksmo etapai. Šiame etape galite ką nors padaryti su ištrauktu:
   • Sukurkite etiketę iš ištrauktų duomenų, kuriuos indeksuos Loki.
   • Pakeiskite arba nustatykite įvykio laiką iš žurnalo.
   • Pakeiskite duomenis (žurnalo tekstą), kurie pateks į Loki.
   • Sukurkite metrikas.
4. Filtravimo etapai. Atitikties etapas, kai galime siųsti įrašus, kurių mums nereikia /dev/null, arba siųsti juos tolesniam apdorojimui.

Naudodamiesi įprastų nginx žurnalų apdorojimo pavyzdžiu, parodysiu, kaip galite analizuoti žurnalus naudodami „Promtail“.

Testui paimkime modifikuotą nginx jwilder/nginx-proxy:alpine vaizdą ir nedidelį demoną, kuris gali pateikti užklausą per HTTP kaip nginx-proxy. Demonas turi keletą galinių taškų, į kuriuos jis gali duoti įvairaus dydžio atsakymus su skirtingomis HTTP būsenomis ir skirtingu vėlavimu.

Rinksime rąstus iš dokerių konteinerių, kuriuos rasite kelyje /var/lib/docker/containers/ / -json.log

Docker-compose.yml nustatome Promtail ir nurodome kelią į konfigūraciją:

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

Įtraukite kelią į žurnalus į promtail.yml (konfigūracijoje yra parinktis „docker“, kuri daro tą patį vienoje eilutėje, bet tai nebūtų taip akivaizdu):

scrape_configs:
 - job_name: containers

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

Kai ši konfigūracija įjungta, Loki gaus žurnalus iš visų konteinerių. Norėdami to išvengti, mes keičiame testo nginx nustatymus docker-compose.yml - pridėkite registravimą prie žymos lauko:

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

Redaguokite promtail.yml ir nustatykite „Pupeline“. Žurnalai yra tokie:

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

dujotiekio etapai:

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

Išgauname srauto, attrs, attrs.tag laukus (jei yra) iš gaunamo JSON ir įdedame juos į išgautą žemėlapį.

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

Jei buvo galima įdėti žymos lauką į ištrauktą žemėlapį, tada naudojant regexp ištraukiame vaizdo ir konteinerio pavadinimus.

 - labels:
     image_name:
     container_name:

Priskiriame etiketes. Jei ištrauktuose duomenyse randami raktai image_name ir konteinerio_pavadinimas, tada jų reikšmės bus priskirtos atitinkamoms etiketėms.

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

Išmetame visus žurnalus, kuriuose nėra nustatytos etiketės vaizdo_pavadinimas ir konteinerio_pavadinimas.

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

Visų žurnalų, kurių vaizdo_pavadinimas yra lygus nginx.promtail.test, žurnalo lauką ištraukiame iš šaltinio žurnalo ir įtraukiame jį į ištrauktą žemėlapį naudodami eilutės klavišą.

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

Išvalome įvesties eilutę įprastomis išraiškomis ir ištraukiame nginx virtualų pagrindinį kompiuterį ir nginx žurnalo eilutę.

     - 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.]+)")?

Išanalizuoti nginx žurnalą su reguliariosiomis išraiškomis.

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

Išanalizuoti užklausos_url. Regexp pagalba nustatome užklausos tikslą: į statiką, į nuotraukas, į API ir nustatome atitinkamą raktą ištrauktame žemėlapyje.

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

Naudodami sąlyginius operatorius šablone, išskleistame žemėlapyje patikriname įdiegtus laukus ir nustatome reikiamas užklausos_tipo lauko reikšmes: nuotrauka, statinė, API. Jei nepavyko, priskirkite kitą. Dabar request_type yra užklausos tipas.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Nustatėme etiketes api_request, virtual_host, request_type ir status (HTTP statusas) pagal tai, ką pavyko įdėti į išgautą žemėlapį.

       - output:
           source: nginx_log_row

Pakeiskite išvestį. Dabar iš ištraukto žemėlapio išvalytas nginx žurnalas eina į Loki.

Paleidę aukščiau pateiktą konfigūraciją, galite pamatyti, kad kiekvienas įrašas yra pažymėtas pagal duomenis iš žurnalo.

Atminkite, kad etikečių su daugybe verčių (kardinalumo) ištraukimas gali žymiai sulėtinti Loki. Tai yra, neturėtumėte įtraukti į indeksą, pavyzdžiui, vartotojo_id. Daugiau apie tai skaitykite straipsnyjeKaip Loki etiketės gali pagreitinti ir palengvinti žurnalų užklausas“. Bet tai nereiškia, kad negalite ieškoti pagal user_id be indeksų. Ieškant būtina naudoti filtrus („patraukti“ pagal duomenis), o indeksas čia veikia kaip srauto identifikatorius.

Žurnalo vizualizacija

Loki gali veikti kaip duomenų šaltinis Grafana diagramoms naudojant LogQL. Palaikomos šios funkcijos:

• norma – įrašų skaičius per sekundę;
• skaičiuoti per laiką – įrašų skaičius duotame diapazone.

Taip pat yra agregavimo funkcijos Sum, Avg ir kt. Galite sudaryti gana sudėtingus grafikus, pavyzdžiui, HTTP klaidų skaičiaus grafiką:

Numatytasis Loki duomenų šaltinis yra šiek tiek mažiau funkcionalus nei Prometheus duomenų šaltinis (pavyzdžiui, negalite pakeisti legendos), tačiau Loki galima prijungti kaip Prometheus tipo šaltinį. Nesu tikras, ar tai dokumentuotas elgesys, bet sprendžiant iš kūrėjų atsakymo “Kaip sukonfigūruoti „Loki“ kaip „Prometheus“ duomenų šaltinį? · 1222 leidimas · grafana/loki“, pavyzdžiui, tai yra visiškai teisėta, o „Loki“ yra visiškai suderinama su „PromQL“.

Pridėkite Loki kaip duomenų šaltinį su tipu Prometheus ir pridėkite URL /loki:

Ir jūs galite sudaryti grafikus, tarsi dirbtume su „Prometheus“ metrika:

Manau, kad funkcionalumo neatitikimas laikinas ir ateityje kūrėjai jį ištaisys.

Metrika

„Loki“ suteikia galimybę iš žurnalų išgauti skaitines metrikas ir nusiųsti jas „Prometheus“. Pavyzdžiui, nginx žurnale yra baitų skaičius vienam atsakymui, taip pat, tam tikru standartinio žurnalo formato pakeitimu, laikas sekundėmis, per kurį buvo atsakyta. Šiuos duomenis galima išgauti ir išsiųsti „Prometheus“.

Pridėkite kitą skyrių prie 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

Ši parinktis leidžia apibrėžti ir atnaujinti metriką pagal duomenis iš ištraukto žemėlapio. Šios metrikos Loki nesiunčiamos – jos rodomos Promtail /metrics galutiniame taške. „Prometheus“ turi būti sukonfigūruotas, kad gautų duomenis iš šio etapo. Aukščiau pateiktame pavyzdyje už request_type="api" renkame histogramos metriką. Naudojant šio tipo metriką patogu gauti procentilius. Statikai ir nuotraukoms renkame baitų sumą ir eilučių, kuriose gavome baitus, skaičių, kad apskaičiuotume vidurkį.

Skaitykite daugiau apie metrikas čia.

Atidarykite prievadą „Promtail“:

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

Įsitikiname, kad pasirodė metrika su promtail_custom priešdėliu:

„Prometėjo“ nustatymas. Pridėti darbo skelbimą:

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

Ir nubraižykite grafiką:

Taip galite sužinoti, pavyzdžiui, keturias lėčiausias užklausas. Taip pat galite konfigūruoti šių metrikų stebėjimą.

Mastelio keitimas

„Loki“ gali būti tiek vieno dvejetainio, tiek susmulkinto (horizontaliai keičiamo režimo) režimu. Antruoju atveju jis gali išsaugoti duomenis debesyje, o gabalai ir indeksas saugomi atskirai. 1.5 versijoje yra įdiegta galimybė saugoti vienoje vietoje, tačiau kol kas nerekomenduojama jos naudoti gamyboje.

Dalys gali būti saugomos su S3 suderinamoje saugykloje, o indeksams saugoti gali būti naudojamos horizontaliai keičiamos duomenų bazės: Cassandra, BigTable arba DynamoDB. Kitos „Loki“ dalys – Platintojai (rašymui) ir „Querier“ (užklausoms) – yra be būsenos ir taip pat keičiasi horizontaliai.

„DevOpsDays Vancouver 2019“ konferencijoje vienas iš dalyvių Callumas Styanas paskelbė, kad su Loki jo projekte yra petabaitų rąstų, kurių indeksas yra mažesnis nei 1% viso dydžio: „Kaip Loki koreliuoja metrikas ir žurnalus – ir sutaupo jūsų pinigų".

Lokio ir ELK palyginimas

Indekso dydis

Norėdami patikrinti gautą indekso dydį, paėmiau žurnalus iš nginx konteinerio, kuriam buvo sukonfigūruotas aukščiau pateiktas vamzdynas. Žurnalo faile buvo 406 624 eilutės, kurių bendras tūris buvo 109 MB. Žurnalai buvo sukurti per valandą, maždaug 100 įrašų per sekundę.

Dviejų eilučių iš žurnalo pavyzdys:

Kai indeksavo ELK, indekso dydis buvo 30,3 MB:

„Loki“ atveju tai davė apie 128 KB indekso ir apie 3,8 MB duomenų dalimis. Verta paminėti, kad žurnalas buvo sukurtas dirbtinai ir jame nebuvo įvairių duomenų. Paprastas gzip originaliame Docker JSON žurnale su duomenimis suglaudino 95,4%, o atsižvelgiant į tai, kad pačiam Loki buvo išsiųstas tik išvalytas nginx žurnalas, suspaudimas iki 4 MB yra suprantamas. Bendras unikalių Loki etikečių reikšmių skaičius buvo 35, o tai paaiškina mažą indekso dydį. ELK rąstas taip pat buvo išvalytas. Taigi „Loki“ suglaudino pradinius duomenis 96%, o ELK – 70%.

Atminties suvartojimas

Jei lygintume visą Prometėjo ir ELK krūvą, tai Lokis „valgo“ kelis kartus mažiau. Akivaizdu, kad „Go“ paslauga sunaudoja mažiau nei „Java“, o „Heap Elasticsearch JVM“ dydžio ir Loki skirtos atminties palyginimas yra neteisingas, tačiau vis dėlto verta paminėti, kad „Loki“ naudoja daug mažiau atminties. Jo procesoriaus pranašumas nėra toks akivaizdus, ​​tačiau jis taip pat yra.

Pagreitinti

Lokis greičiau „suryja“ rąstus. Greitis priklauso nuo daugelio faktorių – kokie žurnalai, kaip įmantriai juos analizuojame, tinklas, diskas ir t.t. – bet jis tikrai didesnis nei ELK (mano teste – maždaug du kartus). Tai paaiškinama tuo, kad Loki į indeksą įdeda daug mažiau duomenų ir atitinkamai mažiau laiko skiria indeksavimui. Šiuo atveju situacija pasikeičia su paieškos greičiu: Loki pastebimai sulėtėja esant didesniems nei keli gigabaitai duomenims, o ELK paieškos greitis nuo duomenų dydžio nepriklauso.

Žurnalų paieška

Loki pagal žurnalų paieškos galimybes gerokai nusileidžia ELK. Grep su reguliariosiomis išraiškomis yra stiprus dalykas, tačiau jis yra prastesnis už suaugusiųjų duomenų bazę. Diapazono užklausų trūkumas, apibendrinimas tik pagal etiketes, nesugebėjimas ieškoti be etikečių – visa tai riboja mus ieškant dominančios informacijos Loki. Tai nereiškia, kad naudojant Loki nieko nepavyksta rasti, bet tai apibrėžia darbo su žurnalais eigą, kai pirmą kartą randate problemą Prometheus diagramose, o tada ieškote, kas atsitiko žurnaluose naudodami šias etiketes.

sąsaja

Visų pirma, jis gražus (atsiprašau, negalėjau atsispirti). „Grafana“ turi gražiai atrodančią sąsają, tačiau „Kibana“ yra daug funkcionalesnė.

Loki pliusai ir minusai

Iš pliusų galima pastebėti, kad „Loki“ integruojasi su „Prometheus“, todėl mes gauname metrikas ir įspėjimus. Patogu rinkti žurnalus ir juos saugoti su Kubernetes Pods, nes turi iš Prometheus paveldėtą paslaugos atradimą ir automatiškai priklijuoja etiketes.

Iš minusų – prasta dokumentacija. Kai kuriuos dalykus, pavyzdžiui, „Promtail“ funkcijas ir galimybes, atradau tik tyrinėdamas kodą, atvirojo kodo naudą. Kitas trūkumas yra silpnos analizės galimybės. Pavyzdžiui, Loki negali išanalizuoti kelių eilučių žurnalų. Be to, trūkumai yra tai, kad „Loki“ yra palyginti jauna technologija (1.0 leidimas buvo 2019 m. lapkričio mėn.).

išvada

Loki yra 100% įdomi technologija, tinkanti mažiems ir vidutiniams projektams, leidžianti išspręsti daugybę rąstų agregavimo, rąstų paieškos, rąstų stebėjimo ir analizės problemų.

Mes nenaudojame Loki Badoo, nes turime ELK stacką, kuris mums tinka ir kuris bėgant metams buvo apaugęs įvairiais individualiais sprendimais. Mums kliūtis – paieškos rąstuose. Turint beveik 100 GB žurnalų per dieną, mums svarbu viską ir dar šiek tiek rasti ir tai padaryti greitai. Diagramų sudarymui ir stebėjimui naudojame kitus sprendimus, pritaikytus mūsų poreikiams ir integruotus tarpusavyje. „Loki“ krūva turi apčiuopiamos naudos, tačiau ji neduos mums daugiau nei turime, o jo nauda tiksliai neatsvers migracijos išlaidų.

Ir nors atlikus tyrimą paaiškėjo, kad negalime naudoti Loki, tikimės, kad šis įrašas padės jums pasirinkti.

Yra saugykla su straipsnyje naudojamu kodu čia.

Šaltinis: www.habr.com