Loki - raccolta dei log utilizzando l'approccio Prometheus

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

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

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

• uso delle etichette (labels) per la conservazione dei dati
• consumare poche risorse

Torneremo presto 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 esportatori) e il loro salvataggio nel TSDB (Time Series Data Base) con l'aggiunta di metadati sotto forma di etichette.

Perché è necessario

Negli ultimi tempi Prometheus è diventato lo standard de facto nel mondo dei contenitori e di Kubernetes: la sua installazione è molto semplice, e nel cluster Kubernetes è originariamente presente un endpoint per Prometheus. Prometheus può anche estrarre metriche dalle applicazioni distribuite nel contenitore, mantenendo determinate etichette. Pertanto, il monitoraggio delle applicazioni è molto facile da implementare.

Sfortunatamente, attualmente non esiste una soluzione 'chiavi in mano' per la gestione dei log, e dovete trovare una soluzione per voi:

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

Per il terzo opzione, ho tradizionalmente utilizzato Elasticsearch, anche se non sono sempre stato soddisfatto (soprattutto per il suo peso e la difficoltà di configurazione).

Loki è stato progettato con l'obiettivo di semplificare l'implementazione secondo i seguenti principi:

• essere semplice da avviare
• consumare poche risorse
• funzionare in modo autonomo senza alcuna manutenzione speciale
• servire come complemento a Prometheus per aiutare nell'indagine sui bug

Tuttavia, questa semplicità è raggiunta a scapito di alcuni compromessi. Uno di questi è l'assenza di indicizzazione dei contenuti. Pertanto, la ricerca nel testo non è molto efficace o ricca e non consente di condurre statistiche sui contenuti testuali. Ma poiché Loki desidera essere l'equivalente di grep e un complemento a Prometheus, questo non è un difetto.

Indagine sugli incidenti

Per capire meglio perché Loki non ha bisogno di indicizzazione, torniamo al metodo di indagine sugli incidenti utilizzato dagli sviluppatori di Loki:

1 Avviso → 2 Cruscotto → 3 Query Adhoc → 4 Aggregazione log → 5 Tracciamento distribuito → 6 Risolvi!
(1 Avviso → 2 Cruscotto → 3 Query Adhoc → 4 Aggregazione log → 5 Tracciamento distribuito → 6 Risolvi!)

L'idea è che riceviamo un avviso (Notifica Slack, SMS, ecc.) e poi:

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

Qui, nel caso della pila Grafana + Prometheus + Elasticsearch + Zipkin, dovremmo utilizzare quattro strumenti diversi. Per risparmiare tempo, sarebbe utile avere la possibilità di eseguire tutte queste fasi utilizzando uno strumento unico: Grafana. Vale la pena notare che questo approccio all'indagine è stato implementato in Grafana a partire dalla versione 6. Pertanto, è possibile accedere ai dati di Prometheus direttamente da Grafana.

La schermata Explorer è divisa tra Prometheus e Loki

In questa schermata è possibile visualizzare i log in Loki collegati alle metriche di Prometheus, utilizzando il concetto di divisione dello schermo. A partire dalla versione 6.5, Grafana consente di elaborare l'identificativo di tracciamento (trace id) nelle voci di log di Loki per navigare nei 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 seguente comando git:

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

Poi devi accedere alla cartella production:

$ cd production

Dopo di che puoi ottenere l'ultima versione delle immagini Docker:

$ docker-compose pull

Infine, la pila Loki viene avviata con il seguente comando:

$ docker-compose up

Architettura di Loki

Ecco un piccolo diagramma con l'architettura di Loki:

Principi dell'architettura di Loki

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

$ docker ps

Se Docker è appena stato installato, il comando dovrebbe restituire il seguente risultato:

IMMAGINE               PORTE                  NOME
 grafana/promtail:                          produzione_promtail_1
 grafana/grafana: m  0.0.0.0:3000->3000/tcp produzione_grafana_1
 grafana/loki: tardivo  80/tcp,0.0.0.0:3100... produzione_loki_1

Vediamo i seguenti componenti:

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

Nell'ambito di un'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 Loki in Kubernetes consisterà nei seguenti passaggi:

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

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

Installazione tramite Helm

Helm dovrebbe già essere installato. Può essere scaricato dal repository GitHub del progetto. Si installa decompressando 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 stati molti cambiamenti, si consiglia ai lettori di aspettare un po' prima di iniziare a usarla.

Aggiunta di una fonte per Helm

Il primo passo sarà aggiungere il repository 'loki' con il seguente comando:

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

Dopo di ciò, puoi cercare pacchetti con il nome 'loki':

$ helm search loki

Risultato:

loki/loki       0.17.2 v0.4.0 Loki: come Prometheus, ma per i log.
loki/loki-stack 0.19.1 v0.4.0 Loki: come 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 un DaemonSet utilizzando fluent-bit per raccogliere i log invece di Promtail
• pacchetto loki/promtail contiene l'agente di raccolta dei file di log
• pacchetto loki/loki-stack, consente di distribuire Loki con Promtail contemporaneamente.

Installazione di Loki

Per distribuire Loki in Kubernetes, eseguire il seguente comando 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 Grafana contemporaneamente, aggiungi il parametro --set grafana.enabled = true

Eseguendo questo comando, dovresti ottenere il seguente output:

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

Guardando 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     Eseguito  0         147m
loki-promtail-9zjvc  1/1     Eseguito  0         3h25m
loki-promtail-f6brf  1/1     Eseguito  0         11h
loki-promtail-hdcj7  1/1     Eseguito  0         3h23m
loki-promtail-jbqhc  1/1     Eseguito  0         11h
loki-promtail-mj642  1/1     Eseguito  0         62m
loki-promtail-nm64g  1/1     Eseguito  0         24m

Tutti i pod sono in esecuzione. È ora di effettuare alcuni test!

Collegamento a Grafana

Per connettersi a Grafana da 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 è memorizzata nel segreto 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

Utilizza 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” è possibile verificare la connessione a Loki.

Facciamo richieste a Loki

Ora passa a Grafana nella sezione “Esplora”. Durante la ricezione dei log dai container, Loki aggiunge metadati da Kubernetes. In questo modo è possibile visualizzare i log di un container specifico.

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

Questa query restituirà l'attività dei container nel seguente formato:

Risultato della query in Grafana

Aggiunta al dashboard

A partire da Grafana 6.4, è possibile inserire informazioni sui log direttamente nel dashboard. Dopo ciò, l'utente potrà passare rapidamente tra il numero di richieste sul proprio sito e i tracciamenti dell'applicazione.

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

Esempio di dashboard con metriche di Prometheus e log di Loki

Il futuro di Loki

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

Va detto che la versione 0.1 non era particolarmente stabile. Ma la 0.3 ha già mostrato reali segni di maturità, e le versioni successive (0.4, poi 1.0) hanno solo rafforzato questa impressione.

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

Miglioramenti futuri dovrebbero riguardare non tanto Loki, quanto piuttosto la sua integrazione con l'ottima Grafana. In effetti, 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 è riportato un breve esempio di questo meccanismo:

Utilizzo delle stringhe Loki visualizzate in Grafana

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

• collegamenti a strumenti esterni
• filtrare il contenuto dei log

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

Tradizionalmente aspettiamo i vostri commenti e vi invitiamo a un webinar aperto, dove parleremo di come si è sviluppato il settore DevOps nel corso del 2019 e discuteremo le possibili direzioni di sviluppo per il 2020.

Fonte: habr.com