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:
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;
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.
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.
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:
Og her er beskrivelsen (mikrotjenestearkitektur):
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.
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)
Nedenfor er et eksempel på dashbord som viser data fra Prometheus for Etcd-metrikk og Loki for Etcd-pod-logger.
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.
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)