Monitorimi Ă«shtĂ« bĂ«rĂ« njĂ« komponent shumĂ« i rĂ«ndĂ«sishĂ«m i zgjidhjeve tĂ« rritura cloud, pĂ«r shkak tĂ« 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Ă« ofrojnĂ« njĂ« ndĂ«rfaqe tĂ« vetme pĂ«r specialistĂ«t, me analizĂ« tĂ« performancĂ«s, tregimin e gabimeve, disponibilitetin dhe regjistrat.
Këto mjete duhet të jenë efikase dhe performuese. Në këtë artikull ne do të shqyrtojmë dy grupe të njohura teknologjish: EFK (Elasticsearch) dhe PLG (Loki) dhe do të analizojmë arkitekturën dhe dallimet e tyre.
Grupi EFK
Mund të keni dëgjuar tashmë për EFK ose ELK, një grup që përbëhet nga disa pjesë të veçuara: Elasticsearch (ruajtje objekti), Logstash ose FluentD (mbledhje dhe agregim regjistrash) dhe Kibana për vizualizimin.
Një skemë tipike e punës duket kështu:
Elasticsearch â njĂ« ruajtje e shpĂ«rndarĂ« objektesh me kĂ«rkimin dhe analizĂ«n nĂ« kohĂ« reale. NjĂ« zgjidhje e shkĂ«lqyer pĂ«r tĂ« dhĂ«nat pjesĂ«risht tĂ« strukturuara, siç janĂ« regjistrat. Informacioni ruhet nĂ« formatin e dokumenteve JSON, indeksohet nĂ« kohĂ« reale dhe shpĂ«rndahet nĂ« nyjet e grumbullit. PĂ«rdoret njĂ« indeks i kthyer, qĂ« pĂ«rmban tĂ« gjitha fjalĂ«t unike dhe dokumentet e lidhura pĂ«r kĂ«rkimin e plotĂ«, qĂ« nga ana e tij mbĂ«shtetet nĂ« motorin e kĂ«rkimit Apache Lucene.
FluentD â Ă«shtĂ« njĂ« mblodhĂ«s tĂ« dhĂ«nash, qĂ« realizon unifikimin e tĂ« dhĂ«nave gjatĂ« mbledhjes dhe konsumit. Ai pĂ«rpiqet tĂ« rregullojĂ« tĂ« dhĂ«nat nĂ« JSON sa mĂ« shumĂ« qĂ« tĂ« jetĂ« e mundur. Arkitektura e tij Ă«shtĂ« e zgjerueshme, me mĂ« shumĂ« , tĂ« mbĂ«shtetura nga komuniteti, pĂ«r çdo rast tĂ« jetĂ«s.
Kibana â njĂ« mjet vizualizimi tĂ« dhĂ«nash pĂ«r Elasticsearch me funksionalitete tĂ« ndryshme shtesĂ«, si analizimi i serive tĂ« kohĂ«s, grafĂ«t, mĂ«simi makinerik dhe mĂ« shumĂ«.
Arkitektura e Elasticsearch
TĂ« dhĂ«nat e grumbullit Elasticsearch ruhen tĂ« shpĂ«rndara nĂ« tĂ« gjitha nyjet e tij. Grumbulli 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 grumbullit, por nĂ« instalimet e mĂ«dha dhe tĂ« shkallĂ«zuara, nyjeve zakonisht u caktohen detyra tĂ« veçanta.
Llojet e nyjeve të grumbullit:
- nyja master â menaxhon grumbullin, nevojiten tĂ« paktĂ«n tri, njĂ«ra gjithmonĂ« Ă«shtĂ« aktive;
- nyja e tĂ« dhĂ«nave â ruan tĂ« dhĂ«nat e indekseve dhe kryen detyra tĂ« ndryshme me to;
- nyja e ingest-it â organizon kantieret pĂ«r transformimin e tĂ« dhĂ«nave para indeksimit;
- nyja koordinuese â rregullon kĂ«rkesat, shkurtimin e fazĂ«s sĂ« pĂ«rpunimit tĂ« kĂ«rkimit, koordinimin e indeksimit nĂ« masĂ«;
- nyja e alertimit â nis detyrat e njoftimit;
- nyja e mĂ«simit makinerik â pĂ«rpunon detyrat e mĂ«simit makinerik.
Në diagramin më poshtë ilustrohet se si ruhet dhe riprodhohet informacioni nëpër nyje për të arritur një disponueshmëri më të lartë të të dhënave.
Të dhënat e çdo replike ruhen në indeksin e kthyer, diagrami më poshtë tregon se si ndodh kjo:
Instalimi
Mund të shikoni detajet , do të përdor helm chart:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsGrupi PLG
Mos u habitni nëse nuk mund ta gjeni këtë akronim, sepse njihet më shumë si Grafana Loki. Në çdo rast, ky grup po fiton popullaritet, pasi aplikon zgjidhje teknike të sakta. Ndoshta keni dëgjuar tashmë për Grafana, një mjet të njohur për vizualizim. Krijuesit e saj, duke u frymëzuar nga Prometheus, zhvilluan Loki, një sistem agregimi regjistrash me shkallëzim horizontal dhe performancë të lartë. Loki indekson vetëm metadata, por jo regjistrat e vetë, kjo zgjidhje teknike e bëri të lehtë në shpërndarje dhe të efektshme nga pikëpamja ekonomike.
Promtail â agjent pĂ«r dĂ«rgimin e regjistrave nga sistemi operativ nĂ« grumbullin Loki. Grafana â njĂ« mjet vizualizimi i bazuar nĂ« tĂ« dhĂ«nat nga Loki.
Loki është ndërtuar mbi të njëjtat parime si Prometheus, ndaj ai përshtatet mirë për ruajtjen dhe analizimin e regjistrave Kubernetes.
Arkitektura e Loki
Loki mund të funksionojë si një proces i vetëm, ashtu edhe si disa procese, që siguron shkallëzim horizontal.
Ai gjithashtu mund të funksionojë, si një aplikacion monolitik, ashtu edhe si një mikrosërvici. Aktivizimi në formën e një procesi të vetëm mund të jetë i dobishëm për zhvillim lokal ose monitorim të vogël. Për përgatitjen industriale dhe ngarkesën e shkallëzueshme, rekomandohet të përdoret forma e mikrosërvicit. Rrugët e të dhënave të shkruara dhe lexuara janë të ndara, kështu që mund të konfigurohet mjaft ndjeshëm dhe të shkallëzohet sipas nevojës.
Le të hedhim një sy në arkitekturën e sistemit të mbledhjes së regjistrave pa detaje:
Dhe këtu është përshkrimi (arkitektura mikrosërvice):
Komponentet:
Promtail â agenti i instaluar nĂ« nyje (nĂ« formĂ«n e njĂ« grupi shĂ«rbimesh), merr regjistrat nga detyrat dhe pĂ«rdor API-nĂ« Kubernetes pĂ«r tĂ« marrĂ« metadatĂ«n qĂ« do tĂ« shoqĂ«rojnĂ« regjistrat. MĂ« pas, ai dĂ«rgon regjistrin nĂ« shĂ«rbimin kryesor Loki. Rregullat e etiketimit pĂ«r metadatĂ«n mbĂ«shtesin tĂ« njĂ«jtat rregulla si nĂ« Prometheus.
Distributor â shĂ«rbimi shpĂ«rndarĂ«s, qĂ« punon si njĂ« tampon. PĂ«r tĂ« pĂ«rpunuar miliona regjistrime, ai paketason tĂ« dhĂ«nat nĂ« hyrje, duke i komprimuar ato nĂ« blloqe ndĂ«rsa arrijnĂ«. Disa pranues tĂ« tĂ« dhĂ«nave punojnĂ« njĂ«kohĂ«sisht, por regjistrat qĂ« i pĂ«rkasin njĂ« rryme tĂ« vetme hyrjeje duhet tĂ« ndodhen vetĂ«m nĂ« njĂ« prej tyre pĂ«r tĂ« gjitha blloqet e tij. Kjo organizohet si njĂ« unazĂ« pranuesish dhe heshim tĂ« rregullt. PĂ«r qĂ«ndrueshmĂ«ri dhe tepĂ«rsi, bĂ«het n herĂ« (3, nĂ«se nuk konfigurohet ndryshe).
Ingester â shĂ«rbimi pranues. Blloqet e tĂ« dhĂ«nave vijnĂ« tĂ« kompresuara me regjistrat e pĂ«rfshirĂ«. Sapo blloku tĂ« arrijĂ« njĂ« madhĂ«si tĂ« mjaftueshme, ai derdhet nĂ« bazĂ«n e tĂ« dhĂ«nave. Metadatet shkojnĂ« nĂ« indeks, dhe tĂ« dhĂ«nat e bllokut me regjistrat kalojnĂ« nĂ« Chunks (zakonisht kjo Ă«shtĂ« njĂ« ruajtje objektuale). Pasi tĂ« derdhet, pranuesi krijon njĂ« bllok tĂ« ri, ku do tĂ« shtohen regjistrime tĂ« reja.
Index â baza e tĂ« dhĂ«nave, DynamoDB, Cassandra, Google BigTable dhe tĂ« tjerĂ«.
Chunks â blloqet e regjistrave nĂ« formĂ« tĂ« kompresuar, tĂ« ruajtura zakonisht nĂ« ruajtje objektuale, si S3.
Querier â rruga e leximit qĂ« bĂ«n gjithĂ« punĂ«n e zezĂ«. Ai shqyrton intervalin e kohĂ«s dhe etiketat, pastaj shikon indeksin pĂ«r tĂ« gjetur pĂ«rputhje. MĂ« pas lexon blloqet e tĂ« dhĂ«nave dhe i filtron ato pĂ«r tĂ« marrĂ« rezultatin.
Tani le të shohim gjithçka në punë.
Instalimi
Për të instaluar në Kubernetes, është më e lehtë të përdorni helm. Supozojmë se tashmë e keni instaluar dhe konfiguruar ( shënim i përkthyesit)
Shtoni depozita dhe instaloni 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ë gjeni një shembull të tabelës së instrumenteve, ku janë shfaqur të dhënat nga Prometheus për metrikat Etcd dhe Loki për regjistrat e pod-eve Etcd.
Tani le të diskutojmë arkitekturën e të dy sistemeve dhe të krahasojmë capability e tyre me njëri-tjetrin.
Krahasimi
Gjuha e pyetjeve
Në Elasticsearch përdoret Query DSL dhe gjuha e pyetjeve Lucene, të cilat ofrojnë mundësinë e kërkimit me tekst të plotë. Ky është një motor kërkimi i fuqishëm me mbështetje të gjerë për operatorët. Me të, mund të kërkosh për kontekste dhe të renditësh sipas relevancës.
Në anën tjetër të ringut është LogQL, e përdorur në Loki, pasardhësi i PromQL (gjuha e pyetjeve Prometheus). Ai përdor etiketat e regjistrave për të filtruar dhe nxjerrë të dhëna nga regjistrat. Ka mundësi për të përdorur disa operatorë dhe aritmetikë, siç përshkruhet , por në mundësi mbetet prapa gjuhës Elastic.
Duke qenĂ« se pyetjet nĂ« Loki janĂ« tĂ« lidhura me etiketat â ato janĂ« tĂ« lehta pĂ«r t'u pĂ«rputhur me metrikat, duke rezultuar mĂ« tĂ« lehta pĂ«r tĂ« organizuar monitorimin operativ.
Shkallëzueshmëria
Të dy stekat janë horizontalisht të shkallëzueshme, por me Loki është më e lehtë, pasi ai ka rrugë të ndara për të lexuar dhe shkruar të dhëna, si dhe një arkitekturë mikroshërbimesh. Loki mund të konfigurohet për karakteristikat tuaja dhe mund të përdoret për volume shumë të mëdha të regjistrave.
Multi-rezidentës
Multi-rezidentës e klasterit është një temë e zakonshme për të reduktuar OPEX, të dy stekat ofrojnë multi-rezidentës. Për Elasticsearch ka disa për ndarjen e klientëve: një indeks i veçantë për secilin klient, ruter në bazë të klientit, fusha të veçanta për klientin, filtrat e kërkimit. Në Loki ka në formën e titullit HTTP X-Scope-OrgID.
Ămimi
Loki është shumë efikas ekonomikisht për shkak se ai nuk bën indeksimin e të dhënave, vetëm të metadatat. Kështu arrihet dhe memorie (cache), pasi ruajtja objektuale është më e lirë se ajo bllokore e përdorur në klasteret Elasticsearch.
PĂ«rfundimi
Steku EFK mund të përdoret për qëllime të ndryshme, duke ofruar fleksibilitet maksimal dhe një ndërfaqe multifunksionale Kibana për analitikë, vizualizim dhe pyetje. Ai mund të përmirësohet më tej me mundësitë e mësimit të makinerive.
Steku Loki është i dobishëm në ekosistemin Kubernetes për shkak të mekanizmit të zbuluarjes së metadatat. Mund të përputhen lehtësisht të dhënat për monitorimin në bazë të serive kohore në Grafana dhe regjistrat.
Kur bëhet fjalë për kostot dhe ruajtjen afatgjatë të regjistrave, Loki është një zgjedhje e shkëlqyer për hyrjen në zgjidhjet cloud.
NĂ« treg ka mĂ« shumĂ« alternativa â disa mund tĂ« jenĂ« mĂ« tĂ« mira pĂ«r ju. PĂ«r shembull, pĂ«r GKE ka integrimin Stackdriver, i cili ofron njĂ« zgjidhje tĂ« shkĂ«lqyer pĂ«r monitorim. Ne nuk i pĂ«rfshim ato nĂ« analizĂ«n tonĂ« nĂ« kĂ«tĂ« artikull.
Linket:
Artikulli Ă«shtĂ« pĂ«rkthyer dhe pĂ«rgatitur pĂ«r Habr nga punonjĂ«sit â intensiva, videokurse dhe trajnim korporativ nga profesionistĂ« praktikĂ« (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Burimi: habr.com
