Overvågning er blevet en meget vigtig komponent i voksende cloud-løsninger med den stigende kompleksitet af distribuerede systemer. Det er nødvendigt at forstå deres adfærd. Vi har brug for skalerbare værktøjer, der kan indsamle data fra alle services – og give specialister en enkelt grænseflade med performanceanalyse, fejldemonstration, tilgængelighed og logs.
De samme værktøjer skal være effektive og produktive. I denne artikel vil vi se på to populære teknologistakke: EFK (Elasticsearch) og PLG (Loki) og analysere deres arkitekturer og forskelle.
EFK stak
Du har måske allerede hørt om de meget populære ELK eller EFK. Stakken består af flere separate dele: Elasticsearch (objektopbevaring), Logstash eller FluentD (indsamling og aggregering af logfiler) og Kibana til visualisering.
En typisk arbejdsgang ser sådan ud:
Elasticsearch — distribueret objektlagring med realtidssøgning og analyser. En fremragende løsning til semi-strukturerede data såsom logfiler. Oplysningerne gemmes som JSON-dokumenter, indekseres i realtid og fordeles på tværs af klyngens noder. Der bruges et omvendt indeks, der indeholder alle unikke ord og relaterede dokumenter til fuldtekstsøgning, som igen er baseret på Apache Lucene-søgemaskinen.
FlydendeD er en dataindsamler, der forener data, efterhånden som de indsamles og forbruges. Det forsøger at organisere dataene i JSON så meget som muligt. Dens arkitektur kan udvides, der er flere , støttet af fællesskabet, til alle lejligheder.
Kibana er et datavisualiseringsværktøj til Elasticsearch med forskellige ekstra funktioner, såsom tidsserieanalyse, grafer, maskinlæring og mere.
Elasticsearch arkitektur
Elasticsearch-klyngedata gemmes spredt over alle dets noder. Klyngen består af flere noder for at forbedre tilgængeligheden og modstandsdygtigheden. Enhver node kan udføre alle klyngeroller, men i store, skalerbare implementeringer tildeles noder normalt separate opgaver.
Klyndeknudetyper:
- master node - styrer klyngen, du har brug for mindst tre, en er altid aktiv;
- data node - gemmer indekserede data og udfører forskellige opgaver med dem;
- indtag node - organiserer pipelines til datatransformation før indeksering;
- koordinerende node - anmodningsruting, reduktion af søgebehandlingsfasen, koordinering af masseindeksering;
- alarmnode - lancering af meddelelsesopgaver;
- machine learning node - bearbejdning af maskinlæringsopgaver.
Diagrammet nedenfor viser, hvordan data bevares og replikeres på tværs af noder for at opnå højere datatilgængelighed.
Hver replikas data er gemt i et omvendt indeks, diagrammet nedenfor viser, hvordan dette sker:
Installation
Detaljer kan ses , jeg vil bruge styrdiagram:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPLG stak
Bliv ikke overrasket, hvis du ikke kan finde dette akronym, da det er bedre kendt som Grafana Loki. Under alle omstændigheder vinder denne stack popularitet, fordi den bruger veltilpassede tekniske løsninger. Du har måske allerede hørt om Grafana, et populært visualiseringsværktøj. Dets skabere, inspireret af Prometheus, udviklede Loki, et horisontalt skalerbart, højtydende log-aggregeringssystem. Loki indekserer kun metadataene, ikke journalerne selv, denne tekniske løsning har gjort det nemt at bruge og omkostningseffektivt.
Promtail - en agent til at sende logfiler fra operativsystemet til Loki-klyngen. grafana er et visualiseringsværktøj baseret på data fra Loke.
Loki er bygget efter de samme principper som Prometheus, så den er velegnet til lagring og parsing af Kubernetes-logfiler.
Loki arkitektur
Loki kan køres som en enkelt proces eller som flere processer, hvilket giver mulighed for horisontal skalering.
Det kan også fungere både som en monolitisk applikation og som en mikroservice. At køre som en enkelt proces kan være nyttig til lokal udvikling eller til finmasket overvågning. Til industriel implementering og skalerbar arbejdsbyrde anbefales det at bruge mikroserviceindstillingen. Dataskrive- og læsevejene er adskilte, så de kan finjusteres og skaleres efter behov.
Lad os se på arkitekturen af logindsamlingssystemet uden detaljer:
Og her er beskrivelsen (mikroservicearkitektur):
Komponenter:
Promtail - en agent installeret på noder (som et sæt tjenester), den fjerner logfiler fra opgaver og får adgang til Kubernetes API for at få metadata, der vil blive brugt til at markere logfilerne. Den sender derefter loggen til Loki-hovedtjenesten. For metadata-matching understøttes de samme tagging-regler som i Prometheus.
Distributør - service-distributør, der fungerer som en buffer. For at behandle millioner af poster pakker den indgående data og komprimerer dem i blokke, efterhånden som de ankommer. Flere datasink kører på samme tid, men logfiler, der tilhører den samme indgående datastrøm, bør kun ende i én af dem for alle dens blokke. Dette er organiseret som en ring af modtagere og sekventiel hashing. For fejltolerance og redundans gøres det n gange (3 hvis ikke konfigureret).
indtager — servicemodtager. Datablokke kommer komprimeret med tilføjede logfiler. Så snart blokken er af tilstrækkelig størrelse, skylles blokken til databasen. Metadataene går til indekset, og dataene fra logblokken går til Chunks (normalt objektlagring). Efter nulstillingen opretter modtageren en ny blok, hvor nye poster vil blive tilføjet.
Indeks - database, DynamoDB, Cassandra, Google BigTable og mere.
bidder - blokke af logfiler i komprimeret form, normalt gemt i objektlager, for eksempel S3.
Spørger er en læsesti, der gør alt det beskidte arbejde. Den ser på tidsintervallet og tidsstemplet og ser derefter på indekset for at lede efter matches. Dernæst læser den datablokke og filtrerer dem for at få resultatet.
Lad os nu se alt på arbejde.
Installation
Den nemmeste måde at installere på Kubernetes er at bruge ror. Vi antager, at du allerede har installeret og konfigureret det ( ca. oversætter)
Vi tilføjer et lager, og vi lægger en stak.
$ 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=falseNedenfor er et eksempel på et dashboard, der viser data fra Prometheus for Etcd og Loki metrics for Etcd pod logs.
Og lad os nu diskutere arkitekturen af begge systemer, samt sammenligne deres muligheder med hinanden.
sammenligning
Forespørgselssprog
Elasticsearch bruger Query DSL og Lucene forespørgselssprog til at give fuld tekst søgefunktion. Det er en etableret kraftfuld søgemaskine med bred operatørsupport. Med den kan du søge efter kontekst og sortere efter relevans.
På den anden side af ringen er Lokis LogQL, en efterfølger til PromQL (Prometheus query language). Den bruger log-etiketter til at filtrere og vælge logdata. Det er muligt at bruge nogle operatorer og aritmetik som beskrevet , men med hensyn til muligheder halter det efter det elastiske sprog.
Da anmodninger i Loki er forbundet med etiketter, er de nemme at korrelere med metrikker, som følge heraf er det lettere at organisere operationel overvågning med dem.
Skalerbarhed
Begge stakke er vandret skalerbare, men med Loki er det nemmere, fordi det har separate læse- og skrivestier, og det har en mikroservicearkitektur. Loki kan tilpasses til dine behov og kan bruges til meget store mængder logdata.
Multi lejemål
Cluster multi-tenancy er et fælles tema for OPEX-reduktion, begge stakke giver multi-tenancy. Der er flere til Elasticsearch kundeadskillelse: separat indeks pr. kunde, kundebaseret routing, kunde unikke felter, søgefiltre. Loke har som HTTP X-Scope-OrgID-header.
Omkostninger
Loki er meget omkostningseffektiv på grund af det faktum, at den ikke indekserer data, kun metadata. Dermed, og hukommelse (cache), da objektlagring er billigere end bloklagring, som bruges i Elasticsearch-klynger.
Konklusion
EFK-stakken kan bruges til en række forskellige formål, hvilket giver maksimal fleksibilitet og en rig Kibana-grænseflade til analyser, visualisering og forespørgsler. Det kan forbedres yderligere med maskinlæringsfunktioner.
Loki-stakken er nyttig i Kubernetes-økosystemet på grund af metadataopdagelsesmekanismen. Du kan nemt korrelere data til overvågning baseret på tidsserier i Grafana og logfiler.
Når det kommer til omkostninger og langsigtet logopbevaring, er Loki et glimrende valg til at komme ind i skyen.
Der er flere alternativer på markedet – nogle kan være bedre for dig. For eksempel har GKE en Stackdriver-integration, der giver en fantastisk overvågningsløsning. Vi har ikke inkluderet dem i vores analyse i denne artikel.
referencer:
Artiklen er oversat og udarbejdet til Habr af medarbejdere — intensive, videokurser og virksomhedstræning fra praktikere (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Kilde: www.habr.com