Loki — mbledhja e logeve duke përdorur qasjen e Prometheus

Përshëndetje, lexues të Habr! Në prag të nisjes së grupit të ri për kursin «Praktikat dhe mjetet DevOps» kemi përgatitur për ju një përkthim të një materiali interesant.

Ky artikull është një hyrje e shkurtër në Loki. Projekti Loki mbështetet nga Grafana dhe është i orientuar drejt mbledhjes së centralizuar të logeve (nga serverët ose kontejnerët).

Burimi kryesor i frymëzimit për Loki ishte Prometheus me idenë e zbatimit të qasjeve të tij në menaxhimin e logeve:

• përdorimi i etiketave (labels) për ruajtjen e të dhënave
• konsum i ulët i burimeve

Do t’u rikthehemi ende parimeve të funksionimit të Prometheus dhe do të sjellim disa shembuj të përdorimit të tij në kontekstin e Kubernetes.

Disa fjalë për Prometheus

Për ta kuptuar plotësisht se si funksionon Loki, është e rëndësishme të bëjmë një hap pas dhe të kujtojmë shkurtimisht Prometheus.

Një nga karakteristikat dalluese të Prometheus është mbledhja e metrikave nga pikat e grumbullimit (përmes exporterëve) dhe ruajtja e tyre në TSDB (Time Series Data Base, bazë e të dhënave të serive kohore) me shtimin e metadatave në formën e etiketave.

Pse është e nevojshme kjo?

Kohët e fundit, Prometheus është bërë standard de facto në botën e kontejnerëve dhe Kubernetes: instalimi i tij është shumë i thjeshtë, ndërsa në një klaster Kubernetes ekziston që në fillim një endpoint për Prometheus. Prometheus gjithashtu mund të mbledhë metrika nga aplikacionet e vendosura në kontejner, duke ruajtur njëkohësisht etiketa të caktuara. Prandaj, monitorimi i aplikacioneve është shumë i lehtë për t’u zbatuar.

Fatkeqësisht, për menaxhimin e logeve ende nuk ka një zgjidhje “çelës në dorë”, ndaj duhet të gjeni vetë zgjidhjen e duhur:

• shërbim cloud i menaxhuar për centralizimin e logeve (AWS, Azure ose Google)
• shërbim monitorimi «monitorim si shërbim» (monitoring as a service) (për shembull, Datadog)
• krijimi i shërbimit tuaj për mbledhjen e logeve.

Për opsionin e tretë, tradicionalisht kam përdorur Elasticsearch, megjithëse jo gjithmonë kam qenë i kënaqur me të (sidomos për shkak të peshës së tij dhe kompleksitetit të konfigurimit).

Loki është projektuar për të thjeshtuar zbatimin sipas parimeve të mëposhtme:

• të jetë i thjeshtë për t’u nisur
• të konsumojë pak burime
• të funksionojë në mënyrë të pavarur pa ndonjë mirëmbajtje të veçantë
• të shërbejë si plotësues i Prometheus për të ndihmuar në hetimin e bug-eve

Megjithatë, kjo thjeshtësi arrihet me disa kompromise. Njëri prej tyre është mungesa e indeksimit të përmbajtjes. Prandaj, kërkimi në tekst nuk është shumë efikas ose i pasur dhe nuk lejon mbledhjen e statistikave mbi përmbajtjen e tekstit. Por, duke qenë se Loki synon të jetë ekuivalenti i grep dhe një plotësim për Prometheus, kjo nuk konsiderohet mangësi.

Hetimi i incidenteve

Për të kuptuar më mirë pse Loki nuk ka nevojë për indeksim, le të kthehemi te metoda e hetimit të incidenteve që përdorën zhvilluesit e Loki:

1 Alert → 2 Dashboard → 3 Adhoc Query → 4 Log Aggregation → 5 Distributed Tracing → 6 Fix!
(1 Alarm → 2 Dashboard → 3 Adhoc Query → 4 Agregimi i logeve → 5 Gjurmim i shpërndarë → 6 E rregullojmë!)

Ideja është që marrim një alarm të caktuar (Slack Notification, SMS etj.) dhe më pas:

• shohim dashboard-et e Grafana
• shohim metrikat e shërbimeve (për shembull, në Prometheus)
• shohim hyrjet e logeve (për shembull, në Elasticsearch)
• ndoshta hedhim një sy te gjurmimet e shpërndara (Jaeger, Zipkin etj.)
• dhe, në fund, rregullojmë problemin fillestar.

Këtu, në rastin e stack-ut Grafana + Prometheus + Elasticsearch + Zipkin, do të duhet të përdoren katër mjete të ndryshme. Për të shkurtuar kohën, do të ishte mirë të kishim mundësinë t’i kryenim të gjitha këto hapa me një mjet të vetëm: Grafana. Vlen të theksohet se kjo qasje ndaj hetimit është zbatuar në Grafana që nga versioni 6. Kështu, bëhet e mundur qasja te të dhënat e Prometheus drejtpërdrejt nga Grafana.

Ekrani Explorer është i ndarë mes Prometheus dhe Loki

Në këtë ekran mund të shikoni loget në Loki të lidhura me metrikat e Prometheus, duke përdorur konceptin e ndarjes së ekranit. Duke filluar nga versioni 6.5, Grafana lejon përpunimin e identifikuesit të gjurmimit (trace id) në hyrjet e logeve të Loki për të ndjekur lidhjet drejt mjeteve tuaja të preferuara të gjurmimit të shpërndarë (Jaeger).

Testim lokal i Loki

Mënyra më e thjeshtë për të testuar Loki në nivel lokal është përdorimi i docker-compose. Skedari docker-compose ndodhet në depozitorin e Loki. Depozitorin mund ta merrni me komandën e mëposhtme git:

$ git clone https://github.com/grafana/loki.git

Më pas duhet të kaloni në direktorinë production:

$ cd production

Pas kësaj, mund të shkarkoni versionin më të fundit të imazheve Docker:

$ docker-compose pull

Së fundi, stack-u Loki niset me komandën e mëposhtme:

$ docker-compose up

Arkitektura e Loki

Ja një diagramë e vogël me arkitekturën e Loki:

Parimet e arkitekturës së Loki

Klienti web ekzekuton aplikacionet në server, Promtail mbledh log-et dhe i dërgon në Loki, ndërsa klienti web dërgon gjithashtu metadata në Loki. Loki i agregon të gjitha dhe i kalon në Grafana.
Loki është nisur. Për të parë komponentët e disponueshëm, ekzekutoni komandën e mëposhtme:

$ docker ps

Në rastin e një instalimi të ri të Docker, komanda duhet të kthejë rezultatin e mëposhtëm:

IMAGE               PORTS                  NAMES
grafana/promtail:                          production_promtail_1
grafana/grafana: m  0.0.0.0:3000->3000/tcp production_grafana_1
grafana/loki: late  80/tcp,0.0.0.0:3100... production_loki_1

Shohim komponentët e mëposhtëm:

• Promtail: agjent përgjegjës për centralizimin e log-eve
• Grafana: një mjet i njohur për dashboard-e
• Loki: shërbim për centralizimin e të dhënave

Në një infrastrukturë klasike (për shembull, të bazuar në makina virtuale), agjenti Promtail duhet të vendoset në çdo makinë. Grafana dhe Loki mund të instalohen në të njëjtën makinë.

Vendosja në Kubernetes

Instalimi i komponentëve të Loki në Kubernetes do të përbëhet nga sa vijon:

• DaemonSet për vendosjen e agjentit Promtail në secilën nga makinat e klasterit të serverëve
• vendosja (Deployment) e Loki
• dhe së fundi — vendosja e Grafana.

Për fat të mirë, Loki është i disponueshëm si paketë Helm, gjë që e thjeshton vendosjen e tij.

Instalimi përmes Helm

Helm duhet ta keni tashmë të instaluar. Mund të shkarkohet nga repository GitHub i projektit. Instalohet duke shpaketuar arkivin që i përshtatet arkitekturës suaj dhe duke shtuar helm në $PATH.

Vërejtje: Versioni 3.0.0 i Helm është publikuar së fundmi. Duke qenë se përfshin shumë ndryshime, lexuesit i rekomandohet të presë pak përpara se të fillojë ta përdorë.

Shtimi i burimit për Helm

Hapi i parë do të jetë shtimi i repository “loki” me ndihmën e komandës së mëposhtme:

$ helm add loki https://grafana.github.io/loki/charts

Pas kësaj, mund të kërkoni paketa me emrin “loki”:

$ helm search loki

Rezultati:

loki/loki       0.17.2 v0.4.0 Loki: like Prometheus, but for logs.
loki/loki-stack 0.19.1 v0.4.0 Loki: like Prometheus, but for logs.
loki/fluent-bit 0.0.2  v0.0.1 Uses fluent-bit Loki go plugin for...
loki/promtail   0.13.1 v0.4.0 Responsible for gathering logs and...

Këto paketa kanë funksionet e mëposhtme:

• paketën loki/loki i korrespondon vetëm serverit Loki
• paketën loki/fluent-bit ju lejon të vendosni një DaemonSet, duke përdorur fluent-bin për mbledhjen e log-eve në vend të Promtail
• paketën loki/promtail përmban agjentin për mbledhjen e skedarëve log
• paketën loki/loki-stack, ju lejon të vendosni menjëherë Loki së bashku me Promtail.

Instalimi i Loki

Për të vendosur Loki në Kubernetes, ekzekutoni komandën e mëposhtme në namespace “monitoring”:

$ helm upgrade --install loki loki/loki-stack --namespace monitoring

Për ta ruajtur në disk, shtoni parametrin --set loki.persistence.enabled = true:

$ helm upgrade --install loki loki/loki-stack 
              --namespace monitoring 
              --set loki.persistence.enabled=true

Vërejtje: nëse dëshironi të vendosni njëkohësisht edhe Grafana, atëherë shtoni parametrin --set grafana.enabled = true

Gjatë ekzekutimit të kësaj komande, duhet të merrni rezultatin e mëposhtëm:

E FUNDIT I VENDOSUR: Mar Nën 19 15:56:54 2019
HAPËSIRA E EMRAVE: monitoring
STATUSI: I VENDOSUR
BURIMET:
==> v1/ClusterRole
EMRI VJETËRSIA
loki-promtail-clusterrole 189d
…
SHËNIME:
Stack-u Loki është vendosur në cluster-in tuaj. Loki tani mund të shtohet si burim të dhënash në Grafana.
Shihni <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> për më shumë detaje.

Duke parë gjendjen e pod-eve në namespace “monitoring”, do të shohim se gjithçka është vendosur:

$ kubectl -n monitoring get pods -l release=loki

Rezultati:

NAME                 READY  STATUS   RESTARTS  AGE
loki-0               1/1    Running  0         147m
loki-promtail-9zjvc  1/1    Running  0         3h25m
loki-promtail-f6brf  1/1    Running  0         11h
loki-promtail-hdcj7  1/1    Running  0         3h23m
loki-promtail-jbqhc  1/1    Running  0         11h
loki-promtail-mj642  1/1    Running  0         62m
loki-promtail-nm64g  1/1    Running  0         24m

Të gjithë pod-et janë në punë. Tani është koha të bëjmë disa teste!

Lidhja me Grafana

Për t’u lidhur me Grafana në Kubernetes, duhet të hapni një tunel drejt pod-it të saj. Më poshtë është komanda për të hapur portin 3000 për pod-in e Grafana:

$ kubectl -n port-forward monitoring svc/loki-grafana 3000:80

Një tjetër pikë e rëndësishme është nevoja për të rikuperuar fjalëkalimin e administratorit të Grafana. Fjalëkalimi ruhet në secret-in loki-grafana në fushën .data.admin-user në formatin base64.

Për ta rikuperuar, duhet të ekzekutoni komandën e mëposhtme:

$ kubectl -n monitoring get secret loki-grafana 
 --template '{{index .data "admin-password" | base64decode}}'; echo

Përdoreni këtë fjalëkalim së bashku me llogarinë e parazgjedhur të administratorit (admin).

Përcaktimi i burimit të të dhënave Loki në Grafana

Së pari, sigurohuni që burimi i të dhënave Loki të jetë krijuar (Configuration / Datasource).
Ja një shembull:

Shembull i konfigurimit të burimit të të dhënave për Loki

Duke klikuar “Test”, mund të kontrolloni lidhjen me Loki.

Bërja e kërkesave në Loki

Tani shkoni në Grafana te seksioni “Explore”. Gjatë marrjes së log-eve nga kontejnerët, Loki shton metadata nga Kubernetes. Kështu, bëhet e mundur të shikohen log-et e një kontejneri të caktuar.

Për shembull, për të zgjedhur log-et e kontejnerit promtail, mund të përdorni kërkesën e mëposhtme: {container_name = "promtail"}.
Edhe këtu mos harroni të zgjidhni burimin e të dhënave Loki.

Kjo kërkesë do të kthejë aktivitetin e kontejnerëve në formën e mëposhtme:

Rezultati i kërkesës në Grafana

Shtimi në dashboard

Duke filluar nga Grafana 6.4, informacioni i log-eve mund të vendoset drejtpërdrejt në dashboard. Pas kësaj, përdoruesi do të mund të kalojë shpejt nga numri i kërkesave në faqen e tij te trace-et e aplikacionit.

Më poshtë është një shembull dashboard-i që realizon këtë ndërveprim:

Shembull paneli me metrika Prometheus dhe logje Loki

E ardhmja e Loki

Kam filluar të përdor Loki qysh në maj/qershor, që nga versioni 0.1. Sot tashmë është publikuar versioni 1, madje edhe 1.1 dhe 1.2.

Duhet pranuar se versioni 0.1 nuk ishte mjaftueshëm i qëndrueshëm. Por 0.3 tregoi tashmë shenja reale pjekurie, ndërsa versionet pasuese (0.4, pastaj 1.0) vetëm sa e përforcuan këtë përshtypje.

Pas 1.0.0, askush nuk ka më justifikim për të mos e përdorur këtë mjet të shkëlqyer.

Përmirësimet e mëtejshme duhet të lidhen jo aq me Loki-n, sa me integrimin e tij me Grafana-n e shkëlqyer. Në fakt, në Grafana 6.4 tashmë është shfaqur një integrim i mirë me dashboard-et.

Grafana 6.5, e cila u publikua së fundmi, e përmirëson edhe më tej këtë integrim duke njohur automatikisht përmbajtjen e logjeve në format JSON.

Më poshtë, në video, është dhënë një shembull i vogël i këtij mekanizmi:

Përdorimi i rreshtave të Loki të shfaqur në Grafana

Bëhet e mundur përdorimi i një prej fushave JSON, për shembull, për:

• lidhje drejt një mjeti të jashtëm
• filtrimin e përmbajtjes së logjeve

Për shembull, mund të klikoni mbi traceId për të kaluar te Zipkin ose Jaeger.

Si zakonisht, presim komentet tuaja dhe ju ftojmë në webinarin e hapur, ku do të flasim për mënyrën si u zhvillua industria DevOps gjatë vitit 2019 dhe do të diskutojmë rrugët e mundshme të zhvillimit për vitin 2020.

Burimi: habr.com