🥇Logimine Kuberneteses: EFK versus PLG

Jälgimine on muutunud järjest olulisemaks komponendiks pilvandmetöötluse lahendustes, kuna jaotatud süsteemide keerukus kasvab. See on vajalik nende käitumise mõistmiseks. Vajame skaleeritavaid tööriistu, mis suudavad andmeid kõigist teenustest koguda — ja pakkuda spetsialistidele ühtset liidest, millel on jõudluse analüüs, veateated, saadavus ja päevikud.

Need tööriistad peavad olema tõhusad ja jõudlusrikkad. Selles artiklis uurime kahte populaarset tehnoloogiakomplekti: EFK (Elasticsearch) ja PLG (Loki) ning käsitleme nende arhitektuuri ja erinevusi.

EFK komplekt

Võib-olla olete juba kuulnud väga populaarsest ELK või EFK-st. Komplekt koosneb mitmest eraldi osast: Elasticsearch (objektide ladustamine), Logstash või FluentD (andmete kogumine ja agregatsioon) ja Kibana visualiseerimiseks.

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

Elasticsearch — jaotatud objektide ladustamine reaalajas analüüsi ja otsimisega. Suurepärane lahendus osaliselt struktureeritud andmete, näiteks päevikute, jaoks. Teave salvestatakse JSON-dokumentidena, indekseeritakse reaalajas ja jaotatakse klastrite vahel. Kasutatakse pööratud indeksi, mis sisaldab kõiki unikaalseid sõnu ja nendega seotud dokumente täisteksti otsinguks, mis põhineb Apache Lucene'i otsingumootoril.

FluentD — andmete kogumise tööriist, mis ühtlustab andmeid kogumise ja tarbimise ajal. See püüab andmeid JSON-is nii palju korraldada, kui võimalik. Selle arhitektuur on laiendatav, olemas on üle saja erineva laienduse, mida toetab kogukond, igaks juhuks.

Kibana — andmete visualiseerimiseks mõeldud tööriist Elasticsearchi jaoks, millel on erinevaid lisavõimalusi, nagu ajas järjestamise analüüs, graafid, masinõpe jms.

Elasticsearchi arhitektuur

Elasticsearchi klastri andmed on jaotatud kõigi sõlmede vahel. Klastrit moodustavad mitmed sõlmed, et parandada saadavust ja resistentsust. Iga sõlm võib täita kõiki klastri rollisid, kuid suurtes skaleeritavates juurutustes määratakse sõlmedele tavaliselt eraldi ülesanded.

Klastri sõlmed:

master node — haldab klastrit, vajatakse vähemalt kolme, millest üks on alati aktiivne;
data node — hoiab indekseeritud andmeid ja teostab erinevaid ülesandeid nende kohta;
ingest node — korraldab torustikke andmete töötlemiseks enne indekseerimist;
coordinating node — suunab päringud, vähendab otsinguprotsessi etappe, koordineerib massindu indekseerimist;
alerting node — käivitab teavituste ülesandeid;
machine learning node — töötleb masinõppe ülesandeid.

Alloleval diagrammil on näidatud, kuidas andmed salvestatakse ja replikatsioonitakse sõlmede vahel, et saavutada suurem andmete saadavus.

Iga koopia andmed hoitakse pööratud indeksis, allolev skeem näitab, kuidas see toimub:

Installimine

Andmete üksikasju saab vaadata siit, ma kasutan helm charti:

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

PLG komplekt

Ärge muretsege, kui te ei leia seda akronüümi, kuna seda tuntakse rohkem kui Grafana Loki. Igatahes, see komplekt on populaarsust kogumas, kuna kasutab värskeid tehnilisi lahendusi. Võib-olla olete juba kuulnud Grafanast, populaarset visualiseerimistööriista. Selle loojaid, inspiratsiooni saades Prometheusest, arendasid välja Loki, horisontaalselt skaleeritava ja kõrgelt jõudlusrikka logide agregatsiooni süsteemi. Loki indekseerib ainult metaandmeid, kuid mitte logisid ise, see tehniline lahendus on võimaldanud tal olla lihtne kasutada ja majanduslikult tasuv.

Promtail — agent logide saatmiseks operatsioonisüsteemist Loki klastrisse. Grafana — visualiseerimistööriist, mis põhineb Loki andmetel.

Loki on üles ehitatud samadele põhimõtetele nagu Prometheus, mistõttu sobib see hästi Kubernetes'i logide salvestamiseks ja analüüsimiseks.

Loki arhitektuur

Loki saab käivitada nii ühe protsessi režiimis kui ka mitme protsessi režiimis, tagades horisontaalse skaleeritavuse.

See võib töötada nii monoliitse rakendusena kui ka mikroteenusena. Ühe protsessi režiim võib osutuda kasulikuks lokaalseteks arendusteks või väiksemateks jälgimistöödeks. Tootmisettevõtte juurutamiseks ja skaleeritava koormuse korral on soovitatav kasutada mikroteenuse varianti. Andmete kirjutamise ja lugemise teed on eraldatud, nii et seda saab piisavalt täpselt konfigureerida ja skaleerida vastavalt vajadusele.

Vaadakem logide kogumise süsteemi arhitektuuri ilma detailideta:

Siin on kirjeldus (mikroteenuse arhitektuur):

Koostisosad:

Promtail — agent, mis paigaldatakse sõlmedesse (teenuste kogumina), kogub see logisid ülesannetest ja kasutab Kubernetes API-d metainfo saamiseks, millega logisid märgistatakse. Seejärel saadab see logi põhiteenusele Loki. Metainfo märgistamiseks kehtivad samad reeglid nagu Prometheus'e puhul.

Jaotaja — teenus, mis toimib vahemikuna. Miljonite kirje töötlemiseks pakkib see sissetulevaid andmeid, tihendades neid plokkidena, kui need saabuvad. Samal ajal töötavad mitu andmevastuvõtjat, kuid logid, mis kuuluvad ühte sissetuleva andmevoogu, peavad olema ainult ühe neist kõigi oma plokkide jaoks. See on korraldatud vastuvõtjate ringina ja järjestikuse häshtimisega. Tõrkekindluse ja üleliigsuse vooruseks tehakse see n korda (3, kui ei seadista).

Ingester — andmevastuvõtja. Andmeplokid saabuvad tihendatuna koos logidega. Kui plokk on piisavalt suur, kirjutatakse plokk andmebaasi. Metainfo läheb indeksisse ja logiplokist tulnud andmed jõuavad Chunks'i (tavaliselt objektihoidlasse). Pärast kirjutamist loob vastuvõtja uue ploki, kuhu lisatakse uusi kirjeid.

Indeks — andmebaasid, nagu DynamoDB, Cassandra, Google BigTable jne.

Chunks — tihendatud logiplokid, mis tavaliselt salvestatakse objektihoidlasse, näiteks S3.

Küürija — lugemistee, mis teeb kogu musta tööt. See vaatab ajavahemikku ja märke, seejärel uurib indeksit vaste leidmiseks. Edasi loetakse andmeplokke ja filtreeritakse neid tulemuste saamiseks.

Nüüd vaatame, kuidas kõik töötab.

Installimine

Kubernetesesse paigaldamine on kõige lihtsam helm'i kasutamisel. Eeldame, et olete selle juba installinud ja seadistanud (ja kolmandat versiooni! tõlkija märk.)

Lisame hoidla ja installime stacki.

$ 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 Prometheus'e andmed Etcd ja Loki jaoks podide logide kohta.

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

Võrdlus

Küsimise keel

Elasticsearchis kasutatakse Query DSL-i ja Lucene päringukeelt, mis võimaldab täisteksti otsingut. See on hästi tuntud ja võimas otsingumootor, millel on ulatuslik toetamine operaatorite osas. Selle abil saab otsida konteksti järgi ja sorteerida asjakohasuse põhjal.

Teisest küljest on LogQL, mida rakendatakse Lokis, PromQL-i (Prometheus päringukeel) järglane. See kasutab logide märke andmete filtreerimiseks ja valimiseks. On võimalik kasutada teatud operaatorite ja aritmeetika, nagu on kirjeldatud siit, kuid võimaluste poolest jääb see Elastic keelele alla.

Kuna päringud Lokis on seotud märkidega — need on lihtsad siduda mõõtmistega, mistõttu on nende abil lihtsam korraldada operatiivset jälgimist.

Skaleeritavus

Mõlemad virnad on horisontaalselt skaleeritavad, kuid Lokiga on see lihtsam, kuna tal on eraldatud andmete lugemise ja kirjutamise teed ning tal on mikroteenuste arhitektuur. Loki saab konfigureerida vastavalt teie vajadustele ja seda saab kasutada väga suurte logide andmemahtude jaoks.

Mitmeühingulisus

Klastri mitmeühingulisus on üldine teema OPEX-i vähendamiseks, mõlemad virnad pakuvad mitmeühingulisust. Elasticsearchi jaoks on mitu võimalust klientide jagamiseks: iga kliendi jaoks eraldi indeks, klientide põhine marsruutimine, kliendi ainulaadsed väljad, otsingu filtrid. Lokis on see toetamine HTTP päises X-Scope-OrgID.

Hind

Loki on väga efektiivne kulude osas, kuna see ei indekseeri andmeid, vaid ainult metainfot. Nii saavutatakse salvestuskulude ja mälu (vahemälu) kokkuhoid, kuna objektide hoidmine on odavam kui plokki kasutav salvestus, mida kasutatakse Elasticsearchi klastrites.

Kokkuvõte

EFK virna saab kasutada erinevatel eesmärkidel, pakkudes maksimaalset paindlikkust ja mitmeotstarbelist Kibana liidest analüütikaks, visualiseerimiseks ja päringuteks. Seda saab täiendavalt täiendada masinõppe võimalustega.

Loki virn on kasulik Kubernetes'e ökosüsteemis metainfot avastava mehhanismi tõttu. Andmeid on lihtne siduda ajas järgneva jälgimise jaoks Grafanas ja logides.

Kuna tegemist on logide hinna ja pikaajalise säilitamisega, on Loki suurepärane valik pilvelahenduste sissejuhatamiseks.

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

Lingid:

Artikkel on tõlgitud ja ette valmistatud Habr'i töötajate poolt Slörmi koolituskeskus — intensiivkursused, videokursused ja ettevõtte koolitus praktiseerivatelt spetsialistidelt (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Allikas: habr.com