Loki — raccolta dei log utilizzando l'approccio Prometheus

Salve, utenti di Habr! In vista dell'inizio di un nuovo ciclo del corso «Pratiche e strumenti DevOps» abbiamo preparato per voi la traduzione di un interessante materiale.

Questo articolo è un breve introduzione a Loki. Il progetto Loki è supportato da Grafana ed è destinato alla raccolta centralizzata dei log (da server o contenitori).

La principale fonte di ispirazione per Loki è stata Prometheus con l'idea di applicare i suoi approcci alla gestione dei log:

• uso di etichette (labels) per memorizzare i dati
• consumo ridotto di risorse

Torneremo ai principi di funzionamento di Prometheus e forniremo alcuni esempi del suo utilizzo nel contesto di Kubernetes.

Qualche parola su Prometheus

Per comprendere appieno come funziona Loki, è importante fare un passo indietro e ricordare un po' Prometheus.

Una delle caratteristiche distintive di Prometheus è l'estrazione delle metriche dai punti di raccolta (tramite exporter) e la loro conservazione nella TSDB (Time Series Data Base) con l'aggiunta di metadati sotto forma di etichette.

A cosa serve

Recentemente, Prometheus è diventato lo standard de facto nel mondo dei container e di Kubernetes: la sua installazione è molto semplice, e all'interno del cluster Kubernetes è già presente un endpoint per Prometheus. Prometheus può anche estrarre metriche da applicazioni distribuite all'interno di container, mantenendo determinate etichette. Pertanto, il monitoraggio delle applicazioni è molto facile da implementare.

Sfortunatamente, non esiste ancora una soluzione “chiavi in mano” per la gestione dei log, e dovete trovare una soluzione per voi stessi:

• servizio cloud gestito per la centralizzazione dei log (AWS, Azure o Google)
• servizio di monitoraggio "monitoraggio come servizio" (monitoring as a service) (ad esempio, Datadog)
• creare il proprio servizio di raccolta log.

Per la terza opzione, ho tradizionalmente utilizzato Elasticsearch, anche se non sono sempre stato soddisfatto (soprattutto per la sua pesantezza e complessità di configurazione).

Loki è stato progettato per semplificare l'implementazione secondo i seguenti principi:

• essere facile da avviare
• consumare poche risorse
• funzionare autonomamente senza alcuna manutenzione speciale
• servire da complemento a Prometheus per aiutare nell'indagine di bug

Tuttavia, questa semplicità comporta alcuni compromessi. Uno di essi è non indicizzare il contenuto. Pertanto, la ricerca testuale non è molto efficace o ricca e non consente di condurre statistiche sul contenuto testuale. Ma poiché Loki desidera essere l'equivalente di grep e un complemento di Prometheus, questo non è un difetto.

Investigazione degli incidenti

Per comprendere meglio perché Loki non necessiti di indicizzazione, torniamo al metodo di investigazione degli incidenti utilizzato dagli sviluppatori di Loki:

1 Allerta → 2 Dashboard → 3 Query Adhoc → 4 Aggregazione dei Log → 5 Tracciamento Distribuito → 6 Risolvi!
(1 Allerta → 2 Dashboard → 3 Query Adhoc → 4 Aggregazione dei Log → 5 Tracciamento Distribuito → 6 Risolvi!)

L'idea è che ricevamo un'allerta (notifica Slack, SMS, ecc.) e dopo:

• guardiamo i dashboard di Grafana
• controlliamo le metriche dei servizi (ad esempio, in Prometheus)
• esaminiamo le registrazioni dei log (ad esempio, in Elasticsearch)
• possibilmente diamo un'occhiata ai tracciamenti distribuiti (Jaeger, Zipkin, ecc.)
• e, infine, risolviamo il problema originale.

Qui, nel caso di un stack Grafana + Prometheus + Elasticsearch + Zipkin, sarà necessario utilizzare quattro strumenti diversi. Per ridurre il tempo, sarebbe utile avere la possibilità di eseguire tutte queste fasi tramite un unico strumento: Grafana. È importante notare che questo approccio all'analisi è stato implementato in Grafana a partire dalla versione 6. In questo modo, diventa possibile accedere ai dati di Prometheus direttamente da Grafana.

Lo schermo Explorer è diviso tra Prometheus e Loki

In questo schermo è possibile visualizzare i log in Loki legati alle metriche di Prometheus utilizzando il concetto di divisione dello schermo. A partire dalla versione 6.5, Grafana consente di gestire l'identificatore di tracciamento (trace id) nei log di Loki per passare ai tuoi strumenti di tracciamento distribuito preferiti (Jaeger).

Test locale di Loki

Il modo più semplice per testare Loki localmente è utilizzare docker-compose. Il file docker-compose si trova nel repository di Loki. Puoi ottenere il repository con il comando seguente git:

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

Poi devi andare nella directory di produzione:

$ cd production

A questo punto, puoi ottenere l'ultima versione delle immagini Docker:

$ docker-compose pull

Finalmente, lo stack Loki viene avviato con il seguente comando:

$ docker-compose up

Architettura di Loki

Ecco un diagramma con l'architettura di Loki:

Principi dell'architettura di Loki

Il client web avvia le applicazioni sul server, Promtail raccoglie i log e li invia a Loki, il client web invia anche i metadati a Loki. Loki aggrega tutto e trasferisce a Grafana.
Loki è in esecuzione. Per visualizzare i componenti disponibili, eseguire il seguente comando:

$ docker ps

In caso di Docker appena installato, il comando dovrebbe restituire il seguente risultato:

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

Vediamo i seguenti componenti:

• Promtail: agente responsabile della centralizzazione dei log
• Grafana: noto strumento per dashboard
• Loki: demone per la centralizzazione dei dati

Nell'infrastruttura classica (ad esempio, basata su macchine virtuali), su ogni macchina deve essere distribuito un agente Promtail. Grafana e Loki possono essere installati sulla stessa macchina.

Distribuzione in Kubernetes

L'installazione dei componenti di Loki in Kubernetes consisterà in quanto segue:

• daemonSet per distribuire l'agente Promtail su ciascuna delle macchine nel cluster di server
• distribuzione (Deployment) Loki
• e per ultimo, distribuzione di Grafana.

Fortunatamente, Loki è disponibile come pacchetto Helm, il che facilita la sua distribuzione.

Installazione tramite Helm

Helm deve già essere installato. Può essere scaricato dal repository GitHub del progetto. Si installa estraendo l'archivio corrispondente alla propria architettura e aggiungendo helm a $PATH.

Nota: la versione 3.0.0 di Helm è stata rilasciata di recente. Poiché ci sono state molte modifiche, si consiglia di attendere un po' prima di iniziare a utilizzarla..

Aggiunta di una sorgente per Helm

Il primo passo sarà aggiungere il repository "loki" utilizzando il seguente comando:

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

Dopo di che, è possibile cercare i pacchetti con il nome "loki":

$ helm search loki

Risultato:

loki/loki       0.17.2 v0.4.0 Loki: simile a Prometheus, ma per i log.
loki/loki-stack 0.19.1 v0.4.0 Loki: simile a Prometheus, ma per i log.
loki/fluent-bit 0.0.2  v0.0.1 Utilizza il plugin go di fluent-bit per...
loki/promtail   0.13.1 v0.4.0 Responsabile della raccolta dei log e...

Questi pacchetti hanno le seguenti funzionalità:

• pacchetto loki/loki corrisponde solo al server Loki
• pacchetto loki/fluent-bit ti consente di distribuire DaemonSet usando fluent-bin per raccogliere log invece di Promtail
• pacchetto loki/promtail contiene un agente di raccolta dei log
• pacchetto loki/loki-stack, consente di distribuire Loki insieme a Promtail.

Installazione di Loki

Per distribuire Loki in Kubernetes, esegui il comando seguente nello spazio dei nomi 'monitoring':

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

Per salvare su disco, aggiungi il parametro --set loki.persistence.enabled=true:

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

Nota: se desideri distribuire anche Grafana, aggiungi il parametro --set grafana.enabled=true

Quando esegui questo comando, dovresti ricevere il seguente output:

ULTIMO DISPONIMENTO: Mar Nov 19 15:56:54 2019
SPAZIO NOME: monitoring
STATO: DISPONIBILE
RISORSE:
==> v1/ClusterRole
NOME ETÀ
loki-promtail-clusterrole 189d
…
NOTE:
Il stack Loki è stato distribuito nel tuo cluster. Loki può ora essere aggiunto come sorgente dati in Grafana.
Vedi <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> per ulteriori dettagli.

Controllando lo stato dei pod nello spazio dei nomi 'monitoring', vedremo che tutto è stato distribuito:

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

Risultato:

NOME                 PRONTO  STATO   RIAVVI  ETÀ
loki-0               1/1    In esecuzione  0         147m
loki-promtail-9zjvc  1/1    In esecuzione  0         3h25m
loki-promtail-f6brf  1/1    In esecuzione  0         11h
loki-promtail-hdcj7  1/1    In esecuzione  0         3h23m
loki-promtail-jbqhc  1/1    In esecuzione  0         11h
loki-promtail-mj642  1/1    In esecuzione  0         62m
loki-promtail-nm64g  1/1    In esecuzione  0         24m

Tutti i pod sono in esecuzione. Ora è tempo di effettuare alcuni test!

Collegamento a Grafana

Per connettersi a Grafana su Kubernetes, è necessario aprire un tunnel al suo pod. Di seguito è riportato il comando per aprire la porta 3000 per il pod Grafana:

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

Un altro aspetto importante è la necessità di recuperare la password dell'amministratore di Grafana. La password è conservata in modo riservato. loki-grafana nel campo .data.admin-user in formato base64.

Per recuperarla, è necessario eseguire il seguente comando:

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

Usa questa password insieme all'account amministratore predefinito (admin).

Definizione della sorgente dati Loki in Grafana

Prima di tutto, assicurati che sia stata creata una sorgente dati Loki (Configurazione / Sorgente dati).
Ecco un esempio:

Esempio di configurazione della sorgente dati per Loki

Cliccando su “Test” puoi verificare la connessione con Loki.

Effettuare richieste a Loki

Ora vai su Grafana nella sezione “Esplora”. Quando riceve log dai contenitori, Loki aggiunge metadati da Kubernetes. In questo modo, diventa possibile visualizzare i log di un contenitore specifico.

Ad esempio, per selezionare i log del contenitore promtail, puoi utilizzare la seguente richiesta: {container_name = "promtail"}.
Non dimenticare di selezionare anche la sorgente dati Loki.

Questa richiesta restituirà l'attività dei contenitori nel seguente formato:

Risultato della richiesta in Grafana

Aggiunta alla dashboard

A partire da Grafana 6.4, è possibile inserire informazioni sui log direttamente nel dashboard. Dopo di che, l'utente può passare rapidamente tra il numero di richieste sul suo sito e i trace dell'applicazione.

Di seguito è riportato un esempio di dashboard che implementa questa interazione:

Esempio di dashboard con metriche Prometheus e log Loki

Il futuro di Loki

Ho iniziato a utilizzare Loki già a maggio / giugno con la versione 0.1. Oggi è già stata rilasciata la versione 1, e anche le versioni 1.1 e 1.2.

Bisogna ammettere che la versione 0.1 non era sufficientemente stabile. Ma la 0.3 ha mostrato già veri segni di maturità, e le versioni successive (0.4, poi 1.0) hanno solo rinforzato questa impressione.

Dopo la 1.0.0, nessuno può avere scuse per non utilizzare questo straordinario strumento.

Miglioramenti futuri dovrebbero riguardare non tanto Loki, quanto piuttosto la sua integrazione con l'eccellente Grafana. In realtà, in Grafana 6.4 è già disponibile una buona integrazione con i dashboard.

Grafana 6.5, rilasciata di recente, migliora ulteriormente questa integrazione, riconoscendo automaticamente il contenuto dei log in formato JSON.

Di seguito nel video è presentato un breve esempio di questo meccanismo:

Utilizzo delle stringhe Loki visualizzate in Grafana

Diventa possibile utilizzare uno dei campi JSON, ad esempio per:

• collegamenti a strumenti esterni
• filtraggio dei contenuti dei log

Ad esempio, puoi cliccare su traceId per passare a Zipkin o Jaeger.

Tradizionalmente attendiamo i vostri commenti e vi invitiamo a un webinar aperto, dove parleremo di come si è sviluppata l'industria DevOps nel corso del 2019 e discuteremo possibili direzioni di sviluppo per il 2020.

Fonte: habr.com