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ä:
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;
Ä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.
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.
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.
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ä.
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ä)
Alla on esimerkki hallintapaneelista, joka näyttää tiedot Prometheus for Etcd -metriikasta ja Loki for Etcd pod -lokeista.
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.