Sisselogimine Kubernetes: EFK vs PLG

Sisselogimine Kubernetes: EFK vs PLG

Järelevalve on muutunud üha olulisemaks komponendiks pilvelahenduste kasvavate hajutatud süsteemide keerukuse tõttu. Nende käitumist on vaja mõista. Vajame skaleeritavaid tööriistu, mis suudavad koguda andmeid kõigist teenustest ja pakuvad spetsialistidele ühtset liidest koos toimivusanalüüsi, vigade demonstreerimise, saadavuse ja logidega.

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

EFK virn

Võib-olla olete juba kuulnud väga populaarsest ELK-st või EFK-st. Virn koosneb mitmest eraldiseisvast osast: Elasticsearch (objektide salvestusruum), Logstash või FluentD (palkide kogumine ja koondamine) ja Kibana visualiseerimiseks.

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

Sisselogimine Kubernetes: EFK vs PLG

Elasticsearch — hajutatud objektide salvestamine reaalajas otsingu ja analüütikaga. Suurepärane lahendus poolstruktureeritud andmete, näiteks logide jaoks. Teave salvestatakse JSON-dokumentidena, indekseeritakse reaalajas ja jaotatakse klastri sõlmede vahel. Täistekstiotsinguks kasutatakse ümberpööratud indeksit, mis sisaldab kõiki unikaalseid sõnu ja seotud dokumente, mis omakorda põhineb Apache Lucene otsingumootoril.

Ladus D on andmekoguja, mis ühendab andmeid kogumise ja tarbimise ajal. See üritab andmeid JSON-is võimalikult palju korraldada. Selle arhitektuur on laiendatav, neid on rohkem sadu erinevaid laiendusi, mida toetab kogukond, igaks juhuks.

Kibana on Elasticsearchi andmete visualiseerimise tööriist erinevate lisafunktsioonidega, nagu aegridade analüüs, graafikud, masinõpe ja palju muud.

Elasticsearch arhitektuur

Elasticsearchi klastri andmed salvestatakse jaotatuna kõigis selle sõlmedes. Klaster koosneb mitmest sõlmest, et parandada saadavust ja vastupidavust. Iga sõlm suudab täita kõiki klastri rolle, kuid suurte skaleeritavate juurutuste korral määratakse sõlmedele tavaliselt individuaalsed ülesanded.

Klastri sõlmede tüübid:

  • peasõlm - haldab klastrit, vajate vähemalt kolme, üks on alati aktiivne;
  • andmesõlm - salvestab indekseeritud andmeid ja täidab nendega erinevaid ülesandeid;
  • sisestussõlm – korraldab enne indekseerimist andmete teisendamiseks torujuhtmeid;
  • koordineeriv sõlm - päringu marsruutimine, otsingu töötlemise faasi vähendamine, hulgiindekseerimise koordineerimine;
  • hoiatussõlm – teavitamisülesannete käivitamine;
  • masinõppesõlm – masinõppe ülesannete töötlemine.

Allolev diagramm näitab, kuidas andmeid säilitatakse ja paljundatakse sõlmedes, et saavutada suurem andmete kättesaadavus.

Sisselogimine Kubernetes: EFK vs PLG

Iga koopia andmed salvestatakse ümberpööratud indeksis, allolev diagramm näitab, kuidas see juhtub:

Sisselogimine Kubernetes: EFK vs PLG

Paigaldamine

Üksikasju saab vaadata siin, kasutan roolidiagrammi:

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

PLG virn

Ärge imestage, kui te seda akronüümi ei leia, sest see on paremini tuntud kui Grafana Loki. Igal juhul kogub see stäkk populaarsust, kuna kasutab hästi kohandatud tehnilisi lahendusi. Võib-olla olete juba kuulnud populaarsest visualiseerimistööriistast Grafanast. Selle loojad töötasid Prometheusest inspireerituna välja Loki, horisontaalselt skaleeritava, suure jõudlusega logide koondamissüsteemi. Loki indekseerib ainult metaandmeid, mitte ajakirju endid, see tehniline lahendus on muutnud selle kasutamise lihtsaks ja kulutõhusaks.

Promtail - agent logide saatmiseks operatsioonisüsteemist Loki klastrisse. grafana on Loki andmetel põhinev visualiseerimistööriist.

Sisselogimine Kubernetes: EFK vs PLG

Loki on ehitatud samadel põhimõtetel nagu Prometheus, seega sobib see hästi Kubernetes palkide hoidmiseks ja parsimiseks.

Loki arhitektuur

Loki saab käivitada ühe protsessina või mitme protsessina, mis võimaldab horisontaalset skaleerimist.

Sisselogimine Kubernetes: EFK vs PLG

Samuti võib see töötada nii monoliitse rakendusena kui ka mikroteenusena. Ühe protsessina töötamine võib olla kasulik kohalikuks arenguks või peeneteraliseks jälgimiseks. Tööstuslikuks juurutamiseks ja skaleeritava töökoormuse jaoks on soovitatav kasutada mikroteenuse võimalust. Andmete kirjutamise ja lugemise teed on eraldatud, nii et neid saab vastavalt vajadusele peenhäälestada ja skaleerida.

Vaatame logide kogumise süsteemi arhitektuuri ilma üksikasjadeta:

Sisselogimine Kubernetes: EFK vs PLG

Ja siin on kirjeldus (mikroteenuse arhitektuur):

Sisselogimine Kubernetes: EFK vs PLG

Komponendid:

Promtail - sõlmedesse installitud agent (teenuste komplektina), see eemaldab logid ülesannetest ja pääseb juurde Kubernetes API-le, et hankida metaandmeid, mida logide märgistamiseks kasutatakse. Seejärel saadab see logi Loki põhiteenusesse. Metaandmete sobitamiseks toetatakse samu sildistamise reegleid, mis Prometheuses.

Jagaja - teenindus-turustaja, töötab puhvrina. Miljonite kirjete töötlemiseks pakib see sissetulevad andmed, tihendades need saabumisel plokkideks. Korraga töötab mitu andmevoogu, kuid samasse sissetulevasse andmevoogu kuuluvad logid peaksid kõigi selle plokkide puhul sattuma ainult ühte neist. See on korraldatud vastuvõtjate ringina ja järjestikuse räsimisena. Veataluvuse ja liiasuse tagamiseks tehakse seda n korda (3, kui pole konfigureeritud).

neelamine — teenuse vastuvõtja. Andmeplokid on tihendatud koos lisatud logidega. Niipea kui plokk on piisava suurusega, loputatakse plokk andmebaasi. Metaandmed lähevad registrisse ja logiploki andmed lähevad tükkidesse (tavaliselt objektide salvestusruumi). Pärast lähtestamist loob vastuvõtja uue ploki, kuhu lisatakse uued kirjed.

Sisselogimine Kubernetes: EFK vs PLG

indeks - andmebaas, DynamoDB, Cassandra, Google BigTable ja palju muud.

Tükid - kokkusurutud logiplokid, tavaliselt salvestatud objektide hoidlasse, näiteks S3.

Küsija on lugemisrada, mis teeb ära kogu musta töö. See vaatab ajavahemikku ja ajatemplit ning seejärel vastete otsimiseks indeksit. Järgmisena loeb see andmeplokke ja filtreerib need tulemuse saamiseks.

Vaatame nüüd kõike tööl.

Paigaldamine

Lihtsaim viis Kubernetesesse installimiseks on kasutada tüüri. Eeldame, et olete selle juba installinud ja konfigureerinud (ja kolmas versioon! u. tõlkija)

Lisame hoidla ja paneme virna.

$ 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äidisarmatuurlaud, mis näitab Prometheuse andmeid Etcd jaoks ja Loki mõõdikuid Etcd pod logide jaoks.

Sisselogimine Kubernetes: EFK vs PLG

Ja nüüd arutleme mõlema süsteemi arhitektuuri üle ja võrdleme nende võimalusi üksteisega.

Võrdlus

Päringu keel

Elasticsearch kasutab täistekstiotsingu pakkumiseks päringukeelt Query DSL ja Lucene. See on väljakujunenud võimas otsingumootor, millel on lai operaatori tugi. Selle abil saate otsida konteksti ja sortida asjakohasuse järgi.

Sõrmuse teisel poolel on Loki LogQL, PromQL-i (Prometheuse päringukeel) järglane. See kasutab logiandmete filtreerimiseks ja valimiseks logisilte. Võimalik on kasutada mõningaid tehteid ja aritmeetikat nagu kirjeldatud siin, kuid võimaluste poolest jääb see Elastic keelele alla.

Kuna Lokis on päringud seotud siltidega, on neid lihtne mõõdikutega seostada, mistõttu on nendega lihtsam operatiivseiret korraldada.

Skaalautuvus

Mõlemad virnad on horisontaalselt skaleeritavad, kuid Lokiga on see lihtsam, kuna sellel on eraldi lugemis- ja kirjutamisteed ning sellel on mikroteenuse arhitektuur. Loki saab kohandada vastavalt teie vajadustele ja seda saab kasutada väga suurte logiandmete mahtude jaoks.

Mitmekordne üürimine

Klastri mitu üürilepingut on OPEXi vähendamise tavaline teema, mõlemad virnad pakuvad mitut üürilepingut. Elasticsearchi jaoks on neid mitu viisil klientide eraldamine: eraldi indeks kliendi kohta, kliendipõhine marsruutimine, kliendi kordumatud väljad, otsingufiltrid. Lokil on toetama HTTP X-Scope-OrgID päisena.

Maksma

Loki on väga kuluefektiivne, kuna see ei indekseeri andmeid, vaid ainult metaandmeid. Seega ladustamise kokkuhoid ja mälu (vahemälu), kuna objektide salvestamine on odavam kui plokksalvestus, mida kasutatakse Elasticsearchi klastrites.

Järeldus

EFK pinu saab kasutada erinevatel eesmärkidel, pakkudes maksimaalset paindlikkust ja rikkalikku Kibana liidest analüütika, visualiseerimise ja päringute jaoks. Seda saab veelgi täiustada masinõppe võimaluste abil.

Loki virn on Kubernetese ökosüsteemis kasulik metaandmete avastamise mehhanismi tõttu. Grafana aegridade ja logide põhjal saate jälgimiseks andmeid hõlpsasti korreleerida.

Kui rääkida kuludest ja pikaajalisest logi säilitamisest, on Loki suurepärane valik pilve sisenemiseks.

Turul on rohkem alternatiive – mõni võib olla teie jaoks parem. Näiteks GKE-l on Stackdriveri integratsioon, mis pakub suurepärast jälgimislahendust. Me ei lisanud neid selle artikli analüüsi.

Lingid:

Artikli tõlkisid ja koostasid Habrile töötajad Slurmi koolituskeskus — intensiivkursused, videokursused ja ettevõtte koolitused praktikutelt (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Allikas: www.habr.com

Lisa kommentaar