Loki — logverzamelaar met een aanpak van Prometheus

Hallo, Habr-leden! In de aanloop naar de start van een nieuwe cursus «DevOps-praktijken en -tools» hebben we een vertaling van interessant materiaal voor jullie voorbereid.

Dit artikel is een korte inleiding tot Loki. Het Loki-project wordt ondersteund door Grafana en richt zich op gecentraliseerde logverzameling (van servers of containers).

De belangrijkste inspiratiebron voor Loki was Prometheus met het idee om zijn aanpak voor logbeheer toe te passen:

• gebruik van labels voor gegevensopslag
• weinig middelen verbruiken

We zullen later terugkomen op de principes van Prometheus en enkele voorbeelden geven van zijn gebruik in de context van Kubernetes.

Een paar woorden over Prometheus

Om volledig te begrijpen hoe Loki werkt, is het belangrijk om een stap terug te nemen en even stil te staan bij Prometheus.

Een van de onderscheidende kenmerken van Prometheus is het extraheren van metrics uit verzamelpunten (via exporters) en deze op te slaan in een TSDB (Time Series Data Base, tijdreeksdatabase) met toevoeging van metadata in de vorm van labels.

Waarom is dit nodig

De laatste tijd is Prometheus de de facto standaard geworden in de wereld van containers en Kubernetes: de installatie is zeer eenvoudig en in een Kubernetes-cluster is er standaard een endpoint voor Prometheus. Prometheus kan ook metrics extraheren uit toepassingen die in containers zijn uitgerold, terwijl bepaalde labels behouden blijven. Daarom is het monitoren van toepassingen zeer eenvoudig te implementeren.

Helaas is er tot nu toe geen ‘turnkey’ oplossing voor logbeheer, en moet je zelf een oplossing vinden:

• een beheerde cloudservice voor logcentralisatie (AWS, Azure of Google)
• monitoringservice 'monitoring als dienst' (monitoring as a service) (bijvoorbeeld Datadog)
• je eigen logverzamelservice opzetten.

Voor de derde optie heb ik traditioneel Elasticsearch gebruikt, hoewel ik daar niet altijd tevreden mee was (vooral vanwege de zwaarte en complexiteit van de configuratie).

Loki is ontworpen om de implementatie te vereenvoudigen volgens de volgende principes:

• gemakkelijk te starten zijn
• weinig middelen verbruiken
• zelfstandig functioneren zonder speciaal onderhoud
• dienen als aanvulling op Prometheus voor het helpen bij het onderzoeken van bugs

Echter, deze eenvoud wordt bereikt ten koste van enkele compromissen. Een daarvan is dat content niet geïndexeerd wordt. Daardoor is tekstzoeken niet erg efficiënt of rijk en is het niet mogelijk om statistieken over de inhoud bij te houden. Maar aangezien Loki de bedoeling heeft om een equivalent van grep en een aanvulling op Prometheus te zijn, is dit geen tekortkoming.

Incidentonderzoek

Om beter te begrijpen waarom Loki geen indexering nodig heeft, laten we terugkeren naar de methode van incidentonderzoek die de ontwikkelaars van Loki hebben gebruikt:

1 Alert → 2 Dashboard → 3 Adhoc Query → 4 Logaggregatie → 5 Gedistribueerde tracing → 6 Oplossen!
(1 Waarschuwing → 2 Dashboard → 3 Adhoc Query → 4 Logaggregatie → 5 Gedistribueerde tracing → 6 Oplossen!)

Het idee is dat we een alert (Slack-notificatie, SMS, enz.) ontvangen en daarna:

• de Grafana-dashboards bekijken
• de prestaties van services bekijken (bijvoorbeeld in Prometheus)
• de logboeken bekijken (bijvoorbeeld in Elasticsearch)
• mogelijk een blik werpen op de gedistribueerde tracés (Jaeger, Zipkin, enz.)
• en tenslotte het oorspronkelijke probleem oplossen.

In dit geval, met de stack Grafana + Prometheus + Elasticsearch + Zipkin, moet je vier verschillende tools gebruiken. Om tijd te besparen, zou het goed zijn om al deze stappen met één tool uit te voeren: Grafana. Het is vermeldenswaard dat deze benadering van onderzoek in Grafana is geïmplementeerd sinds versie 6. Hierdoor is het mogelijk om direct gegevens van Prometheus vanuit Grafana aan te roepen.

Het Explorer-scherm is verdeeld tussen Prometheus en Loki

Op dit scherm kunnen logs in Loki worden bekeken die verband houden met de metrics van Prometheus, met behulp van het concept van gesplitst scherm. Sinds versie 6.5 stelt Grafana je in staat om trace-id's in de logboeken van Loki te verwerken om door te linken naar je favoriete gedistribueerde traceertools (Jaeger).

Lokaal test Loki

De eenvoudigste manier voor lokaal testen van Loki is het gebruik van docker-compose. Het docker-compose bestand bevindt zich in de Loki-repository. Je kunt de repository verkrijgen met behulp van de volgende opdracht git:

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

Vervolgens moet je naar de productiecatalogus gaan:

$ cd production

Daarna kun je de laatste versie van de Docker-images ophalen:

$ docker-compose pull

Ten slotte wordt de Loki-stack gestart met de volgende opdracht:

$ docker-compose up

Architectuur van Loki

Hier is een klein diagram van de architectuur van Loki:

Principes van de architectuur van Loki

De webclient start applicaties op de server, Promtail verzamelt logs en verzendt ze naar Loki, de webclient verzendt ook metadata naar Loki. Loki aggregeert alles en stuurt het door naar Grafana.
Loki is gestart. Voer de volgende opdracht uit om de beschikbare componenten te bekijken:

$ docker ps

Bij een vers geïnstalleerde Docker zou de opdracht het volgende resultaat moeten geven:

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

We zien de volgende componenten:

• Promtail: een agent die verantwoordelijk is voor de centralisatie van logs
• Grafana: een bekend hulpmiddel voor dashboards
• Loki: een demon voor datacentralisatie

Binnen de klassieke infrastructuur (bijvoorbeeld op basis van virtuele machines) moet op elke machine een Promtail-agent worden geïnstalleerd. Grafana en Loki kunnen op dezelfde machine worden geïnstalleerd.

Implementatie in Kubernetes

De installatie van Loki-componenten in Kubernetes bestaat uit het volgende:

• daemonSet voor de implementatie van de Promtail-agent op elke machine in het servercluster
• implementatie (Deployment) van Loki
• en ten slotte - de implementatie van Grafana.

Gelukkig is Loki beschikbaar als een Helm-pakket, wat de implementatie vergemakkelijkt.

Installatie via Helm

Helm moet al op uw systeem zijn geïnstalleerd. Het kan worden gedownload van de GitHub-repository van het project. Het wordt geïnstalleerd door het archief uit te pakken dat bij uw architectuur hoort en helm toe te voegen aan $PATH.

Opmerking: versie 3.0.0 van Helm is onlangs uitgebracht. Aangezien er veel wijzigingen zijn doorgevoerd, wordt de lezer aangeraden even te wachten voordat hij deze gaat gebruiken..

Toevoegen van een bron voor Helm

De eerste stap is het toevoegen van de repository "loki" met behulp van de volgende opdracht:

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

Daarna kan er gezocht worden naar pakketten met de naam "loki":

$ helm search loki

Resultaat:

loki/loki       0.17.2 v0.4.0 Loki: als Prometheus, maar voor logs.
loki/loki-stack 0.19.1 v0.4.0 Loki: als Prometheus, maar voor logs.
loki/fluent-bit 0.0.2  v0.0.1 Gebruik de fluent-bit Loki-go-plugin voor...
loki/promtail   0.13.1 v0.4.0 Verantwoordelijk voor het verzamelen van logs en...

Deze pakketten hebben de volgende functies:

• pakket loki/loki komt overeen met alleen de Loki-server
• pakket loki/fluent-bit maakt het mogelijk om een DaemonSet te implementeren, gebruikmakend van fluent-bit voor het verzamelen van logs in plaats van Promtail
• pakket loki/promtail bevat de agent voor het verzamelen van logbestanden
• pakket loki/loki-stack, maakt het mogelijk om Loki samen met Promtail te implementeren.

Installatie van Loki

Om Loki in Kubernetes te implementeren, voert u de volgende opdracht uit in de namespace "monitoring":

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

Om op te slaan op de schijf, voeg de parameter toe --set loki.persistence.enabled = true:

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

Opmerking: als je tegelijkertijd Grafana wilt implementeren, voeg dan de parameter toe --set grafana.enabled = true

Wanneer je dit commando uitvoert, zou je de volgende output moeten krijgen:

LAATSTE UITGEVOERD: di 19 nov 15:56:54 2019
NAAMRUIMTE: monitoring
STATUS: UITGEVOERD
BRONNEN:
==> v1/ClusterRole
NAAM LEEFTIJD
loki-promtail-clusterrole 189d
…
OPMERKINGEN:
De Loki-stack is naar uw cluster uitgerold. Loki kan nu als een gegevensbron in Grafana worden toegevoegd.
Zie <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> voor meer details.

Door de status van de pods in de namespace “monitoring” te bekijken, zien we dat alles is geïmplementeerd:

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

Resultaat:

NAAM                 KLAAR  STATUS   HERSTARTEN  LEeftijd
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 pods draaien. Nu is het tijd om enkele tests uit te voeren!

Verbinding maken met Grafana

Om verbinding te maken met Grafana vanuit Kubernetes, moet je een tunnel naar zijn pod openen. Hieronder staat de commando om poort 3000 voor de Grafana pod open te stellen:

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

Een andere belangrijke zaak is de noodzaak om het Grafana-beheerder wachtwoord te herstellen. Het wachtwoord is opgeslagen in een geheim loki-grafana in het veld .data.admin-user in base64-formaat.

Om het te herstellen, moet je het volgende commando uitvoeren:

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

Gebruik dit wachtwoord samen met het standaard beheerdersaccount (admin).

Bron van Loki-gegevens in Grafana definiëren

Zorg er eerst voor dat de bron van Loki-gegevens (Configuratie / Gegevensbron) is aangemaakt.
Hier is een voorbeeld:

Voorbeeldconfiguratie voor de Loki-gegevensbron

Door op 'Test' te klikken, kun je de verbinding met Loki controleren.

Verzoeken indienen bij Loki

Ga nu naar Grafana in het gedeelte 'Verken'. Bij het ontvangen van logs van de containers voegt Loki metadata van Kubernetes toe. Hierdoor is het mogelijk om de logs van een specifieke container te bekijken.

Bijvoorbeeld, om de logs van de promtail-container te selecteren, kun je de volgende query gebruiken: {container_name = "promtail"}.
Vergeet ook niet om de Loki-gegevensbron te selecteren.

Deze query retourneert de activiteit van de containers in de volgende vorm:

Resultaat van de query in Grafana

Toevoegen aan het dashboard

Vanaf Grafana 6.4 is het mogelijk om informatie over logs rechtstreeks op het dashboard te plaatsen. Na dit zal de gebruiker snel kunnen schakelen tussen het aantal verzoeken op zijn website en de tracés van de applicatie.

Hier is een voorbeeld van een dashboard dat deze interactie implementeert:

Voorbeeld dashboard met Prometheus-metrieken en Loki-logboeken

De toekomst van Loki

Ik begon Loki te gebruiken in mei/juni met versie 0.1. Vandaag is versie 1 al uitgebracht, en ook 1.1 en 1.2.

Het moet gezegd worden dat versie 0.1 niet voldoende stabiel was. Maar 0.3 toonde al echte tekenen van volwassenheid, en de daaropvolgende versies (0.4, daarna 1.0) versterkten alleen maar deze indruk.

Na 1.0.0 kan niemand nog excuses hebben om deze geweldige tool niet te gebruiken.

Verdere verbeteringen moeten niet de focus op Loki hebben, maar eerder op de integratie met het uitstekende Grafana. In feite heeft Grafana 6.4 al een goede integratie met dashboards geïntroduceerd.

Grafana 6.5, dat recent is uitgebracht, verbetert deze integratie verder door automatisch de inhoud van logboeken in JSON-formaat te herkennen.

Hieronder staat een korte video van dit mechanisme:

Gebruik van Loki-strings weergegeven in Grafana

Het wordt mogelijk om een van de JSON-velden te gebruiken, bijvoorbeeld voor:

• link naar een externe tool
• filteren van logboekinhoud

Bijvoorbeeld, je kunt op traceId klikken om naar Zipkin of Jaeger te gaan.

Traditioneel wachten we op jullie opmerkingen en nodigen we je uit voor de openbare webinar, waar we zullen praten over hoe de DevOps-industrie zich in 2019 heeft ontwikkeld en mogelijke ontwikkelingsroutes voor 2020 zullen bespreken.

Bron: habr.com