Monitorimi është bërë një komponent shumë i rëndësishëm i zgjidhjeve të rritura cloud me rritjen e kompleksitetit të sistemeve të shpërndara. Ai është i nevojshëm për të kuptuar sjelljen e tyre. Nevojiten 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ë të performancës, demostrimin e gabimeve, disponueshmërinë dhe regjistrat.
Këto mjete gjithashtu duhet të jenë efikase dhe të shkallëzuara. Në këtë artikull ne do të shqyrtojmë dy stakët e njohura të teknologjisë: EFK (Elasticsearch) dhe PLG (Loki) dhe do t'i analizojmë arkitekturat dhe dallimet e tyre.
Staku EFK
Mund të keni dëgjuar tashmë për ELK ose EFK, të dyja janë staka popullore që përbëhen nga disa pjesë të veçanta: Elasticsearch (depo objektesh), Logstash ose FluentD (mbledhja dhe agregimi i regjistrave) dhe Kibana për vizualizimin.
Një skemë tipike e veprimit duket kështu:
Elasticsearch â njĂ« depo objektesh e shpĂ«rndarĂ« me kĂ«rkim dhe analytic nĂ« kohĂ« reale. NjĂ« zgjidhje e shkĂ«lqyer pĂ«r tĂ« dhĂ«na gjysmĂ« tĂ« strukturuara, siç janĂ« regjistrat. Informacioni ruhet nĂ« formĂ«n e dokumenteve JSON, indikohet nĂ« kohĂ« reale dhe shpĂ«rndahet nĂ« nyjet e klasterit. PĂ«rdoret njĂ« indeks i kthyer qĂ« pĂ«rmban tĂ« gjitha fjalĂ«t unike dhe dokumentet e lidhura me to pĂ«r kĂ«rkimin me tekst tĂ« plotĂ«, i cili bazohet nĂ« motorin e kĂ«rkimit Apache Lucene.
FluentD â Ă«shtĂ« njĂ« mbledhĂ«s tĂ« dhĂ«nash qĂ« kryen unifikimin e tĂ« dhĂ«nave gjatĂ« mbledhjes dhe konsumit. Ai pĂ«rpiqet tĂ« renditĂ« tĂ« dhĂ«nat nĂ« JSON sa mĂ« shumĂ« qĂ« tĂ« jetĂ« e mundur. Arkitektura e tij Ă«shtĂ« e shkallĂ«zueshme, ka mĂ« shumĂ« se , tĂ« mbĂ«shtetura nga komuniteti, pĂ«r çdo rast.
Kibana â njĂ« mjet vizualizimi tĂ« dhĂ«nash pĂ«r Elasticsearch me veçori tĂ« ndryshme shtesĂ«, si analiza e serive temporale, grafikĂ«t, mĂ«simi automat, dhe tĂ« tjera.
Arkitektura e Elasticsearch
TĂ« dhĂ«nat e klasterit Elasticsearch ruhen tĂ« shpĂ«rndara nĂ« tĂ« gjitha nyjet e tij. Klasteri pĂ«rbĂ«het nga disa nyje pĂ«r tĂ« pĂ«rmirĂ«suar disponueshmĂ«rinĂ« dhe qĂ«ndrueshmĂ«rinĂ«. Ădo nyje mund tĂ« kryejĂ« tĂ« gjitha rolet e klasterit, por nĂ« shpĂ«rndarjet e mĂ«dha tĂ« shkallĂ«zuara, nyjeve zakonisht u caktohen detyra tĂ« veçanta.
Llojet e nyjeve të klasterit:
- nyja master â menaxhon klasterin, janĂ« tĂ« nevojshme tĂ« paktĂ«n tre, njĂ«ra Ă«shtĂ« gjithmonĂ« aktive;
- nyja e dhĂ«nave â ruan tĂ« dhĂ«na tĂ« indeksuara dhe kryen detyra tĂ« ndryshme me to;
- node i ngrënies - organizon kanalet për konvertimin e të dhënave para indeksimit;
- node koordinues - rute kërkesash, reduktim i fazës së përpunimit të kërkimeve, koordinimi i indeksimit masiv;
- node alarmimi - nisja e detyrave për njoftim;
- node mësimi makinerik - përpunimi i detyrave të mësimit makinerik.
Në diagramin më poshtë tregohet si ruhet dhe riprodhohet të dhënat në nodet për arritjen e një disponibiliteti më të lartë të të dhënave.
Të dhënat e çdo replike ruhen në indeksin e inverzituar, diagrami më poshtë tregon si ndodh kjo:
Instalimi
Detajet mund të shihen , do të përdor helm chart:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsSteka PLG
Nuk është e çuditshme nëse nuk e gjeni këtë akronim, pasi njihet më shumë si Grafana Loki. Në çdo rast, ky stek po fiton popullaritet, pasi aplikon zgjidhje teknike të matur. Mund të keni dëgjuar tashmë për Grafana, mjetin popullor për vizualizimin e të dhënave. Krijuesit e saj, duke u frymëzuar nga Prometheus, zhvilluan Loki, një sistem aggregimi logësh me performancë të lartë, të shkallëzueshëm horizontalisht. Loki indekson vetëm metadat, por jo logët vetë, kjo zgjidhje teknike e bëri atë të lehtë për t'u përdorur dhe ekonomik.
Promtail - agjent për dërgimin e logëve nga sistemi operativ në klasterin Loki. Nëse tashmë e dini se çfarë është analiza e grupeve dhe se si ta bëni në SQL, kaloni menjëherë në seksionin e fundit. - mjet vizualizimi bazuar në të dhënat nga Loki.
Loki është ndërtuar mbi të njëjtin parim si Prometheus, prandaj i përshtatet mirë ruajtjes dhe analizës së logëve Kubernetes.
Arkitektura e Loki
Loki mund të ekzekutohet si në mënyrën e një procesi, ashtu edhe në formën e disa proceseve, që siguron shkallëzim horizontal.
Ai gjithashtu mund të funksionojë, si një aplikacion monolit, ashtu edhe si një mikroshërbim. Ekzekutimi në formën e një procesi mund të jetë i dobishëm për zhvillimin lokal ose për monitorim të vogël. Për zbatimin industrial dhe ngarkesën e shkallëzueshme, rekomandohet të përdoret varianti i mikroshërbimit. Rrugët e regjistrimit dhe të leximit të të dhënave janë të ndara, kështu që mund të konfigurohet dhe të shkallëzohet mjaft saktë sipas nevojës.
Le të shohim arkitekturën e sistemit të mbledhjes së logëve pa detaje:
Dhe këtu - përshkrimi (arkitektura mikroshërbimit):
Komponentët:
Promtail â agent, i instaluar nĂ« nyje (si njĂ« grup shĂ«rbimesh), ai nxjerr loge nga detyrat dhe i drejtohet API-sĂ« Kubernetes pĂ«r tĂ« marrĂ« metadatat, me tĂ« cilat do tĂ« etiketohen loget. MĂ« pas ai dĂ«rgon logun nĂ« shĂ«rbimin kryesor Loki. PĂ«r pĂ«rputhjen e metadataset, mbahen tĂ« njĂ«jtat rregulla pĂ«r etiketimin si nĂ« Prometheus.
Distributor â shĂ«rbim shpĂ«rndarĂ«s qĂ« funksionon si njĂ« tampon. PĂ«r tĂ« pĂ«rpunuar miliona regjistrime, ai paket loget e ardhshme, duke i ngjeshur ato nĂ« blloqe sipas radhĂ«s. NjĂ«kohĂ«sisht punojnĂ« disa marrĂ«s tĂ« tĂ« dhĂ«nave, por loget qĂ« i pĂ«rkasin njĂ« rrjedhe tĂ« vetme tĂ« tĂ« dhĂ«nave duhet tĂ« gjenden vetĂ«m nĂ« njĂ« prej tyre pĂ«r tĂ« gjithĂ« blloqet e tij. Kjo organizohet nĂ« formĂ«n e njĂ« unazĂ« marrĂ«sish dhe heshitjes sekondare. PĂ«r qĂ«ndrueshmĂ«ri dhe tepĂ«rsi, bĂ«het n herĂ« (3, nĂ«se nuk konfigurohen ndryshe).
Ingester â shĂ«rbim marrĂ«s. Blloqet e tĂ« dhĂ«nave vijnĂ« tĂ« ngjeshura me loget e shtuar. Sa herĂ« qĂ« blloku arrin njĂ« madhĂ«si tĂ« mjaftueshme, ai shkarkohet nĂ« bazĂ«n e tĂ« dhĂ«nave. Metadat mbajnĂ« indekse, ndĂ«rsa tĂ« dhĂ«nat nga blloku me log mbĂ«rrijnĂ« nĂ« Chunks (zakonisht kjo Ă«shtĂ« njĂ« ruajtje objektuale). Pas shkarkimit, marrĂ«si krijon njĂ« bllok tĂ« ri, ku do tĂ« shtohen regjistrimet e reja.
Index â bazĂ« tĂ« dhĂ«nash, DynamoDB, Cassandra, Google BigTable dhe tĂ« tjera.
Chunks â blloqe logesh nĂ« formĂ« tĂ« ngjeshur, zakonisht ruhen nĂ« ruajtje objektuale, pĂ«r shembull, S3.
Querier â rruga e leximit qĂ« bĂ«n gjithĂ« punĂ«n e zezĂ«. Ai shqyrton intervalin e kohĂ«s dhe etiketat, mĂ« pas shqyrton indekset pĂ«r tĂ« gjetur pĂ«rputhje. MĂ« pas lexon blloqet e tĂ« dhĂ«nave dhe i filtrojnĂ« ato pĂ«r tĂ« marrĂ« njĂ« rezultat.
Tani le të shohim gjithçka në veprim.
Instalimi
Për të instaluar në Kubernetes, është më e lehtë të përdorim helm. Supozojmë se ju tashmë e keni vendosur dhe konfiguruar ( shën. e përkthyesit)
Shtojmë repozitorin dhe vendosim stek.
$ 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 i një paneli të instrumenteve, ku janë të dhënat nga Prometheus për metrikat Etcd dhe Loki për loget e podave Etcd.
Tani le të diskutojmë arkitekturën e të dyve, si dhe të krahasojmë mundësitë e tyre me njëra-tjetrën.
Krahasimi
Gjuha e pyetjeve
Në Elasticsearch përdoret Query DSL dhe Lucene query language, të cilat sigurojnë mundësinë e kërkimit me tekst të plotë. Ky është një motor kërkimi i fuqishëm i konsoliduar me mbështetje të gjerë për operatorë. Me ndihmën e tij, mund të kërkoni në kontekst dhe të renditni sipas relevancës.
Në anën tjetër të ringut është LogQL, i aplikuar në Loki, pasardhësi i PromQL (Prometheus query language). Ai përdor etiketat e log-eve për të filtruar dhe marrë të dhënat e log-eve. Ka mundësi të përdoren disa operatorë dhe aritmetikë, siç përshkruhet , por në mundësi ai mbetet pas gjuhës Elastic.
Duke qenë se kërkesat në Loki lidhen me etiketat, ato janë të lehta për t'u lidhur me metrikat, si rezultat është më e lehtë të organizoni monitorimin operativ me to.
Shkallëzueshmëria
Të dy stekët janë horizontalisht të shkallëzueshëm, por me Loki është më e thjeshtë, pasi ka rrugë të ndara për leximin dhe shkruan të dhënat, si dhe ka një arkitekturë mikroshërbimesh. Loki mund të konfigurohet sipas karakteristikave tuaja dhe mund të përdoret për volume shumë të mëdha të të dhënave të log-eve.
Multiaktorshmëria
Multiaktorshmëria e klasterit është një temë e zakonshme për uljen e OPEX, të dy stekët ofrojnë multiaktorshmëri. Për Elasticsearch ka disa për ndarjen e klientëve: një indeks të veçantë për çdo klient, rrugëzim bazuar në klientin, fusha unike të klientit, filtre kërkimi. Në Loki ka në formën e titullit HTTP X-Scope-OrgID.
Ămimi
Loki është shumë ekonomik për shkak se ai nuk bën indeksimin e të dhënave, por vetëm të metadatat. Në këtë mënyrë arrihet dhe memorje (cache), pasi ruajtja objektore është më e lirë se ajo blloku që përdoret në klasteret Elasticsearch.
PĂ«rfundim
Steka EFK mund të përdoret për qëllime të ndryshme, duke ofruar fleksibilitet maksimal dhe një ndërfaqe shumëfunksionale Kibana për analitikë, vizualizim dhe kërkesa. Ai mund të përmirësohet më tej me mundësitë e mësimit të makinerive.
Steka Loki është e dobishme në ekosistemin Kubernetes për shkak të mekanizmit të zbulimit të metadatat. Mund të lehtësojë përshtatjen e të dhënave për monitorimin e bazuar në seritë e kohës në Grafana dhe log-e.
Kur flitet për koston dhe ruajtjen afatgjatë të log-eve, Loki është një zgjedhje e shkëlqyer për hyrje në zgjidhjet në re.
NĂ« treg ka mĂ« shumĂ« alternativa â disa mund tĂ« jenĂ« mĂ« tĂ« mira pĂ«r ju. PĂ«r shembull, pĂ«r GKE ekziston integrimi me Stackdriver, i cili ofron njĂ« zgjidhje tĂ« shkĂ«lqyer pĂ«r monitorimin. Ne nuk i pĂ«rfshimĂ« ata nĂ« analizĂ«n tonĂ« nĂ« kĂ«tĂ« artikull.
Lidhjet:
Artikulli Ă«shtĂ« pĂ«rkthyer dhe pĂ«rgatitur pĂ«r Habr nga punonjĂ«sit â intensiva, video-kurse dhe trajnime korporative nga specialistĂ« praktikĂ« (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Burimi: habr.com
