Kirjautuminen Kubernetesiin: EFK vs PLG

Kirjautuminen Kubernetesiin: EFK vs PLG

Monitoroinnista on tullut erittäin tärkeä osa kasvavia pilviratkaisuja hajautettujen järjestelmien monimutkaisuuden kasvaessa. On välttämätöntä ymmärtää heidän käyttäytymisensä. Tarvitsemme skaalautuvia työkaluja, jotka voivat kerätä tietoja kaikista palveluista - ja tarjota asiantuntijoille yhden käyttöliittymän suorituskykyanalyysin, virheesittelyn, saatavuuden ja lokien kanssa.

Näiden samojen työkalujen on oltava tehokkaita ja tuottavia. Tässä artikkelissa tarkastellaan kahta suosittua teknologiapinoa: EFK (Elasticsearch) ja PLG (Loki) ja tarkastellaan niiden arkkitehtuuria ja eroja.

EFK-pino

Olet ehkä jo kuullut erittäin suositusta ELK:sta tai EFK:sta. Pino koostuu useista erillisistä osista: Elasticsearch (objektien tallennus), Logstash tai FluentD (lokkikeräys ja -aggregointi) ja Kibana visualisointia varten.

Tyypillinen työnkulku näyttää tältä:

Kirjautuminen Kubernetesiin: EFK vs PLG

Elasticsearch — hajautettu objektitallennus haun ja reaaliaikaisen analytiikan avulla. Erinomainen ratkaisu puolistrukturoiduille tiedoille, kuten lokeille. Tiedot tallennetaan JSON-asiakirjoina, indeksoidaan reaaliajassa ja jaetaan klusterin solmuille. Käytetään käänteistä hakemistoa, joka sisältää kaikki yksilölliset sanat ja niihin liittyvät asiakirjat kokotekstihakuun, joka puolestaan ​​perustuu Apache Lucene -hakukoneeseen.

SujuvaD on tiedonkeruuohjelma, joka yhdistää tiedot kerättäessä ja kuluttaessaan sitä. Se yrittää järjestää tiedot JSONissa mahdollisimman paljon. Sen arkkitehtuuri on laajennettavissa, niitä on enemmän satoja erilaisia ​​laajennuksia, yhteisön tukema, kaikkiin tilanteisiin.

Kibana - Elasticsearchin tietojen visualisointityökalu, jossa on erilaisia ​​lisäominaisuuksia, kuten aikasarjaanalyysi, kaavioanalyysi, koneoppiminen ja paljon muuta.

Elasticsearch-arkkitehtuuri

Elasticsearch-klusterin tiedot tallennetaan hajautetusti kaikkiin sen solmuihin. Klusteri koostuu useista solmuista saatavuuden ja joustavuuden parantamiseksi. Mikä tahansa solmu voi suorittaa kaikki klusterin roolit, mutta laajamittaisessa käyttöönotossa solmuille osoitetaan yleensä yksittäisiä tehtäviä.

Klusterisolmutyypit:

  • pääsolmu - hallitsee klusteria, tarvitaan vähintään kolme, yksi on aina aktiivinen;
  • datasolmu - tallentaa indeksoidut tiedot ja suorittaa sen kanssa erilaisia ​​tehtäviä;
  • sisäänottosolmu - järjestää liukuhihnat tietojen muuntamista varten ennen indeksointia;
  • solmujen koordinointi - reitityspyynnöt, haun käsittelyvaiheen vähentäminen, massaindeksoinnin koordinointi;
  • alerting node — hälytystehtävien käynnistäminen;
  • koneoppimissolmu - käsittelee koneoppimistehtäviä.

Alla oleva kaavio näyttää, kuinka tiedot tallennetaan ja replikoidaan solmujen välillä paremman tiedon saatavuuden saavuttamiseksi.

Kirjautuminen Kubernetesiin: EFK vs PLG

Jokaisen replikan tiedot on tallennettu käänteiseen hakemistoon, alla oleva kaavio näyttää, kuinka tämä tapahtuu:

Kirjautuminen Kubernetesiin: EFK vs PLG

Asennus

Yksityiskohtia voi katsoa täällä, käytän ruorikaaviota:

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

PLG pino

Älä ihmettele, jos et löydä tätä lyhennettä, sillä se tunnetaan paremmin nimellä Grafana Loki. Joka tapauksessa tämä pino on saamassa suosiota, koska se käyttää todistettuja teknisiä ratkaisuja. Olet ehkä jo kuullut Grafanasta, suositusta visualisointityökalusta. Sen tekijät kehittivät Prometheuksen inspiroimana Lokin, vaakasuunnassa skaalautuvan, tehokkaan lokien yhdistämisjärjestelmän. Loki indeksoi vain metatiedot, ei itse lehtiä, mikä on tekninen ratkaisu, jonka avulla se on helppokäyttöinen ja kustannustehokas.

Promtail - agentti lokien lähettämiseen käyttöjärjestelmästä Loki-klusteriin. grafana on Lokin tietoihin perustuva visualisointityökalu.

Kirjautuminen Kubernetesiin: EFK vs PLG

Loki on rakennettu samoilla periaatteilla kuin Prometheus, joten se soveltuu hyvin Kubernetes-tukkien varastointiin ja analysointiin.

Loki arkkitehtuuri

Loki voidaan ajaa joko yhtenä prosessina tai useana prosessina, mikä mahdollistaa vaakasuuntaisen skaalauksen.

Kirjautuminen Kubernetesiin: EFK vs PLG

Se voi toimia myös joko monoliittisena sovelluksena tai mikropalveluna. Ajo yhtenä prosessina voi olla hyödyllistä paikallisen kehityksen tai vähäisen seurannan kannalta. Teolliseen toteutukseen ja skaalautuvaan työmäärään on suositeltavaa käyttää mikropalveluvaihtoehtoa. Tiedon kirjoitus- ja lukupolut on erotettu toisistaan, joten sitä voidaan hienosäätää ja skaalata tarpeen mukaan.

Katsotaanpa lokinkeräysjärjestelmän arkkitehtuuria menemättä yksityiskohtiin:

Kirjautuminen Kubernetesiin: EFK vs PLG

Ja tässä on kuvaus (mikropalveluarkkitehtuuri):

Kirjautuminen Kubernetesiin: EFK vs PLG

Komponentit:

Promtail — solmuihin asennettu agentti (palvelusarjana), se poistaa lokit tehtävistä ja käyttää Kubernetes APIa saadakseen metatiedot, jotka merkitsevät lokit. Sitten se lähettää lokin Loki-pääpalveluun. Metatietojen kartoitus tukee samoja merkintäsääntöjä kuin Prometheus.

Jakelija — puskurina toimiva palvelujakelija. Käsitelläkseen miljoonia tietueita se pakkaa saapuvat tiedot ja pakkaa ne lohkoiksi saapuessaan. Useita tietonieluja on käynnissä samanaikaisesti, mutta yhteen saapuvaan tietovirtaan kuuluvien lokien pitäisi näkyä vain yhdessä niistä kaikista sen lohkoista. Tämä on järjestetty nielujen renkaaksi ja peräkkäiseksi hajautusjärjestelmäksi. Vikasietokyvyn ja redundanssin vuoksi tämä tehdään n kertaa (3, jos sitä ei ole määritetty).

Ingester - palvelun vastaanotin. Tietolohkot saapuvat pakattuna ja lokit on lisätty. Kun lohko on riittävän kokoinen, lohko huuhdellaan tietokantaan. Metatiedot menevät hakemistoon ja tiedot lokilohkosta kappaleisiin (yleensä objektin tallennustilaan). Nollauksen jälkeen vastaanotin luo uuden lohkon, johon lisätään uusia merkintöjä.

Kirjautuminen Kubernetesiin: EFK vs PLG

indeksi - tietokanta, DynamoDB, Cassandra, Google BigTable jne.

paloina — lokilohkot pakatussa muodossa, tavallisesti tallennettuna objektimuistiin, esimerkiksi S3.

Kysyjä - lukupolku, joka tekee kaiken likaisen työn. Se tarkastelee aikaväliä ja aikaleimaa ja etsii sitten osumia hakemistosta. Seuraavaksi se lukee tietolohkoja ja suodattaa ne tuloksen saamiseksi.

Katsotaan nyt kaikki toiminnassa.

Asennus

Helpoin tapa asentaa Kubernetesiin on käyttää ruoria. Oletamme, että olet jo asentanut ja määrittänyt sen (ja kolmas versio! noin kääntäjä)

Lisää arkisto ja asenna pino.

$ 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

Alla on esimerkki hallintapaneelista, joka näyttää tiedot Prometheus for Etcd -metriikasta ja Loki for Etcd pod -lokeista.

Kirjautuminen Kubernetesiin: EFK vs PLG

Keskustellaan nyt molempien järjestelmien arkkitehtuurista ja verrataan myös niiden ominaisuuksia toisiinsa.

vertailu

Kyselyn kieli

Elasticsearch käyttää Query DSL:ää ja Lucenen kyselykieltä tarjotakseen kokotekstihakuominaisuuksia. Se on vakiintunut, tehokas hakukone, jolla on laaja operaattorituki. Sen avulla voit etsiä kontekstin ja lajitella osuvuuden mukaan.

Renkaan toisella puolella on LogQL, jota käytetään Lokissa, PromQL:n (Prometheus-kyselykielen) seuraajassa. Se käyttää lokitunnisteita lokitietojen suodattamiseen ja valitsemiseen. On mahdollista käyttää joitain operaattoreita ja aritmetiikkaa kuvatulla tavalla täällä, mutta ominaisuuksiltaan se on Elastisen kielen jälkeen jäljessä.

Koska Lokissa kyselyt liittyvät tunnisteisiin, ne on helppo korreloida mittareiden kanssa ja näin ollen niiden avulla on helpompi organisoida toiminnan seuranta.

Skaalautuvuus

Molemmat pinot ovat vaakasuunnassa skaalautuvia, mutta Loki tekee siitä helpompaa, koska siinä on erilliset luku- ja kirjoituspolut sekä mikropalveluarkkitehtuuri. Loki voidaan räätälöidä tarpeidesi mukaan ja sitä voidaan käyttää erittäin suuriin lokitietomääriin.

Monivuokraus

Klusterin monivuokraus on yleinen teema OPEX-lyhenteessä, molemmat pinot tarjoavat monivuokrauksen. Niitä on useita Elasticsearchille tapoja asiakkaan erottelu: erillinen indeksi jokaiselle asiakkaalle, asiakaspohjainen reititys, yksilölliset asiakaskentät, hakusuodattimet. Lokilla on tukea HTTP X-Scope-OrgID-otsikon muodossa.

Maksaa

Loki on melko kustannustehokas, koska se ei indeksoi tietoja, vain metadataa. Tällä saavutetaan säästöjä varastoinnissa ja muisti (välimuisti), koska objektin tallennus on halvempaa kuin lohkotallennus, jota käytetään Elasticsearch-klustereissa.

Johtopäätös

EFK-pinoa voidaan käyttää useisiin tarkoituksiin, mikä tarjoaa maksimaalisen joustavuuden ja monipuolisen Kibana-käyttöliittymän analytiikkaa, visualisointia ja kyselyjä varten. Sitä voidaan edelleen parantaa koneoppimisominaisuuksilla.

Loki-pino on hyödyllinen Kubernetes-ekosysteemissä sen metatietojen etsintämekanismin vuoksi. Voit helposti korreloida tietoja seurantaa varten Grafanan aikasarjojen ja lokien perusteella.

Mitä tulee kustannuksiin ja pitkäaikaiseen lokivarastointiin, Loki on erinomainen lähtökohta pilviratkaisuihin.

Markkinoilla on enemmän vaihtoehtoja – jotkut saattavat olla sinulle parempia. Esimerkiksi GKE:ssä on Stackdriver-integraatio, joka tarjoaa erinomaisen valvontaratkaisun. Emme sisällyttäneet niitä tämän artikkelin analyysiimme.

viitteet:

Työntekijät käänsivät ja valmistelivat artikkelin Habrille Slurm koulutuskeskus — intensiivikurssit, videokurssit ja yrityskoulutus asiantuntijoilta (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Lähde: will.com

Lisää kommentti