Salute, Khabroviti! In attesa dell'inizio di una nuova iscrizione al corso preparato una traduzione di materiale interessante per te.
Questo articolo è una breve introduzione a Loki. Progetto Loki ed è finalizzato alla raccolta centralizzata di log (da server o container).
L'ispirazione principale per Loki era con l'idea di applicare i suoi approcci alla gestione dei log:
- utilizzando le etichette per memorizzare i dati
- basso consumo di risorse
Torneremo ai principi di Prometeo e forniremo alcuni esempi del suo utilizzo nel contesto di Kubernetes.
Qualche parola su Prometeo
Per comprendere appieno come funziona Loki, è importante fare un passo indietro e rivisitare Prometheus un po'.
Una delle caratteristiche distintive di Prometheus è l'estrazione delle metriche dai punti di raccolta (tramite esportatori) e la loro memorizzazione in un TSDB (Time Series Data Base, database di serie temporali) con l'aggiunta di metadati sotto forma di etichette.
Perché ne hai bisogno
Recentemente, Prometheus è diventato lo standard de facto nel mondo dei container e di Kubernetes: la sua installazione è molto semplice, e un cluster Kubernetes ha inizialmente un endpoint per Prometheus. Prometheus può anche estrarre le metriche dalle applicazioni distribuite in un contenitore mantenendo etichette specifiche. Pertanto, il monitoraggio dell'applicazione è molto facile da implementare.
Sfortunatamente, non esiste ancora una soluzione chiavi in mano per la gestione dei log e devi trovare una soluzione per te stesso:
- servizio cloud gestito per la centralizzazione dei log (AWS, Azure o Google)
- servizio di monitoraggio "monitoraggio come servizio" (ad esempio, Datadog)
- creare il proprio servizio di raccolta dei registri.
Per la terza opzione, ho utilizzato tradizionalmente Elasticsearch, nonostante non ne fossi sempre soddisfatto (soprattutto la sua pesantezza e complessità di configurazione).
Loki è stato progettato per essere facile da implementare secondo i seguenti principi:
- essere facile da iniziare
- consumare poche risorse
- lavorare in autonomia senza particolari manutenzioni
- servire come componente aggiuntivo di Prometheus per aiutare con le indagini sui bug
Tuttavia, questa semplicità va a scapito di alcuni compromessi. Uno di questi è non indicizzare il contenuto. Pertanto, la ricerca testuale è poco efficiente o ricca e non consente di tenere statistiche sul contenuto del testo. Ma dal momento che Loki vuole essere l'equivalente grep e il complemento di Prometeo, questo non è uno svantaggio.
Indagine sull'incidente
Per capire meglio perché Loki non necessita di indicizzazione, torniamo al metodo di indagine sugli incidenti utilizzato dagli sviluppatori di Loki:
1 Avviso → 2 Dashboard → 3 Query ad hoc → 4 Aggregazione log → 5 Tracciamento distribuito → 6 Correzione!
(1 Avviso → 2 Dashboard → 3 Query ad hoc → 4 Aggregazione log → 5 Tracciamento distribuito → 6 Correzione!)
L'idea è che riceviamo una sorta di avviso (notifica di rallentamento, SMS, ecc.) e successivamente:
- guarda i cruscotti di Grafana
- guarda le metriche del servizio (ad esempio, in Prometheus)
- guarda le voci di registro (ad esempio, in Elasticsearch)
- forse dai un'occhiata alle tracce distribuite (Jaeger, Zipkin, ecc.)
- e infine risolvere il problema originale.
Qui, nel caso dello stack Grafana + Prometheus + Elasticsearch + Zipkin, dovrai utilizzare quattro diversi strumenti. Per risparmiare tempo, sarebbe bello poter fare tutti questi passaggi con un unico strumento: Grafana. Vale la pena notare che questo approccio alla ricerca è stato implementato in Grafana dalla versione 6. Pertanto, diventa possibile accedere ai dati di Prometheus direttamente da Grafana.
Schermata di Explorer divisa tra Prometeo e Loki
Da questa schermata, puoi visualizzare i log in Loki relativi alle metriche di Prometheus utilizzando il concetto di schermo diviso. Dalla versione 6.5, Grafana ti consente di analizzare l'id di traccia nelle voci del registro Loki per seguire i collegamenti ai tuoi strumenti di tracciamento distribuiti preferiti (Jaeger).
Test locale Loki
Il modo più semplice per testare Loki localmente è usare docker-compose. Il file docker-compose si trova nel repository Loki. Puoi ottenere il repository con il seguente comando git:
$ git clone https://github.com/grafana/loki.gitQuindi è necessario passare alla directory di produzione:
$ cd productionSuccessivamente, puoi ottenere le ultime immagini Docker:
$ docker-compose pullInfine, lo stack Loki viene avviato con il seguente comando:
$ docker-compose upArchitettura loki
Ecco un piccolo diagramma con l'architettura Loki:
Principi di architettura Loki
Il client Web esegue 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 lo passa a Grafana.
Loki sta correndo. Per visualizzare i componenti disponibili, eseguire il seguente comando:
$ docker psNel caso di un 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_1Vediamo i seguenti componenti:
- Promtail: agente responsabile della centralizzazione dei log
- Grafana: il famoso strumento dashboard
- Loki: demone di centralizzazione dei dati
Come parte di un'infrastruttura classica (ad esempio, basata su macchine virtuali), l'agente Promtail deve essere distribuito su ogni macchina. Grafana e Loki possono essere installati sulla stessa macchina.
Distribuzione su Kubernetes
L'installazione dei componenti Loki in Kubernetes sarà la seguente:
- daemonSet per distribuire l'agente Promtail su ciascuna delle macchine nel cluster di server
- Distribuzione di Loki
- e l'ultimo è lo schieramento di Grafana.
Fortunatamente, Loki è disponibile come pacchetto Helm, facilitando la distribuzione.
Installazione tramite Heml
Dovresti già avere Heml installato. Può essere scaricato dal repository GitHub del progetto. Viene installato estraendo l'archivio appropriato per la tua architettura e aggiungendovi helm $PATH.
Nota: la versione 3.0.0 di Helm è stata rilasciata di recente. Poiché ci sono stati molti cambiamenti in esso, si consiglia al lettore di attendere un po' prima di iniziare ad usarlo..
Aggiunta fonte per Helm
Il primo passo è aggiungere il repository "loki" con il seguente comando:
$ helm add loki https://grafana.github.io/loki/chartsSuccessivamente, puoi cercare i pacchetti denominati "loki":
$ helm search lokiIl risultato:
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...Questi pacchetti hanno le seguenti caratteristiche:
- pacchetto loki/loki corrisponde solo al server Loki
- pacchetto loki/fluente consente di distribuire DaemonSet utilizzando fluent-bin per raccogliere i log invece di Promtail
- pacchetto loki/coda del ballo contiene un agente di raccolta dei registri
- pacchetto loki/loki-stack, ti consente di schierare immediatamente Loki insieme a Promtail.
Installazione di Loki
Per distribuire Loki su Kubernetes, esegui il seguente comando nello spazio dei nomi "monitoraggio":
$ helm upgrade --install loki loki/loki-stack --namespace monitoringPer salvare su disco, aggiungi l'opzione --set loki.persistence.enabled = true:
$ helm upgrade --install loki loki/loki-stack
--namespace monitoring
--set loki.persistence.enabled=trueNota: se desideri distribuire Grafana contemporaneamente, aggiungi il parametro
--set grafana.enabled = true
Quando esegui questo comando, dovresti ottenere il seguente output:
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.Osservando lo stato dei pod nello spazio dei nomi di "monitoraggio", possiamo vedere che tutto è distribuito:
$ kubectl -n monitoring get pods -l release=lokiIl risultato:
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 24mTutti i pod sono in esecuzione. Ora è il momento di fare alcuni test!
Collegamento a Grafana
Per connetterti a Grafana sotto Kubernetes, devi aprire un tunnel al suo pod. Di seguito è riportato il comando per aprire la porta 3000 per un pod Grafana:
$ kubectl -n port-forward monitoring svc/loki-grafana 3000:80Un altro punto importante è la necessità di recuperare la password dell'amministratore di Grafana. La password è tenuta segreta loki-grafana nel campo .data.admin-user in formato base64.
Per ripristinarlo, è necessario eseguire il seguente comando:
$ kubectl -n monitoring get secret loki-grafana
--template '{{index .data "admin-password" | base64decode}}'; echoUtilizzare questa password insieme all'account amministratore predefinito (admin).
Definizione dell'origine dati Loki a Grafana
Prima di tutto, assicurati che l'origine dati Loki (Configurazione / Origine dati) sia creata.
Ecco un esempio:
Un esempio di impostazione di un'origine dati per Loki
Cliccando su “Test” puoi testare la connessione con Loki.
Fare richieste a Loki
Ora vai a Grafana e vai alla sezione "Esplora". Quando riceve i log dai container, Loki aggiunge metadati da Kubernetes. Pertanto, diventa possibile visualizzare i log di un contenitore specifico.
Ad esempio, per selezionare i log del contenitore promtail, puoi utilizzare la seguente query: {container_name = "promtail"}.
Non dimenticare di selezionare anche qui l'origine dati Loki.
Questa query restituirà l'attività del contenitore come segue:
Risultato interrogazione a Grafana
Aggiunta alla dashboard
A partire da Grafana 6.4, è possibile inserire le informazioni di registro direttamente sulla dashboard. Successivamente, l'utente sarà in grado di passare rapidamente dal numero di richieste sul proprio sito alle tracce dell'applicazione.
Di seguito è riportato un esempio di dashboard che implementa questa interazione:
Dashboard di esempio con metriche Prometheus e registri Loki
Il futuro di Loki
Ho iniziato a usare Loki a maggio/giugno con la versione 0.1. La versione 1 è già stata rilasciata oggi, e anche la 1.1 e la 1.2.
Bisogna ammettere che la versione 0.1 non era abbastanza stabile. Ma la 0.3 mostrava già veri segni di maturità e le versioni successive (0.4, poi 1.0) hanno solo rafforzato questa impressione.
Dopo la 1.0.0, nessuno può avere una scusa per non utilizzare questo meraviglioso strumento.
Ulteriori miglioramenti non dovrebbero riguardare Loki, quanto piuttosto la sua integrazione con l'ottimo Grafana. Infatti, Grafana 6.4 ha già una buona integrazione con i dashboard.
Grafana 6.5, rilasciato di recente, migliora ulteriormente questa integrazione riconoscendo automaticamente il contenuto dei log in formato JSON.
Il video qui sotto mostra un piccolo esempio di questo meccanismo:
Utilizzo di stringhe Loki renderizzate in Grafana
Diventa possibile utilizzare uno dei campi JSON, ad esempio, per:
- collegamenti a uno strumento esterno
- filtro del contenuto del registro
Ad esempio, puoi fare clic su traceId per accedere a Zipkin o Jaeger.
Come al solito, restiamo in attesa dei vostri commenti e vi invitiamo a farlo , dove parleremo di come si è sviluppato il settore DevOps nel corso del 2019 e discuteremo possibili percorsi di sviluppo per il 2020.
Fonte: habr.com