🥇Logimine Kuberneteses: EFK vs PLG

Jälgimine on muutunud väga oluliseks komponendiks kasvavatesse pilve lahendustesse, kuna jaotatud süsteemide keerukus suureneb. See on vajalik nende käitumise mõistmiseks. On vaja skaleeritavaid tööriistu, mis suudavad koguda andmeid kõikidest teenustest ja pakkuda spetsialistidele ühtset liidest jõudluse analüüsimiseks, vigade tuvastamiseks, kätte saadavuse jälgimiseks ja logide haldamiseks.

Need tööriistad peavad olema tõhusad ja tootlikud. Käesolevas artiklis vaatleme kahte populaarset tehnoloogeograafiat: EFK (Elasticsearch) ja PLG (Loki) ning analüüsime nende arhitektuure ja erinevusi.

EFK tehnoloogeograafia

Võimalik, et olete juba kuulnud väga populaarsest ELK või EFK-st. Tehnoloogeograafia koosneb mitmest eraldi osast: Elasticsearch (objektide salvestamine), Logstash või FluentD (logide kogumine ja agregatsioon) ning Kibana visualiseerimiseks.

Tüüpiline töövoog näeb välja järgmiselt:

Elasticsearch — jaotatud objektide salvestamine, reaalajas otsingu ja analüüsi võimalustega. Suurepärane lahendus osaliselt struktureeritud andmete, nagu logide, jaoks. Teave salvestatakse JSON dokumentidena, indekseeritakse reaalajas ja jagatakse klastrite sõlmede vahel. Kasutatakse pöördsõnastikku, mis sisaldab kõiki unikaalseid sõnu ja nendega seotud dokumente täisteksti otsingu jaoks, mis põhineb Apache Lucene'i otsingumootoril.

FluentD — andmete kogumiseks mõeldud tööriist, mis ühtlustab andmeid nende kogumise ja kasutamise ajal. See püüab andmeid JSON formaadis võimalikult korralikult struktureerida. Selle arhitektuur on laiendatav ning olemas on üle saja erineva laienduse, mida toetavad kogukonnad iga olukorra jaoks.

Kibana — Elasticsearchi andmete visualiseerimise tööriist koos erinevate täiendavate funktsioonidega, nagu ajaread, graafikud, masinõpe ja muud.

Elasticsearchi arhitektuur

Elasticsearchi klastrite andmed on jaotatud kõikide selle sõlmede vahel. Klastril on mitu sõlme, et parandada kätte saadavust ja vastupidavust. Iga sõlm võib täita kõiki klastritöid, kuid suurtel skaleeritavatel juurutustel määratakse tavaliselt sõlmedele erinevad ülesanded.

Klastri sõlmede tüübid:

master node — haldab klastrit, vajab vähemalt kolme, üks neist on alati aktiivne;
data node — salvestab indekseeritud andmeid ja sooritab nendega erinevaid ülesandeid;
ingest node — korraldab andmete töötlemise torusid enne indekseerimist;
coordinating node — suunab päringud, lühendab otsingu töötlemise etappi, koordineerib massindekseerimist;
alerting node — käivitab teavitamise ülesandeid;
machine learning node — töötleb masinõppe ülesandeid.

Alloleval diagrammil on näidatud, kuidas andmeid salvestatakse ja kopeeritakse sõlmedes, et saavutada suurem andmete kättesaadavus.

Iga replikatsiooni andmed salvestatakse pöördindeksis, allolev skeem näitab, kuidas see toimub:

Paigaldamine

Detailide vaatamiseks kliki siia siin, ma kasutan helm chart'i:

$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elastics

PLG stack

Ärge muretsege, kui te ei leia seda akronüümi, kuna seda tuntakse paremini kui Grafana Loki. Igal juhul on see stack populaarsust kogumas, kuna rakendab läbimõeldud tehnilisi lahendusi. Olete võib-olla juba kuulnud Grafanast, populaarsest visualiseerimise tööriistast. Selle loojad, võttes inspiratsiooni Prometheusest, arendasid välja Loki, horisontaalselt skaleeritava ja kõrge jõudlusega logide kogumise süsteemi. Loki indekseerib ainult metaandmeid, mitte logisid endid, see tehniline lahendus on võimaldanud sellel olla lihtne kasutada ja kulutõhus.

Promtail — agent, mis saadab logisid opsüsteemist Loki klastrisse. Grafana — visualiseerimise tööriist, mis põhineb Loki andmetel.

Loki on üles ehitatud samadel põhimõtetel kui Prometheus, seega sobib see hästi logide säilitamiseks ja analüüsimiseks Kuberneteses.

Loki arhitektuur

Loki saab tööle panna nii ühes protsessis kui ka mitmes protsessis, mis tagab horisontaalse skaleeritavuse.

Samuti võib see töötada kas monoliitse rakendusena või mikroteenusena. Ühes protsessis töötamine võib olla kasulik kohaliku arenduse või väikese jälgimise jaoks. Tööstuslikuks rakendamiseks ja skaleeritava koormuse jaoks on soovitatav kasutada mikroteenuse varianti. Andmete kirjutamise ja lugemise teed on eraldatud, nii et seda saab piisavalt peenelt seadistada ja vajadusel skaleerida.

Vaatame logide kogumise süsteemi arhitektuuri ilma detailideta:

Ja siin on kirjeldus (mikroteenuse arhitektuur):

Koostisosad:

Promtail — agent, mis paigaldatakse sõlmedesse (teenuste kogumina), mis salvestab ülesannete logid ja suhtleb Kubernetes API-ga logide märgistamiseks vajalike metadate saamiseks. Seejärel saadab see logi põhiteenusele Loki. Metadatee märgistamiseks kehtivad samad reeglid nagu Prometheuses.

Jaotaja — jaotusteenus, mis töötab puhvri põhimõttel. Miljonite kirje töötlemiseks pakib see sissetulevaid andmeid, surudes need blotina kokku nende saabumise ajal. Samal ajal töötab mitu andmete vastuvõtjat, kuid ühe sissetuleva andmevoo logid peavad olema ainult ühes neist kõikides tema blotides. See on korraldatud vastuvõtjate ringina ja järjestikuse häshetimisega. Veatuks ja üleliigseks rakendatakse seda n korda (3, kui seda ei seadistata).

Andmevastuvõtja — vastuvõtja teenus. Andmeblokid tulevad kokku surutud koos lisatud logidega. Kui blokil on piisavalt suurus, tehakse selle blokeerimine andmebaasi. Metadatee läheb indeksisse, samas kui logiblokist saadud andmed jõuavad Chunks'isse (tavaliselt objektihoidlas). Pärast blokeerimist loob vastuvõtja uue bloki, kuhu lisatakse uusi kirjeid.

Index — andmebaas, näiteks DynamoDB, Cassandra, Google BigTable jne.

Chunks — kompaktsed logiblokid, mis on tavaliselt salvestatud objektihoidlas, nagu S3.

Küsija — lugemistee, mis teeb kogu musta töö. See vaatab ajavahemikku ja silte, seejärel vaatab indeksist vastete leidmiseks. Seejärel loeb andmeblokke ja filtreerib neid, et saada tulemus.

Nüüd vaatame kõike töös.

Paigaldamine

Kubernetesesse seadistamiseks on kõige lihtsam kasutada helm'i. Eeldame, et olete selle juba paigaldanud ja seadistatud (ja kolmandat versiooni! tõlkija märkus)

Lisame hoidla ja paigaldame steigi.

$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=false

Allpool on näide juhtpaneelist, kus kuvatakse andmed Prometheusest Etcd-i mõõtmete ja Loki logide jaoks.

Nüüd arutame mõlema süsteemi arhitektuuri ja võrdleme nende võimalusi.

Võrdlus

Küsimuste keel

Elasticsearch kasutab Query DSL-i ja Lucene päringukeelt, mis võimaldavad täisteksti otsingut. See on väljakujunenud võimas otsimootor, millel on lai toetavate operaatorete tugi. Selle abil saab otsida konteksti järgi ja järjekorrastada vastavuse alusel.

Ringis teisel pool on LogQL, mida kasutatakse Lokis, PromQL-i (Prometheuse päringukeel) järeltulija. See kasutab logimärksõnu logide filterimiseks ja andmete valimiseks. On võimalik kasutada mõningaid operaatorite ja aritmeetika, nagu on kirjeldatud, siin, kuid omaduste poolest jääb see Elasticu keelele alla.

Kuna Loki päringud on seotud märksõnadega, on neid lihtne seostada mõõdikute tõttu, mis teeb operatiivse jälgimise korraldamise lihtsamaks.

Skaleeritavus

Mõlemad tehnoloogiad on horisontaalselt skaleeritavad, kuid Loki puhul on see lihtsam, kuna sellel on eraldi andmete lugemise ja kirjutamise teed ning mikroteenuste arhitektuur. Lokit saab kohandada vastavalt teie vajadustele ja seda saab kasutada väga suurte logiandmete mahtude jaoks.

Mitmeüürilisus

Klastri mitmeüürilisus on üldine teema OPEX-i vähendamiseks, mõlemad tehnoloogiad toetavad mitmeüürilisust. Elasticsearchi jaoks on mitmeid viise klientide eraldamiseks: eraldi indeks igale kliendile, kliendi põhjal navigeerimine, unikaalsed kliendi väljad, otsingufiltrid. Lokis on olemas toetamine HTTP päises X-Scope-OrgID.

Hind

Loki on majanduslikult väga efektiivne, kuna see ei indekseeri andmeid, vaid ainult metaandmeid. Nii saavutatakse salvestusruumi ja mälu (vahemälu) kokkuhoid, kuna objektide salvestamine on odavam kui plokis, mida kasutatakse Elasticsearchi klastrites.

Kokkuvõte

EFK tehnoloogiat saab kasutada erinevateks eesmärkideks, pakkudes maksimaalset paindlikkust ja mitmeotstarbelist Kibana liidest analüütikaks, visualiseerimiseks ja päringuteks. Seda saab veelgi täiustada masinõppe võimalustega.

Loki tehnoloogia on Kubernetes'i ökosüsteemis kasulik seoses metaandmete avastamise mehhanismiga. Andmeid on lihtne seostada ajajoonte jälgimise ja logide põhjal Grafanas.

Kui rääkida logide säilitamise maksumusest ja pikkadest säilitamisperioodidest, on Loki suurepärane valik pilve lahendustesse sisenemiseks.

Turul on rohkem alternatiive - mõned võivad teile paremini sobida. Näiteks GKE jaoks on olemas Stackdriveri integreerimine, mis pakub suurepärast lahendust jälgimiseks. Me ei lisanud neid oma analüüsi selles artiklis.

Lingid:

Artikkel on tõlgitud ja koostatud Habra töötajate poolt Sljörmi koolituskeskusest — intensiivkursused, videokursused ja ettevõtte koolitus praktiseerivatelt spetsialistidelt (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Allikas: habr.com