Innlogging Kubernetes: EFK vs PLG

Innlogging Kubernetes: EFK vs PLG

Overvåking har blitt en svært viktig komponent i voksende skyløsninger ettersom kompleksiteten til distribuerte systemer øker. Det er nødvendig å forstå deres oppførsel. Vi trenger skalerbare verktøy som kan samle inn data fra alle tjenester – og gi spesialister ett enkelt grensesnitt med ytelsesanalyse, feildemonstrasjon, tilgjengelighet og logger.

De samme verktøyene må være effektive og produktive. I denne artikkelen vil vi se på to populære teknologistabler: EFK (Elasticsearch) og PLG (Loki) og undersøke deres arkitekturer og forskjeller.

EFK stabel

Du har kanskje allerede hørt om den svært populære ELK eller EFK. Stabelen består av flere distinkte deler: Elasticsearch (objektlagring), Logstash eller FluentD (loggsamling og aggregering), og Kibana for visualisering.

En typisk arbeidsflyt ser slik ut:

Innlogging Kubernetes: EFK vs PLG

Elasticsearch — distribuert objektlagring med søk og sanntidsanalyse. Utmerket løsning for semistrukturerte data som logger. Informasjon lagres som JSON-dokumenter, indekseres i sanntid og distribueres på tvers av klyngenoder. Det brukes en invertert indeks som inneholder alle unike ord og tilhørende dokumenter for fulltekstsøk, som igjen er basert på søkemotoren Apache Lucene.

FlytendeD er en datainnsamler som forener data når den samles inn og forbrukes. Den prøver å organisere dataene i JSON så mye som mulig. Arkitekturen er utvidbar, det er flere hundrevis av forskjellige utvidelser, samfunnsstøttet, for alle anledninger.

Kibana - et datavisualiseringsverktøy for Elasticsearch med ulike tilleggsfunksjoner, for eksempel tidsserieanalyse, grafanalyse, maskinlæring og mer.

Elasticsearch-arkitektur

Elasticsearch-klyngedata lagres spredt over alle nodene. En klynge består av flere noder for å forbedre tilgjengelighet og robusthet. Enhver node kan utføre alle rollene til klyngen, men i store utskaleringsutplasseringer tildeles noder typisk individuelle oppgaver.

Cluster node typer:

  • master node - administrerer klyngen, minst tre er nødvendig, en er alltid aktiv;
  • datanode - lagrer indekserte data og utfører forskjellige oppgaver med dem;
  • ingest node - organiserer rørledninger for transformering av data før indeksering;
  • koordinere node - ruting forespørsler, redusere søkebehandlingsfasen, koordinere masseindeksering;
  • varslingsnode — lansering av varslingsoppgaver;
  • maskinlæringsnode - behandling av maskinlæringsoppgaver.

Diagrammet nedenfor viser hvordan data lagres og replikeres på tvers av noder for å oppnå høyere datatilgjengelighet.

Innlogging Kubernetes: EFK vs PLG

Hver replikas data er lagret i en invertert indeks, diagrammet nedenfor viser hvordan dette skjer:

Innlogging Kubernetes: EFK vs PLG

Installasjon

Detaljer kan sees her, jeg bruker rordiagram:

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

PLG stabel

Ikke bli overrasket om du ikke finner dette akronymet, siden det er bedre kjent som Grafana Loki. I alle fall blir denne stabelen stadig mer populær fordi den bruker velprøvde tekniske løsninger. Du har kanskje allerede hørt om Grafana, et populært visualiseringsverktøy. Skaperne, inspirert av Prometheus, utviklet Loki, et horisontalt skalerbart, høyytelses loggaggregeringssystem. Loki indekserer kun metadataene, ikke journalene i seg selv, en teknisk løsning som gjør det enkelt å bruke og kostnadseffektivt.

Promtail - en agent for å sende logger fra operativsystemet til Loki-klyngen. grafana er et visualiseringsverktøy basert på data fra Loki.

Innlogging Kubernetes: EFK vs PLG

Loki er bygget på de samme prinsippene som Prometheus, noe som gjør den godt egnet for lagring og analyse av Kubernetes-logger.

Loki arkitektur

Loki kan kjøres enten som en enkelt prosess eller som flere prosesser, noe som gir mulighet for horisontal skalering.

Innlogging Kubernetes: EFK vs PLG

Den kan også fungere enten som en monolittisk applikasjon eller som en mikrotjeneste. Å kjøre som en enkelt prosess kan være nyttig for lokal utvikling eller for mindre overvåking. For industriell implementering og skalerbar arbeidsmengde, anbefales det å bruke alternativet mikrotjeneste. Banene for å skrive og lese data er atskilt, slik at de kan finjusteres og skaleres etter behov.

La oss se på arkitekturen til logginnsamlingssystemet uten å gå i detalj:

Innlogging Kubernetes: EFK vs PLG

Og her er beskrivelsen (mikrotjenestearkitektur):

Innlogging Kubernetes: EFK vs PLG

Komponenter:

Promtail — en agent installert på noder (som et sett med tjenester), den fjerner logger fra oppgaver og får tilgang til Kubernetes API for å få metadata som vil merke loggene. Den sender deretter loggen til Loki-hovedtjenesten. Metadatakartlegging støtter de samme taggingsreglene som Prometheus.

Distributør — en tjenestedistributør som fungerer som en buffer. For å behandle millioner av poster, pakker den innkommende data, og komprimerer dem i blokker etter hvert som de ankommer. Flere datasink kjører samtidig, men logger som tilhører én innkommende datastrøm skal bare vises i én av dem for alle blokkene. Dette er organisert i en ring av vasker og sekvensiell hashing. For feiltoleranse og redundans gjøres dette n ganger (3 hvis ikke konfigurert).

Ingester — tjenestemottaker. Datablokker kommer komprimert med logger lagt til. Når blokken er av tilstrekkelig størrelse, tømmes blokken til databasen. Metadata går til indeksen, og data fra loggblokken går til Chunks (vanligvis objektlagring). Etter tilbakestillingen oppretter mottakeren en ny blokk hvor nye oppføringer vil bli lagt til.

Innlogging Kubernetes: EFK vs PLG

Index - database, DynamoDB, Cassandra, Google BigTable, etc.

Biter — loggblokker i komprimert form, vanligvis lagret i objektlager, for eksempel S3.

Spørrer – leseveien som gjør alt det skitne arbeidet. Den ser på tidsområdet og tidsstempelet, og ser deretter på indeksen for å finne treff. Deretter leser den blokker med data og filtrerer dem for å oppnå resultatet.

La oss nå se alt i aksjon.

Installasjon

Den enkleste måten å installere i Kubernetes er å bruke ror. Vi antar at du allerede har installert og konfigurert det (og den tredje versjonen! ca. oversetter)

Legg til et depot og installer en stabel.

$ 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

Nedenfor er et eksempel på dashbord som viser data fra Prometheus for Etcd-metrikk og Loki for Etcd-pod-logger.

Innlogging Kubernetes: EFK vs PLG

La oss nå diskutere arkitekturen til begge systemene, og også sammenligne deres evner med hverandre.

sammenligning

Spørrespråk

Elasticsearch bruker Query DSL og Lucene spørrespråk for å gi fulltekstsøkefunksjoner. Det er en etablert, kraftig søkemotor med bred operatørstøtte. Med den kan du søke etter kontekst og sortere etter relevans.

På den andre siden av ringen er LogQL, brukt i Loki, etterfølgeren til PromQL (Prometheus query language). Den bruker loggkoder for å filtrere og velge loggdata. Det er mulig å bruke noen operatorer og aritmetikk som beskrevet her, men når det gjelder kapasiteter henger det etter Elastisk språk.

Siden spørringer i Loki er assosiert med tagger, er de enkle å korrelere med beregninger, og som et resultat er de lettere å organisere driftsovervåking med.

Skalerbarhet

Begge stablene er horisontalt skalerbare, men Loki gjør det enklere fordi den har separate lese- og skrivebaner og en mikrotjenestearkitektur. Loki kan tilpasses for å passe dine behov og kan brukes til svært store mengder loggdata.

Flerleie

Cluster multitenancy er et vanlig tema i OPEX-forkortelsen, begge stablene gir multitenancy. Det er flere for Elasticsearch måter å klientseparasjon: separat indeks for hver klient, klientbasert ruting, unike klientfelt, søkefiltre. Loke har støtte i form av en HTTP X-Scope-OrgID-header.

Koste

Loki er ganske kostnadseffektiv på grunn av det faktum at den ikke indekserer dataene, bare metadataene. Dette oppnår besparelser på lagring og minne (cache), siden objektlagring er billigere enn blokklagring, som brukes i Elasticsearch-klynger.

Konklusjon

EFK-stakken kan brukes til en rekke formål, og gir maksimal fleksibilitet og et funksjonsrikt Kibana-grensesnitt for analyser, visualisering og spørringer. Det kan forbedres ytterligere med maskinlæringsfunksjoner.

Loki-stakken er nyttig i Kubernetes-økosystemet på grunn av dens metadata-oppdagelsesmekanisme. Du kan enkelt korrelere data for overvåking basert på tidsserier i Grafana og logger.

Når det gjelder kostnader og langsiktig logglagring, er Loki et utmerket inngangspunkt til skyløsninger.

Det finnes flere alternativer på markedet – noen kan være bedre for deg. For eksempel har GKE en Stackdriver-integrasjon som gir en utmerket overvåkingsløsning. Vi tok dem ikke med i analysen vår i denne artikkelen.

referanser:

Artikkelen er oversatt og utarbeidet for Habr av ansatte Slurm treningssenter — intensive kurs, videokurs og bedriftsopplæring fra praktiserende spesialister (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Kilde: www.habr.com

Legg til en kommentar