Ne Badoo, ne monitorojmĂ« vazhdimisht teknologjitĂ« e reja dhe vlerĂ«sojmĂ« nĂ«se ia vlen t'i pĂ«rdorim ato nĂ« sistemin tonĂ«. NjĂ« nga kĂ«to studime do tĂ« duam tĂ« ndajmĂ« me komunitetin. Ky Ă«shtĂ« pĂ«r Loki â sistemin e agregimit tĂ« logĂ«ve.
Loki Ă«shtĂ« njĂ« zgjidhje pĂ«r ruajtjen dhe shikimin e logĂ«ve, gjithashtu ky grumbull ofron njĂ« sistem fleksibĂ«l pĂ«r analizĂ«n e tyre dhe dĂ«rgimin e tĂ« dhĂ«nave nĂ« Prometheus. NĂ« maj u lĂ«shua pĂ«rditĂ«simi i fundit, i cili Ă«shtĂ« promovuar aktivisht nga krijuesit. Na interesoi se çfarĂ« mund tĂ« bĂ«jĂ« Loki, cilat mundĂ«si ofron dhe nĂ« çfarĂ« mase mund tĂ« shĂ«rbejĂ« si alternativĂ« ndaj ELK â grumbullit qĂ« po pĂ«rdorim tani.
ĂfarĂ« Ă«shtĂ« Loki
Grafana Loki Ă«shtĂ« njĂ« koleksion komponentĂ«sh pĂ«r njĂ« sistem tĂ« plotĂ« punimi me logĂ«. Ndryshe nga sistemet e tjera tĂ« ngjashme, Loki bazohet nĂ« idenĂ« pĂ«r tĂ« indeksuar vetĂ«m metadatĂ«n e logĂ«ve â etiketat (ashtu si nĂ« Prometheus), ndĂ«rsa logĂ«t vetĂ« kompresohen pranĂ« nĂ« pjesĂ« tĂ« veçanta.
,
Para se të kaloj në përshkrimin e asaj që mund të bëhet me ndihmën e Loki, dua të sqaroj se çfarë nënkuptohet me "idenë për të indeksuar vetëm metadatën". Le të krahasojmë qasjen e Loki dhe qasjen ndaj indeksimit në zgjidhjet tradicionale, si Elasticsearch, duke marrë si shembull një varg nga logu nginx:
172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"Sistemet tradicionale analizohet e gjithë vargu, duke përfshirë fushat me shumë vlera unike user_id dhe item_id, dhe ruajnë gjithçka në indekse të mëdha. Avantazhi i këtij qasjeje është se mund të kryhen kërkesa komplekse shpejt, pasi pothuajse të dhënat janë në indeks. Por për këtë duhen paguar kostot e shpërthimit të indeksit, dhe si rezultat kërkohet më shumë memorie. Në fund, indeksi i plotë i logëve është i barabartë me madhësinë e logëve vetë. Për të kërkuar shpejt në të, indeksi duhet të ngarkohet në memorie. Dhe sa më shumë logë, aq më shpejt rritet indeksi dhe aq më shumë memorie konsumon.
Princi Loki kërkon që nga stringu të nxirren vetëm të dhënat e nevojshme, numri i të cilave është i vogël. Në këtë mënyrë, krijojmë një indeks të vogël dhe mund të kërkojmë të dhëna duke i filtruar ato sipas kohës dhe fushave të indeksuara, pastaj skanojmë të mbeturat me shprehi të rregullta ose kërkime të nënstringjeve. Procesi duket se nuk është nga më të shpejtët, por Loki e ndan kërkesën në disa pjesë dhe i ekzekuton ato paralelisht, duke procesuar një sasi të madhe të dhënash në një kohë të shkurtër. Numri i shardeve dhe kërkesave paralel në to është konfigurues; kështu, sasia e të dhënave që mund të procesohen në një njësi kohe varet linearisht nga sasia e burimeve të ofruara.
Ky kompromis midis një indeksi të madh dhe të shpejtë dhe një indeksi të vogël me një përmbledhje të plotë paralele lejon Loki të kontrollojë kostot e sistemit. Ajo mund të konfigurohet dhe zgjerohet në mënyrë fleksibile sipas nevojave.
Staku Loki përbëhet nga tre komponentë: Promtail, Loki, Grafana. Promtail mbledh log-et, i përpunon dhe i dërgon në Loki. Loki i ruan ato. Grafana mund të kërkojë të dhëna nga Loki dhe t'i shfaqë ato. Në përgjithësi, Loki mund të përdoret jo vetëm për ruajtjen e log-eve dhe kërkimin në to. E gjithë staku ofron mundësi të mëdha për përpunimin dhe analizimin e të dhënave në ardhje, duke përdorur mënyrën Prometheus.
Përshkrimi i procesit të instalimit mund të gjendet .
Kërkimi në log-e
KĂ«rkimi nĂ« log-e mund tĂ« bĂ«het nĂ« njĂ« ndĂ«rfaqe speciale Grafana â Explorer. PĂ«r kĂ«rkesat pĂ«rdoret gjuha LogQL, e cila Ă«shtĂ« shumĂ« e ngjashme me PromQL, e cila pĂ«rdoret nĂ« Prometheus. NĂ« parim, mund tĂ« konsiderohet si njĂ« grep i shpĂ«rndarĂ«.
Ndërfaqja e kërkimit duket kështu:
KĂ«rkesa pĂ«rbĂ«het nga dy pjesĂ«: selector dhe filter. Selector â Ă«shtĂ« kĂ«rkimi sipas metadatave tĂ« indeksuara (etiketave) qĂ« i janĂ« caktuar log-eve, dhe filter â Ă«shtĂ« stringu i kĂ«rkimit ose reg-exp, me anĂ« tĂ« tĂ« cilit filtrohen rekordet e pĂ«rcaktuara nga selector-i. NĂ« shembullin e dhĂ«nĂ«: NĂ« kllapat e mĂ«dha â selector, gjithçka pas â filter.
{image_name="nginx.promtail.test"} |= "index"Për shkak të parimit të punës së Loki-t, nuk mund të bëhen kërkesa pa selector, por etiketat mund të bëhen aq të gjera sa të dëshirosh.
Selector është një çift çelës-vlerë në kllapë të madhe. Mund të kombinohen selectorë dhe të vendosen kushte të ndryshme kërkimi, duke përdorur operatorët =, != ose shprehi të rregullta:
{instance=~"kafka-[23]",name!="kafka-dev"}
// Gjenfind logg med merkelappen instance, som har verdiene kafka-2, kafka-3, og utelater dev Filteret er en tekst eller regex som filtrerer ut alle dataene som hentes av velgeren.
Det er mulig Ä hente ad-hoc-grafer basert pÄ de mottatte dataene i metrics-modus. For eksempel kan man finne frekvensen av oppfÞrsel i nginx-loggene som inneholder strengen index:
En fullstendig beskrivelse av funksjonene finnes i dokumentasjonen .
Parsing av logger
Det finnes flere mÄter Ä samle logger pÄ:
- Ved hjelp av Promtail, en standardkomponent i stakken for loggsamling.
- Direkte fra Docker-beholderen med
- Bruke Fluentd eller Fluent Bit, som kan sende data til Loki. I motsetning til Promtail har de ferdige parsere for nesten alle typer logger og hÄndterer ogsÄ multiline-logger.
Vanligvis brukes Promtail til parsing. Den gjĂžr tre ting:
- Den finner datakilder.
- Den knytter merkelapper til dem.
- Den sender data til Loki.
Per nÄ kan Promtail lese logger fra lokale filer og fra systemd journal. Den mÄ installeres pÄ hver maskin som samler logger.
Det finnes integrasjon med Kubernetes: Promtail finner automatisk ut tilstanden til klyngen via Kubernetes REST API og samler logger fra noden, tjenesten eller podden, og legger merkelapper basert pÄ metadata fra Kubernetes (poddens navn, filnavn osv.).
Merkelapper kan ogsÄ legges til basert pÄ data fra loggen ved hjelp av Pipeline. En Promtail-pipeline kan bestÄ av fire typer faser. Mer detaljert kan leses i , her nevnes noen nuanser.
- Parsing-faser. Dette er RegEx og JSON-fase. PÄ dette stadiet trekker vi ut data fra loggene til det sÄkalte extracted map. Data kan hentes fra JSON ved simpelthen Ä kopiere Þnskede felt til extracted map, eller via regulÊre uttrykk (RegEx), hvor named groups mappes i extracted map. Extracted map fungerer som et key-value lager, der key er feltets navn, og value er verdien fra loggene.
- Transformasjonsfaser. Denne fasen har to alternativer: transform, der vi spesifiserer transformationsregler, og source â datakilden for transformasjonen fra extracted map. Hvis det ikke finnes et slikt felt i extracted map, opprettes det. Dermed kan merkelapper som ikke baseres pĂ„ extracted map, opprettes. PĂ„ dette stadiet kan vi manipulere dataene i extracted map ved Ă„ bruke en ganske kraftig . PĂ«r mĂ« tepĂ«r, duhet tĂ« mbani mend se harta e dalĂ« ngarkohet krejtĂ«sisht gjatĂ« analizĂ«s, qĂ« ofron mundĂ«sinĂ«, pĂ«r shembull, tĂ« kontrolloni vlerĂ«n nĂ« tĂ«: â{{if .tag}vlera e tagut ekziston{end}}â. Shabloni mbĂ«shtet kushte, cikle dhe disa funksione pĂ«r strings, si Replace dhe Trim.
- Fazat e veprimit. Në këtë fazë, mund të bëni diçka me të dhënat e nxjerra:
- Krijoni një etiketë nga të dhënat e nxjerra, e cila do të indeksohet në Loki.
- Ndryshoni ose vendosni kohën e ngjarjes nga logu.
- Ndryshoni të dhënat (tekstin e logs) që do të dërgohen në Loki.
- Krijoni metrika.
- Fazat e filtrimit. Faza e përputhjes, në të cilën mund të dërgoni në /dev/null regjistrimet që nuk na duhen, ose t'i dërgoni ato për përpunim të mëtejshëm.
Do ta ilustroj me një shembull të përpunimit të logs të zakonshme të nginx-it, si mund të analizoni logs me ndihmën e Promtail.
Për test, do të marrim si një nginx-proxy imazhin e modifikuar jwilder/nginx-proxy:alpine dhe një demon të vogël, i cili është i aftë të pyet veten me HTTP. Demonit i janë caktuar disa endpoint-e, në të cilat mund të japë përgjigje me madhësi të ndryshme, me statuset e ndryshme të HTTP dhe me vonesa të ndryshme.
Do të mbledhim logs nga kontejnerët docker, të cilët mund të gjenden në rrugën /var/lib/docker/containers//-json.log
Në docker-compose.yml, konfigurojmë Promtail dhe tregojmë rrugën deri në konfiguracion:
promtail:
image: grafana/promtail:1.4.1
// ...
volumes:
- /var/lib/docker/containers:/var/lib/docker/containers:ro
- promtail-data:/var/lib/promtail/positions
- ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
command:
- '-config.file=/etc/promtail/promtail.yml'
// ...
ShtojmĂ« nĂ« promtail.yml rrugĂ«n deri nĂ« logs (nĂ« konfiguracion ka njĂ« opsion âdockerâ, i cili bĂ«n tĂ« njĂ«jtĂ«n gjĂ« njĂ« rresht, por do tĂ« ishte mĂ« pak e qartĂ«):
scrape_configs:
- job_name: containers
static_configs:
labels:
job: containerlogs
__path__: /var/lib/docker/containers/*/*log # vetĂ«m pĂ«r linuxDuke aktivizuar njĂ« konfigurim tĂ« tillĂ«, logs nga tĂ« gjithĂ« kontejnerĂ«t do tĂ« mbĂ«rrijnĂ« nĂ« Loki. PĂ«r tĂ« evituar kĂ«tĂ«, ndryshojmĂ« cilĂ«simet e nginx-it test nĂ« docker-compose.yml â shtojmĂ« fushĂ«n e logimit tĂ« tagut:
proxy:
image: nginx.test.v3
//âŠ
logging:
driver: "json-file"
options:
tag: "{{.ImageName}}|{{.Name}}"Rregullojmë promtail.yml dhe konfigurojmë Pipeline. Në hyrje mbërrijnë logs të këtij lloji:
{"log":"u001b[0;33;1mnginx.1 | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] \"GET /api/index HTTP/1.1\" 200 0 \"-\" \"Stub_Bot/0.1\" \"0.096\"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1 | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] \"GET /200 HTTP/1.1\" 200 0 \"-\" \"Stub_Bot/0.1\" \"0.000\"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}Faza e pipeline:
- json:
expressions:
stream: stream
attrs: attrs
tag: attrs.tagNxjerrim nga fusha stream e JSON-it hyrës, attrs, attrs.tag (nëse ato ekzistojnë) dhe i vendosim ato në hartën e ekstraktuar.
- regex:
shprehja: ^(?P([^|]+))|(?P([^|]+))$
burimi: "tag"Nëse arritëm të vendosim fushën tag në hartën e ekstraktuar, atëherë me anë të regex-it nxjerrim emrat e imazhit dhe kontejnerit.
- etiketa:
emri_i_imazhit:
emri_i_kontejnerit:Caktojmë etiketat. Nëse në të dhënat e ekstraktuara do të zbuloheshin çelësat emri_i_imazhit dhe emri_i_kontejnerit, atëherë vlerat e tyre do të atribuoheshin etiketave përkatëse.
- përputhja:
selektori: '{job="docker",emri_i_kontejnerit="",emri_i_imazhit=""}'
veprimi: heqjeHeqim të gjitha log-et, ku nuk janë zbuluar etiketat e vendosura emri_i_imazhit dhe emri_i_kontejnerit.
- përputhja:
selektori: '{emri_i_imazhit="nginx.promtail.test"}'
fazat:
- json:
shprehje:
rresht: logPër të gjitha log-et, ku emri_i_imazhit është nginx.promtail.test, nxjerrim nga log-u burimor fushën log dhe e vendosim në hartën e ekstraktuar me çelësin rresht.
- regex:
# shtypi ngjyrat e forego
shprehja: .+nginx.+|.+[0m(?P[a-z_.-]+) +(?P.+)
burimi: logrowPastruam stringun hyrës me shprehje të zakonshme dhe nxorrëm nginx virtual host dhe stringun e log-ut nginx.
- regex:
burimi: nginxlog
shprehja: ^(?P[w.]+) - (?P[^ ]*) [(?P[^ ]+).*] "(?P[^ ]*) (?P[^ ]*) (?P[^ ]*)" (?P[d]+) (?P[d]+) "(?P[^"]*)" "(?P[^"]*)"( "(?P[d.]+)")?Parsing-ng ngin-log me shprehje të zakonshme.
- regex:
burimi: request_url
shprehja: ^.+.(?Pjpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
- regex:
burimi: request_url
shprehja: ^/photo/(?P[^/?.]+).*$
- regex:
burimi: request_url
shprehja: ^/api/(?P[^/?.]+).*Analizojmë request_url. Duke përdorur regex-in përcaktojmë qëllimin e kërkesës: për statikën, fotografitë, API dhe vendosim në hartën e ekstraktuar çelësin përkatës.
- template:
burimi: request_type
template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"Me anë të operatorëve të kushtit në Template kontrollojmë fushat e vendosura në hartën e ekstraktuar dhe caktojmë për fushën request_type vlerat e nevojshme: photo, static, API. Caktojmë other, nëse nuk arritëm. Tani request_type ka llojin e kërkesës.
- etiketat:
api_request:
virtual_host:
request_type:
status:Vendosim etiketat api_request, virtual_host, request_type dhe statusin (HTTP status) në bazë të asaj që arritëm të vendosim në hartën e ekstraktuar.
- output:
burimi: nginx_log_rowNdryshojmë output-in. Tani në Loki dërgohet nginx-log-u i pastruar nga harta e ekstraktuar.
Pas nisjes së konfiguratës së mësipërme, mund të shihet se çdo regjistrim është dhënë etiketat bazuar në të dhënat nga log-u.
Duhet tĂ« kihet parasysh se nxjerrja e etiketave me shumĂ« vlera (cardinality) mund tĂ« ngadalĂ«sojĂ« ndjeshĂ«m punĂ«n e Loki. Pra, nuk duhet tĂ« vendosni nĂ« indeks, pĂ«r shembull, user_id. MĂ« shumĂ« rreth kĂ«tij tema lexoni nĂ« artikullin ââ. Por kjo nuk do tĂ« thotĂ« se nuk mund tĂ« kĂ«rkoni pĂ«r user_id pa indekse. Duhet tĂ« pĂ«rdorni filtra gjatĂ« kĂ«rkimit (âgrepâ mbi tĂ« dhĂ«nat), dhe indeksi kĂ«tu vepron si identifikues i fluxit.
Vizualizimi i logëve
Loki mund të jetë një burim të dhënash për grafike Grafana, duke përdorur LogQL. Mbështeten funksionet e mëposhtme:
- rate â numri i regjistrimeve nĂ« sekondĂ«;
- count over time â numri i regjistrimeve nĂ« njĂ« interval tĂ« caktuar.
Gjithashtu, ka funksione agreguese si Sum, Avg dhe të tjera. Mund të krijoni grafika mjaft komplekse, për shembull, grafikun e numrit të gabimeve HTTP:
Burimi standard i tĂ« dhĂ«nave Loki Ă«shtĂ« disi mĂ« i kufizuar nĂ« funksionalitet krahasuar me burimin e tĂ« dhĂ«nave Prometheus (pĂ«r shembull, nuk mund tĂ« ndryshoni legjendĂ«n), por Loki mund tĂ« lidhet si burim me tipin Prometheus. Nuk jam i sigurt se ky Ă«shtĂ« njĂ« veprim i dokumentuar, por, sipas pĂ«rgjigjes sĂ« zhvilluesve ââ, pĂ«r shembull, kjo Ă«shtĂ« plotĂ«sisht e ligjshme, dhe Loki Ă«shtĂ« plotĂ«sisht nĂ« pĂ«rputhje me PromQL.
Shtojmë Loki si burim të dhënash me tipin Prometheus dhe shkruajmë URL /loki:
Dhe mund të krijojmë grafika, siç do të ishim duke punuar me metrika nga Prometheus:
Mendoj se përjashtimi në funksionalitet është përkohësor dhe zhvilluesit do ta korrigjojnë këtë në të ardhmen.
Metrikat
Në Loki është e mundur të nxjerrim metrika numerike nga logët dhe t'i dërgojmë ato në Prometheus. Për shembull, në logun e nginx ndodhet numri i byte-ve në përgjigje, si dhe, me një modifikim të caktuar të formatit standard të logut, koha në sekonda që u nevojit për përgjigjen. Këto të dhëna mund të nxirren dhe dërgohen në Prometheus.
Shtojmë një seksion tjetër në promtail.yml:
- match:
selector: '{request_type="api"}'
stages:
- metrics:
http_nginx_response_time:
type: Histogram
description: "koha e përgjigjes ms"
source: response_time
config:
buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
selector: '{request_type=~"static|photo"}'
stages:
- metrics:
http_nginx_response_bytes_sum:
type: Counter
description: "shuma e byte-ve të përgjigjes"
source: bytes_out
config:
action: add
http_nginx_response_bytes_count:
type: Counter
description: "numri i byte-ve të përgjigjes"
source: bytes_out
config:
action: incOpsioni lejon qĂ« tĂ« pĂ«rcaktoni dhe pĂ«rditĂ«soni metrikat nĂ« bazĂ« tĂ« tĂ« dhĂ«nave nga extracted map. KĂ«to metrika nuk dĂ«rgohen nĂ« Loki â ato shfaqen nĂ« Promtail /metrics endpoint. Prometheus duhet tĂ« konfigurohet nĂ« mĂ«nyrĂ« qĂ« tĂ« marrĂ« tĂ« dhĂ«nat e marra nĂ« kĂ«tĂ« fazĂ«. NĂ« shembullin e dhĂ«nĂ« pĂ«r request_type=âapiâ ne mbledhim metrikĂ«n histogramĂ«. Me kĂ«tĂ« lloj metrikash Ă«shtĂ« e lehtĂ« tĂ« merret percentili. PĂ«r statikĂ«n dhe fotot ne mbledhim shumĂ«n e bajtave dhe numrin e rreshtave, nĂ« tĂ« cilĂ«t kemi marrĂ« bajtat, pĂ«r tĂ« llogaritur mesataren.
Për më shumë detaje rreth metrikave, lexoni .
Hapim portin në Promtail:
promtail:
image: grafana/promtail:1.4.1
container_name: monitoring.promtail
expose:
- 9080
ports:
- "9080:9080"Sigurohemi që metrikat me parazgjedhje promtail_custom janë shfaqur:
Konfigurojmë Prometheus. Shtojmë punën promtail:
- job_name: 'promtail'
scrape_interval: 10s
static_configs:
- targets: ['promtail:9080']Dhe vizatojmë grafik:
Në këtë mënyrë mund të kuptojmë, për shembull, katër kërkesat më të ngadalta. Gjithashtu, për këto metrika mund të konfiguroni monitorimin.
Zgjerimi
Loki mund të jetë si në mënyrë të vetme (single binary mode), ashtu edhe në mënyrë të shpërndarë (horizontally-scalable mode). Në rastin e dytë, ai mund të ruajë të dhëna në cloud, kurse chunks dhe indekset ruhen veçmas. Në versionin 1.5 është zbatuar mundësia e ruajtjes në një vend, por akoma nuk rekomandohet përdorimi i saj në prodhim.
Chunks mund tĂ« ruhen nĂ« njĂ« depo S3-kompatibile, pĂ«r ruajtjen e indekseve â pĂ«rdoren baza tĂ« dhĂ«nash horizontalisht tĂ« shkallĂ«zuara: Cassandra, BigTable ose DynamoDB. PjesĂ«t e tjera tĂ« Loki â Distribuuesit (pĂ«r shkruarje) dhe KĂ«rkuesi (pĂ«r kĂ«rkesa) â janĂ« stateless dhe gjithashtu shkallĂ«zohen horizontalisht.
NĂ« konferencĂ«n DevOpsDays Vancouver 2019, njĂ« nga pjesĂ«marrĂ«sit, Callum Styan, shprehu se me Loki projekti i tij ka petabytes logĂ«sh me njĂ« indeks mĂ« pak se 1% tĂ« madhĂ«sisĂ« totale: ââ.
Krahasimi i Loki dhe ELK
Madhësia e indeksit
Për të testuar madhësinë e indeksit, kam marrë logët nga kontejneri nginx, për të cilin ishte konfiguruar Pipeline i përmendur më lart. Skedari me logët përmbante 406,624 rreshta me një vëllim të përgjithshëm prej 109 Mb. Logët u gjeneruan për një orë, rreth 100 regjistrime në sekondë.
Shembulli i dy rreshtave nga logu:
Në indeksonin ELK kjo përbëri madhësinë e indeksit 30.3 Mb:
NĂ« rastin e Loki, kjo dha rreth 128 KB indeks dhe rreth 3.8 MB tĂ« dhĂ«nash nĂ« blloqe. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se logu ishte gjeneruar nĂ« mĂ«nyrĂ« artificiale dhe nuk kishte shumĂ« ndryshueshmĂ«ri tĂ« tĂ« dhĂ«nave. Kompresimi i thjeshtĂ« gzip nĂ« logun origjinal JSON Docker me tĂ« dhĂ«nat jepte njĂ« kompresim prej 95.4%, dhe duke marrĂ« parasysh se nĂ« vetĂ« Loki dĂ«rgohej vetĂ«m logu i pastruar nginx, atĂ«herĂ« kompresimi deri nĂ« 4 MB Ă«shtĂ« i kuptueshĂ«m. Numri total i vlerave unike pĂ«r etiketat Loki ishte 35, qĂ« shpjegon madhĂ«sinĂ« e vogĂ«l tĂ« indeksit. PĂ«r ELK logu gjithashtu u pastrua. KĂ«shtu, Loki kompresoi tĂ« dhĂ«nat origjinale me 96%, ndĂ«rsa ELK me 70%.
Konsumimi i memorjes
NĂ«se e krahasojmĂ« tĂ« gjithĂ« stakun Prometheus dhe ELK, atĂ«herĂ« Loki "hĂ«ngĂ«r" disa herĂ« mĂ« pak. ĂshtĂ« e qartĂ« se shĂ«rbimi nĂ« Go konsumon mĂ« pak se shĂ«rbimi nĂ« Java, dhe krahasimi i madhĂ«sisĂ« sĂ« JVM Heap Elasticsearch dhe memorjes sĂ« dedikuar pĂ«r Loki Ă«shtĂ« i papĂ«rshtatshĂ«m, por megjithatĂ« Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se Loki pĂ«rdor shumĂ« mĂ« pak memorie. Avantazhi i tij nĂ« CPU nuk Ă«shtĂ« aq i dukshĂ«m, por gjithashtu Ă«shtĂ« prezent.
Shpejtësia
Loki ha logĂ«t mĂ« shpejt. ShpejtĂ«sia varet nga shumĂ« faktorĂ« â çfarĂ« lloji logĂ«sh kemi, sa sofisticuar i analizojmĂ« ata, rrjeti, disku etj. â por ajo Ă«shtĂ« padyshim mĂ« e lartĂ« se ELK (nĂ« testin tim â rreth dy herĂ«). Kjo shpjegohet me faktin se Loki vendos shumĂ« mĂ« pak tĂ« dhĂ«na nĂ« indeks dhe, pĂ«r rrjedhojĂ«, shpenzon mĂ« pak kohĂ« nĂ« indeksim. Me shpejtĂ«sinĂ« e kĂ«rkimit, situata Ă«shtĂ« e kundĂ«rta: Loki ngadalĂ«sohet ndjeshĂ«m nĂ« tĂ« dhĂ«na me madhĂ«si mbi disa gigabajt, ndĂ«rsa te ELK shpejtĂ«sia e kĂ«rkimit nuk varet nga madhĂ«sia e tĂ« dhĂ«nave.
Kërkimi në log-e
Loki e kalon ELK ndjeshĂ«m nĂ« mundĂ«sitĂ« e kĂ«rkimit tĂ« logĂ«ve. Grep me shprehje tĂ« rregullta Ă«shtĂ« njĂ« gjĂ« e fortĂ«, por ai i humbet njĂ« baze tĂ« dhĂ«nash tĂ« plotĂ«. Mungesa e kĂ«rkesave range, agregimi vetĂ«m sipas etiketave, pamundĂ«sia pĂ«r tĂ« kĂ«rkuar pa etiketa â tĂ« gjitha kĂ«to na kufizojnĂ« nĂ« gjetjen e informacionit tĂ« interesit nĂ« Loki. Kjo nuk nĂ«nkupton se me ndihmĂ«n e Loki nuk mund tĂ« gjendet asgjĂ«, por pĂ«rcakton flukset e punĂ«s me logĂ«t, kur pĂ«r herĂ« tĂ« parĂ« gjeni njĂ« problem nĂ« grafiket e Prometheus dhe mĂ« pas sipas kĂ«tyre etiketimeve kĂ«rkoni se çfarĂ« ndodhi nĂ« logĂ«t.
Ndërfaqja
Së pari, është e bukur (më falni, nuk mund të mbahesha). Grafana ka një ndërfaqe të këndshme për syrin, por Kibana është shumë më funksionale.
PĂ«rfitimet dhe disavantazhet e Loki
Një nga avantazhet është se Loki integrohet me Prometheus, duke siguruar që metrikat dhe alarmet i marrim direkt. Ai është i përshtatshëm për mbledhjen dhe ruajtjen e logeve nga Kubernetes Pods, pasi ka zbuluar shërbimin e trashëguar nga Prometheus dhe automatikisht ngjarkon etiketat.
Nga disavantazhet, dokumentacioni është i dobët. Disa gjëra, siç janë karakteristikat dhe funksionalitetet e Promtail, i zbulova vetëm gjatë studimit të kodit, mirë që është me burim të hapur. Një tjetër disavantazh është aftësitë e dobëta të përpunimit. Për shembull, Loki nuk mund të përpunojë loge shumëlinjëshe. Po ashtu, një nga mangësitë është se Loki është një teknologji relativisht e re (lëshimi 1.0 ka qenë në nëntor 2019).
PĂ«rfundim
Loki është një teknologji 100% interesante, e cila është e përshtatshme për projekte të vogla dhe të mesme, duke lejuar zgjidhjen e shumë problemeve të agregimit të logeve, kërkimin nëpër loge, monitorimin dhe analizën e logeve.
Ne nuk e përdorim Loki në Badoo, pasi kemi ELK-stack që na përshtatet dhe që për shumë vite ka evoluar me zgjidhje të ndryshme të personalizuara. Për ne, problemi kryesor është kërkimi nëpër loge. Me gati 100 GB loge në ditë, është e rëndësishme të jemi në gjendje të gjejmë gjithçka dhe pak më shumë. Për ndërtimin e grafikëve dhe monitorimit përdorim zgjidhje të tjera, të cilat janë të dizajnuara për nevojat tona dhe janë të integruara me njëra-tjetrën. Stack-u Loki ka disa përfitime të dukshme, por nuk do të na ofrojë më shumë se sa kemi, dhe avantazhet e tij sigurisht që nuk do të mbulojnë kostot e migrimit.
Edhe pse pas hetimit doli se ne nuk mund ta përdorim Loki, shpresojmë që ky postim do t'ju ndihmojë në zgjedhjen tuaj.
Repository me kodin e përdorur në artikull ndodhet .
Burimi: habr.com
