Monitorimi është bërë një komponent shumë i rëndësishëm i zgjidhjeve në rritje të cloud, ndërsa kompleksiteti i sistemeve të shpërndara rritet. Është e nevojshme të kuptohet sjellja e tyre. Ne kemi nevojë për mjete të shkallëzueshme që mund të mbledhin të dhëna nga të gjitha shërbimet - dhe t'u ofrojnë specialistëve një ndërfaqe të vetme me analizën e performancës, demonstrimin e gabimeve, disponueshmërinë dhe regjistrat.
Të njëjtat mjete duhet të jenë efikase dhe produktive. Në këtë artikull, ne do të shikojmë dy grupe teknologjike të njohura: EFK (Elasticsearch) dhe PLG (Loki) dhe do të shqyrtojmë arkitekturat dhe dallimet e tyre.
EFK pirg
Ju mund të keni dëgjuar tashmë për ELK ose EFK shumë të njohur. Stacki përbëhet nga disa pjesë të dallueshme: Elasticsearch (ruajtja e objekteve), Logstash ose FluentD (mbledhja dhe grumbullimi i regjistrave) dhe Kibana për vizualizim.
Një rrjedhë tipike e punës duket si kjo:
Elasticsearch — ruajtja e objekteve të shpërndara me kërkim dhe analitikë në kohë reale. Zgjidhje e shkëlqyer për të dhëna gjysmë të strukturuara si regjistrat. Informacioni ruhet si dokumente JSON, indeksohet në kohë reale dhe shpërndahet nëpër nyjet e grupimeve. Përdoret një indeks i përmbysur, që përmban të gjitha fjalët unike dhe dokumentet shoqëruese për kërkimin e tekstit të plotë, i cili nga ana tjetër bazohet në motorin e kërkimit Apache Lucene.
RrjedhshmeD është një grumbullues i të dhënave që unifikon të dhënat gjatë mbledhjes dhe konsumimit të tyre. Ai përpiqet të organizojë të dhënat në JSON sa më shumë që të jetë e mundur. Arkitektura e saj është e zgjerueshme, ka më shumë , i mbështetur nga komuniteti, për të gjitha rastet.
kibana - një mjet vizualizimi i të dhënave për Elasticsearch me aftësi të ndryshme shtesë, për shembull, analiza e serive kohore, analiza e grafikëve, mësimi i makinerive dhe më shumë.
Elasticsarch Arkitektura
Të dhënat e grupit të Elasticsearch ruhen të shpërndara në të gjitha nyjet e tij. Një grup përbëhet nga nyje të shumta për të përmirësuar disponueshmërinë dhe elasticitetin. Çdo nyje mund të kryejë të gjitha rolet e grupit, por në vendosjet në shkallë të gjerë, nyjeve zakonisht u caktohen detyra individuale.
Llojet e nyjeve të grupimit:
- nyja master - menaxhon grupin, nevojiten të paktën tre, njëri është gjithmonë aktiv;
- nyja e të dhënave - ruan të dhënat e indeksuara dhe kryen detyra të ndryshme me to;
- ingest node - organizon tubacionet për transformimin e të dhënave përpara indeksimit;
- koordinimi i nyjeve - kërkesa për rrugëzim, reduktimi i fazës së përpunimit të kërkimit, koordinimi i indeksimit masiv;
- nyja e alarmit - nisja e detyrave të alarmit;
- Nyja e mësimit të makinës - përpunimi i detyrave të mësimit të makinerive.
Diagrami më poshtë tregon se si të dhënat ruhen dhe përsëriten nëpër nyje për të arritur disponueshmëri më të lartë të të dhënave.
Të dhënat e secilës kopje ruhen në një indeks të përmbysur, diagrami më poshtë tregon se si ndodh kjo:
Instalim
Detajet mund të shihen , Unë do të përdor diagramin e timonit:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsStack PLG
Mos u çuditni nëse nuk mund ta gjeni këtë akronim, pasi njihet më shumë si Grafana Loki. Në çdo rast, kjo pirg po fiton popullaritet sepse përdor zgjidhje teknike të provuara. Ju mund të keni dëgjuar tashmë për Grafana, një mjet popullor vizualizimi. Krijuesit e tij, të frymëzuar nga Prometeu, zhvilluan Loki, një sistem grumbullimi i regjistrave me performancë të lartë të shkallëzuar horizontalisht. Loki indekson vetëm meta të dhënat, jo vetë revistat, një zgjidhje teknike që e lejon atë të jetë e lehtë për t'u përdorur dhe me kosto efektive.
Promtail - një agjent për dërgimin e regjistrave nga sistemi operativ në grupin Loki. grafana është një mjet vizualizimi i bazuar në të dhënat nga Loki.
Loki është ndërtuar mbi të njëjtat parime si Prometheus, duke e bërë atë të përshtatshëm për ruajtjen dhe analizimin e regjistrave të Kubernetes.
Arkitektura Loki
Loki mund të ekzekutohet ose si një proces i vetëm ose si procese të shumta, duke lejuar shkallëzim horizontal.
Mund të funksionojë gjithashtu si një aplikim monolit ose si një mikroshërbim. Drejtimi si një proces i vetëm mund të jetë i dobishëm për zhvillimin lokal ose për monitorime të vogla. Për zbatimin industrial dhe ngarkesën e shkallëzueshme të punës, rekomandohet përdorimi i opsionit të mikroservisit. Shtigjet për shkrimin dhe leximin e të dhënave janë të ndara, kështu që ato mund të sintonizohen mirë dhe të shkallëzohen sipas nevojës.
Le të shohim arkitekturën e sistemit të mbledhjes së regjistrave pa hyrë në detaje:
Dhe këtu është përshkrimi (arkitektura e mikroshërbimit):
Përbërësit:
Promtail — një agjent i instaluar në nyje (si një grup shërbimesh), ai heq regjistrat nga detyrat dhe hyn në API të Kubernetes për të marrë meta të dhëna që do të etiketojnë regjistrat. Më pas e dërgon regjistrin te shërbimi kryesor Loki. Hartimi i meta të dhënave mbështet të njëjtat rregulla etiketimi si Prometheus.
Shpërndarës — një shpërndarës shërbimi që punon si një bufer. Për të përpunuar miliona regjistrime, ai paketon të dhënat hyrëse, duke i ngjeshur ato në blloqe kur mbërrijnë. Disa rezerva të dhënash funksionojnë njëkohësisht, por regjistrat që i përkasin një rryme të dhënash hyrëse duhet të shfaqen vetëm në njërin prej tyre për të gjitha blloqet e tij. Kjo është e organizuar në një unazë lavamaniesh dhe hashimi vijues. Për tolerancën e gabimeve dhe tepricën, kjo bëhet n herë (3 nëse nuk është konfiguruar).
Ingester — marrësi i shërbimit. Blloqet e të dhënave mbërrijnë të ngjeshur me regjistrat e shtuar. Pasi blloku të ketë madhësi të mjaftueshme, blloku derdhet në bazën e të dhënave. Metadatat shkojnë në indeks dhe të dhënat nga blloku i regjistrit shkojnë te Chunks (zakonisht ruajtja e objekteve). Pas rivendosjes, marrësi krijon një bllok të ri ku do të shtohen hyrje të reja.
indeks - baza e të dhënave, DynamoDB, Cassandra, Google BigTable, etj.
Copa — blloqet e regjistrit në formë të ngjeshur, zakonisht të ruajtura në ruajtjen e objekteve, për shembull, S3.
Pyetës - rruga e leximit që bën të gjitha punët e pista. Ai shikon intervalin kohor dhe vulën kohore, dhe më pas shikon indeksin për të gjetur përputhje. Më pas, lexon blloqe të dhënash dhe i filtron për të marrë rezultatin.
Tani le të shohim gjithçka në veprim.
Instalim
Mënyra më e lehtë për të instaluar në Kubernetes është të përdorni timonin. Ne supozojmë se ju e keni instaluar dhe konfiguruar tashmë atë ( përafërsisht. përkthyes)
Shtoni një depo dhe instaloni një pirg.
$ 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=falseMë poshtë është një shembull pulti që tregon të dhëna nga Prometheus për metrikat Etcd dhe Loki për regjistrat e pod Etcd.
Tani le të diskutojmë arkitekturën e të dy sistemeve, dhe gjithashtu të krahasojmë aftësitë e tyre me njëri-tjetrin.
krahasim
Gjuha e pyetjes
Elasticsearch përdor Query DSL dhe gjuhën e pyetjeve Lucene për të ofruar aftësi kërkimi në tekst të plotë. Është një motor kërkimi i krijuar dhe i fuqishëm me mbështetje të gjerë operatori. Me të, ju mund të kërkoni sipas kontekstit dhe të renditni sipas rëndësisë.
Në anën tjetër të unazës është LogQL, e përdorur në Loki, pasardhësi i PromQL (Prometheus query language). Ai përdor etiketat e regjistrave për të filtruar dhe përzgjedhur të dhënat e regjistrit. Është e mundur të përdoren disa operatorë dhe aritmetikë siç përshkruhet , por për nga aftësitë mbetet pas gjuhës elastike.
Meqenëse pyetjet në Loki shoqërohen me etiketa, ato janë të lehta për t'u lidhur me metrikat dhe si rezultat, ato janë më të lehta për t'u organizuar monitorimi operacional.
Shkallëzueshmëria
Të dy grupet janë të shkallëzueshme horizontalisht, por Loki e bën më të lehtë sepse ka shtigje të veçanta leximi dhe shkrimi dhe një arkitekturë mikroshërbimi. Loki mund të personalizohet për t'iu përshtatur nevojave tuaja dhe mund të përdoret për vëllime shumë të mëdha të të dhënave log.
Shumëqiramarrja
Shumëqiramarrja e grupeve është një temë e zakonshme në shkurtesën OPEX, të dy raftet ofrojnë shumëqiramarrje. Ka disa për Elasticsearch ndarja e klientit: indeks i veçantë për secilin klient, rrugëzim i bazuar në klient, fusha unike të klientit, filtra kërkimi. Loki ka në formën e një titulli HTTP X-Scope-OrgID.
Kosto
Loki është mjaft me kosto efektive për faktin se nuk indekson të dhënat, por vetëm metadatat. Kjo arrin dhe memorie (cache), pasi ruajtja e objekteve është më e lirë se ruajtja e bllokut, e cila përdoret në grupimet Elasticsearch.
Përfundim
Stacki EFK mund të përdoret për një sërë qëllimesh, duke ofruar fleksibilitet maksimal dhe një ndërfaqe Kibana të pasur me veçori për analitikë, vizualizim dhe pyetje. Mund të përmirësohet më tej nga aftësitë e mësimit të makinerive.
Stacki Loki është i dobishëm në ekosistemin Kubernetes për shkak të mekanizmit të tij të zbulimit të meta të dhënave. Ju mund të lidhni lehtësisht të dhëna për monitorim bazuar në seritë kohore në Grafana dhe regjistrat.
Kur bëhet fjalë për koston dhe ruajtjen afatgjatë të regjistrave, Loki është një pikë e shkëlqyer hyrjeje në zgjidhjet cloud.
Ka më shumë alternativa në treg - disa mund të jenë më të mira për ju. Për shembull, GKE ka një integrim Stackdriver që ofron një zgjidhje të shkëlqyer monitorimi. Ne nuk i kemi përfshirë në analizën tonë në këtë artikull.
referencat:
Artikulli u përkthye dhe u përgatit për Habr nga punonjësit — Kurse intensive, kurse video dhe trajnime korporative nga specialistë praktikues (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Burimi: www.habr.com