Loki - versamel logs met die Prometheus-benadering

Salueer, Khabroviete! In afwagting van die begin van 'n nuwe inskrywing vir die kursus "DevOps-praktyke en gereedskap" het vir jou 'n vertaling van interessante materiaal voorberei.

Hierdie artikel is 'n kort inleiding tot Loki. Projek Loki ondersteun deur Grafana en is gemik op gesentraliseerde versameling van logs (van bedieners of houers).

Die hoofinspirasie vir Loki was Prometheus met die idee om sy benaderings tot logbestuur toe te pas:

  • gebruik van etikette om data te stoor
  • lae hulpbronverbruik

Ons sal terugkeer na die beginsels van Prometheus en 'n paar voorbeelde gee van die gebruik daarvan in die konteks van Kubernetes.

'n Paar woorde oor Prometheus

Om ten volle te verstaan ​​hoe Loki werk, is dit belangrik om 'n tree terug te neem en Prometheus 'n bietjie te herbesoek.

Een van die onderskeidende kenmerke van Prometheus is die onttrekking van metrieke vanaf versamelpunte (via uitvoerders) en berging daarvan in 'n TSDB (Time Series Data Base, tydreeksdatabasis) met die byvoeging van metadata in die vorm van etikette.

Waarom is dit nodig?

Onlangs het Prometheus die de facto-standaard in die wêreld van houers en Kubernetes geword: die installasie daarvan is baie eenvoudig, en 'n Kubernetes-kluster het aanvanklik 'n eindpunt vir Prometheus. Prometheus kan ook statistieke onttrek uit toepassings wat in 'n houer ontplooi is, terwyl spesifieke etikette gehandhaaf word. Daarom is toepassingsmonitering baie maklik om te implementeer.

Ongelukkig is daar steeds geen sleuteloplossing vir logbestuur nie, en jy moet vir jouself 'n oplossing vind:

  • bestuurde wolkdiens vir die sentralisering van logs (AWS, Azure of Google)
  • moniteringdiens "monitering as 'n diens" (byvoorbeeld Datadog)
  • skep jou eie loginsamelingsdiens.

Vir die derde opsie het ek tradisioneel Elasticsearch gebruik, ondanks die feit dat ek nie altyd tevrede was daarmee nie (veral die swaar en kompleksiteit van die opstelling daarvan).

Loki is ontwerp om maklik te implementeer volgens die volgende beginsels:

  • maklik wees om te begin
  • min hulpbronne verbruik
  • werk onafhanklik sonder enige spesiale onderhoud
  • dien as 'n byvoeging tot Prometheus om te help met foutondersoeke

Hierdie eenvoud kom egter ten koste van sommige kompromieë. Een daarvan is om nie die inhoud te indekseer nie. Tekssoektog is dus nie baie doeltreffend of ryk nie en laat jou nie toe om statistieke oor die inhoud van die teks te hou nie. Maar aangesien Loki die grep-ekwivalent en aanvulling tot Prometheus wil wees, is dit nie 'n nadeel nie.

Insident ondersoek

Om beter te verstaan ​​hoekom Loki nie indeksering nodig het nie, kom ons gaan terug na die voorvalondersoekmetode wat deur die Loki-ontwikkelaars gebruik is:

Loki - versamel logs met die Prometheus-benadering
1 Waarskuwing → 2 Dashboard → 3 Adhoc-navraag → 4 Logsamestelling → 5 Verspreide opsporing → 6 Maak reg!
(1 Waarskuwing → 2 Dashboard → 3 Adhoc-navraag → 4 Log-samestelling → 5 Verspreide opsporing → 6 Regmaak!)

Die idee is dat ons 'n soort waarskuwing kry (Slack Notification, SMS, ens.) en daarna:

  • kyk na Grafana-dashboards
  • kyk na diensmaatstawwe (byvoorbeeld in Prometheus)
  • kyk na loginskrywings (byvoorbeeld in Elasticsearch)
  • kyk miskien na verspreide spore (Jaeger, Zipkin, ens.)
  • en uiteindelik die oorspronklike probleem reg te stel.

Hier, in die geval van die Grafana + Prometheus + Elasticsearch + Zipkin-stapel, sal jy vier verskillende gereedskap moet gebruik. Om tyd te bespaar, sal dit lekker wees om al hierdie stappe met een hulpmiddel te kan doen: Grafana. Dit is opmerklik dat hierdie benadering tot navorsing sedert weergawe 6 in Grafana geïmplementeer is. Dit word dus moontlik om direk vanaf Grafana toegang tot Prometheus-data te verkry.

Loki - versamel logs met die Prometheus-benadering
Explorer-skerm verdeel tussen Prometheus en Loki

Vanaf hierdie skerm kan jy logs in Loki sien wat verband hou met Prometheus-statistieke deur die gesplete skerm-konsep te gebruik. Sedert weergawe 6.5 laat Grafana jou toe om die spoor-ID in Loki-loginskrywings te ontleed om skakels na jou gunsteling verspreide opsporingsinstrumente (Jaeger) te volg.

Loki plaaslike toets

Die maklikste manier om Loki plaaslik te toets, is om docker-compose te gebruik. Die docker-compose-lêer is in die Loki-bewaarplek geleë. U kan die bewaarplek kry met die volgende opdrag git:

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

Dan moet jy na die produksiegids verander:

$ cd production

Daarna kan u die nuutste Docker-beelde kry:

$ docker-compose pull

Uiteindelik word die Loki-stapel begin met die volgende opdrag:

$ docker-compose up

Loki argitektuur

Hier is 'n klein diagram met Loki-argitektuur:

Loki - versamel logs met die Prometheus-benadering
Loki-argitektuurbeginsels

Die webkliënt laat toepassings op die bediener loop, Promtail versamel logs en stuur dit na Loki, die webkliënt stuur ook metadata na Loki. Loki versamel alles en gee dit aan Grafana deur.
Loki hardloop. Om die beskikbare komponente te sien, voer die volgende opdrag uit:

$ docker ps

In die geval van 'n vars geïnstalleerde Docker, moet die opdrag die volgende uitvoer terugstuur:

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

Ons sien die volgende komponente:

  • Promtail: agent verantwoordelik vir die sentralisering van logs
  • Grafana: die bekende dashboard-instrument
  • Loki: datasentralisasie daemon

As deel van 'n klassieke infrastruktuur (byvoorbeeld gebaseer op virtuele masjiene), moet die Promtail-agent op elke masjien ontplooi word. Grafana en Loki kan op dieselfde masjien geïnstalleer word.

Ontplooiing na Kubernetes

Die installering van Loki-komponente in Kubernetes sal soos volg wees:

  • daemonSet om die Promtail-agent op elk van die masjiene in die bedienerkluster te ontplooi
  • Loki-ontplooiing
  • en die laaste een is die ontplooiing van Grafana.

Gelukkig is Loki beskikbaar as 'n Helm-pakket, wat dit maklik maak om te ontplooi.

Installasie via Heml

Jy behoort reeds Heml geïnstalleer te hê. Dit kan afgelaai word vanaf die projek se GitHub-bewaarplek. Dit word geïnstalleer deur die argief wat geskik is vir jou argitektuur te onttrek en stuur by te voeg $PATH.

Let wel: weergawe 3.0.0 van Helm is onlangs vrygestel. Aangesien daar baie veranderinge daarin was, word die leser aangeraai om 'n bietjie te wag voordat hy dit begin gebruik..

Voeg bron by vir Helm

Die eerste stap is om die "loki"-bewaarplek by te voeg met die volgende opdrag:

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

Daarna kan jy soek vir pakkette met die naam "loki":

$ helm search loki

Gevolg:

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...

Hierdie pakkette het die volgende kenmerke:

  • die pakket loki/loki pas net by die Loki-bediener
  • die pakket loki/fluent-bit laat jou toe om DaemonSet te ontplooi met behulp van fluent-bin om logs in plaas van Promtail te versamel
  • die pakket loki/promtail bevat 'n loginsamelingsagent
  • die pakket loki/loki-stapel, laat jou toe om Loki onmiddellik saam met Promtail te ontplooi.

Installeer Loki

Om Loki na Kubernetes te ontplooi, voer die volgende opdrag in die "monitering"-naamruimte uit:

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

Om op skyf te stoor, voeg die opsie by --set loki.persistence.enabled = true:

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

Let wel: as jy Grafana terselfdertyd wil ontplooi, voeg dan die parameter by --set grafana.enabled = true

Wanneer jy hierdie opdrag uitvoer, behoort jy die volgende uitvoer te kry:

LAST DEPLOYED: Tue Nov 19 15:56:54 2019
NAMESPACE: monitoring
STATUS: DEPLOYED
RESOURCES:
==> v1/ClusterRole
NAME AGE
loki-promtail-clusterrole 189d
…
NOTES:
The Loki stack has been deployed to your cluster. Loki can now be added as a datasource in Grafana.
See <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> for more details.

As ons na die toestand van die peule in die "monitering"-naamruimte kyk, kan ons sien dat alles ontplooi is:

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

Gevolg:

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

Alle peule loop. Nou is dit tyd om 'n paar toetse te doen!

Koppel aan Grafana

Om met Grafana onder Kubernetes te koppel, moet jy 'n tonnel na sy peul oopmaak. Die volgende is die opdrag om poort 3000 oop te maak vir 'n Grafana-peul:

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

Nog 'n belangrike punt is die behoefte om die Grafana-administrateurwagwoord te herstel. Die wagwoord word geheim gehou loki-grafana in die veld .data.admin-user in base64-formaat.

Om dit te herstel, moet jy die volgende opdrag uitvoer:

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

Gebruik hierdie wagwoord in samewerking met die verstek administrateur rekening (admin).

Loki-databrondefinisie in Grafana

Maak eerstens seker dat die Loki-databron (konfigurasie / databron) geskep is.
Hier is 'n voorbeeld:

Loki - versamel logs met die Prometheus-benadering
'n Voorbeeld van die opstel van 'n databron vir Loki

Deur op "Toets" te klik, kan jy die verbinding met Loki toets.

Om versoeke aan Loki te rig

Gaan nou na Grafana en gaan na die "Verken"-afdeling. Wanneer hy logs van houers ontvang, voeg Loki metadata van Kubernetes by. Dit word dus moontlik om die logs van 'n spesifieke houer te sien.

Byvoorbeeld, om promtail houer logs te kies, kan jy die volgende navraag gebruik: {container_name = "promtail"}.
Moenie vergeet om die Loki-databron ook hier te kies nie.

Hierdie navraag sal houeraktiwiteit soos volg terugstuur:

Loki - versamel logs met die Prometheus-benadering
Navraagresultaat in Grafana

Voeg by die dashboard

Vanaf Grafana 6.4 is dit moontlik om loginligting direk op die dashboard te plaas. Daarna sal die gebruiker vinnig kan wissel tussen die aantal versoeke op sy webwerf na toepassingspore.

Hieronder is 'n voorbeeld dashboard wat hierdie interaksie implementeer:

Loki - versamel logs met die Prometheus-benadering
Voorbeeld dashboard met Prometheus-statistieke en Loki-logboeke

Die toekoms van Loki

Ek het Loki in Mei/Junie met weergawe 0.1 begin gebruik. Weergawe 1 is reeds vandag vrygestel, en selfs 1.1 en 1.2.

Daar moet erken word dat weergawe 0.1 nie stabiel genoeg was nie. Maar 0.3 het reeds werklike tekens van volwassenheid getoon, en die volgende weergawes (0.4, toe 1.0) het hierdie indruk net versterk.

Na 1.0.0 kan niemand 'n verskoning hê om nie hierdie wonderlike hulpmiddel te gebruik nie.

Verdere verbeterings moet nie oor Loki gaan nie, maar eerder die integrasie daarvan met die uitstekende Grafana. Trouens, Grafana 6.4 het reeds goeie integrasie met dashboards.

Grafana 6.5, wat onlangs vrygestel is, verbeter hierdie integrasie verder deur outomaties die inhoud van logs in JSON-formaat te herken.

Die video hieronder toon 'n klein voorbeeld van hierdie meganisme:

Loki - versamel logs met die Prometheus-benadering
Gebruik Loki-stringe wat in Grafana weergegee word

Dit word moontlik om een ​​van die JSON-velde te gebruik, byvoorbeeld om:

  • skakels na 'n eksterne hulpmiddel
  • loginhoudfiltrering

Byvoorbeeld, jy kan op traceId klik om na Zipkin of Jaeger te gaan.

Soos gewoonlik, sien ons uit na jou kommentaar en nooi jou uit om oop webinar, waar ons sal praat oor hoe die DevOps-industrie gedurende 2019 ontwikkel het en moontlike ontwikkelingspaaie vir 2020 bespreek.

Bron: will.com