Logga in Kubernetes: EFK vs PLG

Logga in Kubernetes: EFK vs PLG

Övervakning har blivit en mycket viktig komponent i växande molnlösningar i takt med att komplexiteten hos distribuerade system ökar. Det är nödvändigt att förstå deras beteende. Vi behöver skalbara verktyg som kan samla in data från alla tjänster – och förse specialister med ett enda gränssnitt med prestandaanalys, feldemonstration, tillgänglighet och loggar.

Samma verktyg måste vara effektiva och produktiva. I den här artikeln kommer vi att titta på två populära teknikstackar: EFK (Elasticsearch) och PLG (Loki) och undersöka deras arkitekturer och skillnader.

EFK stack

Du kanske redan har hört talas om den mycket populära ELK eller EFK. Stacken består av flera distinkta delar: Elasticsearch (objektlagring), Logstash eller FluentD (logginsamling och aggregering) och Kibana för visualisering.

Ett typiskt arbetsflöde ser ut så här:

Logga in Kubernetes: EFK vs PLG

Elasticsearch — distribuerad objektlagring med sökning och realtidsanalys. Utmärkt lösning för semistrukturerad data som loggar. Information sparas som JSON-dokument, indexeras i realtid och distribueras över klusternoder. Ett inverterat index används som innehåller alla unika ord och tillhörande dokument för fulltextsökning, vilket i sin tur är baserat på sökmotorn Apache Lucene.

FlytandeD är en datainsamlare som förenar data när den samlas in och konsumeras. Den försöker organisera data i JSON så mycket som möjligt. Dess arkitektur är utbyggbar, det finns fler hundratals olika tillägg, gemenskapsstödd, för alla tillfällen.

Kibana - ett datavisualiseringsverktyg för Elasticsearch med olika ytterligare funktioner, till exempel tidsserieanalys, grafanalys, maskininlärning och mer.

Elasticsearch arkitektur

Elasticsearch-klusterdata lagras spridda över alla dess noder. Ett kluster består av flera noder för att förbättra tillgängligheten och motståndskraften. Vilken nod som helst kan utföra alla klustrets roller, men i storskaliga distributioner tilldelas noder vanligtvis individuella uppgifter.

Klusternodtyper:

  • masternod - hanterar klustret, minst tre behövs, en är alltid aktiv;
  • datanod - lagrar indexerad data och utför olika uppgifter med den;
  • ingest node - organiserar pipelines för att transformera data före indexering;
  • koordinering av nod - routingbegäranden, reducering av sökbearbetningsfasen, koordinering av massindexering;
  • varningsnod — start av varningsuppgifter;
  • maskininlärningsnod - bearbetning av maskininlärningsuppgifter.

Diagrammet nedan visar hur data lagras och replikeras över noder för att uppnå högre datatillgänglighet.

Logga in Kubernetes: EFK vs PLG

Varje replikas data lagras i ett inverterat index, diagrammet nedan visar hur detta händer:

Logga in Kubernetes: EFK vs PLG

Installation

Detaljer kan ses här, jag använder styrdiagram:

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

PLG stack

Bli inte förvånad om du inte kan hitta denna akronym, eftersom den är mer känd som Grafana Loki. Hur som helst, denna stack vinner popularitet eftersom den använder beprövade tekniska lösningar. Du kanske redan har hört talas om Grafana, ett populärt visualiseringsverktyg. Dess skapare, inspirerade av Prometheus, utvecklade Loki, ett horisontellt skalbart, högpresterande logaggregationssystem. Loki indexerar endast metadata, inte tidskrifterna själva, en teknisk lösning som gör att den är enkel att använda och kostnadseffektiv.

Promtail - en agent för att skicka loggar från operativsystemet till Loki-klustret. grafana är ett visualiseringsverktyg baserat på data från Loki.

Logga in Kubernetes: EFK vs PLG

Loki är byggd på samma principer som Prometheus, vilket gör den väl lämpad för att lagra och analysera Kubernetes-loggar.

Loki arkitektur

Loki kan köras antingen som en enda process eller som flera processer, vilket möjliggör horisontell skalning.

Logga in Kubernetes: EFK vs PLG

Det kan också fungera antingen som en monolitisk applikation eller som en mikrotjänst. Att köra som en enda process kan vara användbart för lokal utveckling eller för mindre övervakning. För industriell implementering och skalbar arbetsbelastning rekommenderas att använda alternativet mikroservice. Banorna för att skriva och läsa data är separerade, så att den kan finjusteras och skalas efter behov.

Låt oss titta på arkitekturen för logginsamlingssystemet utan att gå in på detaljer:

Logga in Kubernetes: EFK vs PLG

Och här är beskrivningen (mikrotjänstarkitektur):

Logga in Kubernetes: EFK vs PLG

Komponenter:

Promtail — en agent installerad på noder (som en uppsättning tjänster), den tar bort loggar från uppgifter och kommer åt Kubernetes API för att få metadata som kommer att tagga loggarna. Den skickar sedan loggen till Loki-huvudtjänsten. Metadatamappning stöder samma taggningsregler som Prometheus.

Distributör — en tjänstedistributör som fungerar som en buffert. För att bearbeta miljontals poster packar den inkommande data och komprimerar den i block när den anländer. Flera datasänkor körs samtidigt, men loggar som tillhör en inkommande dataström bör endast visas i en av dem för alla dess block. Detta är organiserat i en ring av sänkor och sekventiell hash. För feltolerans och redundans görs detta n gånger (3 om inte konfigurerat).

Ingester — tjänstemottagare. Datablock kommer komprimerade med loggar som lagts till. När blocket är tillräckligt stort spolas blocket till databasen. Metadata går till indexet och data från loggblocket går till Chunks (vanligtvis objektlagring). Efter återställningen skapar mottagaren ett nytt block där nya poster kommer att läggas till.

Logga in Kubernetes: EFK vs PLG

index - databas, DynamoDB, Cassandra, Google BigTable, etc.

Bitar — loggblock i komprimerad form, vanligtvis lagrade i objektlagring, till exempel S3.

Querier – läsvägen som gör allt lumpen. Den tittar på tidsintervallet och tidsstämpeln och tittar sedan på indexet för att hitta matchningar. Därefter läser den datablock och filtrerar dem för att få resultatet.

Låt oss nu se allt i aktion.

Installation

Det enklaste sättet att installera i Kubernetes är att använda rodret. Vi antar att du redan har installerat och konfigurerat det (och den tredje versionen! cirka. översättare)

Lägg till ett arkiv och installera en stack.

$ 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

Nedan är ett exempel på instrumentpanelen som visar data från Prometheus för Etcd-mått och Loki för Etcd-podloggar.

Logga in Kubernetes: EFK vs PLG

Låt oss nu diskutera arkitekturen för båda systemen och även jämföra deras kapacitet med varandra.

jämförelse

Frågespråk

Elasticsearch använder Query DSL och Lucene frågespråk för att tillhandahålla fulltextsökningsmöjligheter. Det är en etablerad, kraftfull sökmotor med brett operatörsstöd. Med den kan du söka efter sammanhang och sortera efter relevans.

På andra sidan av ringen finns LogQL, som används i Loki, efterföljaren till PromQL (Prometheus query language). Den använder loggtaggar för att filtrera och välja loggdata. Det är möjligt att använda vissa operatorer och aritmetik enligt beskrivningen här, men när det gäller kapacitet släpar det efter Elastiskt språk.

Eftersom frågor i Loki är associerade med taggar är de lätta att korrelera med mätvärden, och som ett resultat är de lättare att organisera operativ övervakning med.

Skalbarhet

Båda stackarna är horisontellt skalbara, men Loki gör det enklare eftersom den har separata läs- och skrivvägar och en mikrotjänstarkitektur. Loki kan anpassas för att passa dina behov och kan användas för mycket stora volymer loggdata.

Flera hyresrätter

Cluster multitenancy är ett vanligt tema i OPEX-förkortningen, båda stackarna ger multitenancy. Det finns flera för Elasticsearch sätt klientseparation: separat index för varje klient, klientbaserad routing, unika klientfält, sökfilter. Loke har stöd i form av ett HTTP X-Scope-OrgID-huvud.

Kostnad

Loki är ganska kostnadseffektiv på grund av att den inte indexerar data, bara metadata. Detta uppnår besparingar på lagring och minne (cache), eftersom objektlagring är billigare än blocklagring, som används i Elasticsearch-kluster.

Slutsats

EFK-stacken kan användas för en mängd olika ändamål, vilket ger maximal flexibilitet och ett funktionsrikt Kibana-gränssnitt för analyser, visualisering och frågor. Det kan förbättras ytterligare med maskininlärningsfunktioner.

Loki-stacken är användbar i Kubernetes ekosystem på grund av dess mekanism för upptäckt av metadata. Du kan enkelt korrelera data för övervakning baserat på tidsserier i Grafana och loggar.

När det kommer till kostnad och långsiktig logglagring är Loki en utmärkt ingång till molnlösningar.

Det finns fler alternativ på marknaden - vissa kan vara bättre för dig. Till exempel har GKE en Stackdriver-integration som ger en utmärkt övervakningslösning. Vi tog inte med dem i vår analys i den här artikeln.

Länkar:

Artikeln översattes och förbereddes för Habr av anställda Slurm träningscenter — intensiva kurser, videokurser och företagsutbildning från praktiserande specialister (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Källa: will.com

Lägg en kommentar