Il monitoraggio è diventato un componente fondamentale delle crescenti soluzioni cloud, con l'aumento della complessità dei sistemi distribuiti. È necessario per comprendere il loro comportamento. Sono necessari strumenti scalabili in grado di raccogliere dati da tutti i servizi e fornire agli esperti un'interfaccia unica con analisi delle prestazioni, visualizzazione degli errori, disponibilità e registri.
Questi strumenti devono anche essere efficaci e performanti. In questo articolo esamineremo due stack tecnologici popolari: EFK (Elasticsearch) e PLG (Loki) analizzando le loro architetture e differenze.
Stack EFK
Forse hai già sentito parlare del molto popolare ELK o EFK. Lo stack è composto da diverse parti: Elasticsearch (archivio oggetti), Logstash o FluentD (raccolta e aggregazione dei log) e Kibana per la visualizzazione.
Uno schema di funzionamento tipico appare così:
Elasticsearch — archivio oggetti distribuito con ricerca e analisi in tempo reale. Una soluzione eccellente per dati parzialmente strutturati, come i log. Le informazioni sono memorizzate in documenti JSON, indicizzate in tempo reale e distribuite tra i nodi del cluster. Viene utilizzato un indice inverso che contiene tutte le parole uniche e i documenti ad esse associati per la ricerca full-text, che a sua volta si basa sul motore di ricerca Apache Lucene.
FluentD — è un raccoglitore di dati che unifica le informazioni al momento della raccolta e del consumo. Cerca di strutturare i dati in JSON il più possibile. La sua architettura è estensibile, ci sono più di , supportate dalla comunità, per ogni evenienza.
Kibana — uno strumento di visualizzazione dei dati per Elasticsearch con varie funzionalità aggiuntive, come analisi delle serie temporali, grafici, machine learning e altro ancora.
Architettura di Elasticsearch
I dati del cluster Elasticsearch sono distribuiti tra tutti i nodi. Il cluster è composto da diversi nodi per migliorare la disponibilità e la resilienza. Ogni nodo può svolgere tutti i ruoli del cluster, ma nei grandi deployment scalabili ai nodi vengono solitamente assegnati compiti specifici.
Tipi di nodi del cluster:
- nodo master — gestisce il cluster, ne servono almeno tre, uno è sempre attivo;
- nodo dati — memorizza i dati indicizzati e svolge vari compiti con essi;
- ingest node — organizza pipeline per la trasformazione dei dati prima dell indicizzazione;
- coordinating node — instradamento delle richieste, riduzione della fase di elaborazione delle ricerche, coordinamento dell indicizzazione di massa;
- alerting node — avvio dei compiti di notifica;
- machine learning node — elaborazione dei compiti di apprendimento automatico.
Nella diagramma qui sotto è mostrato come i dati siano salvati e replicati sui nodi per garantire maggiore disponibilità dei dati.
I dati di ciascuna replica sono memorizzati nell indice invertito; lo schema qui sotto mostra come avviene:
Installazione
Puoi visualizzare i dettagli , userò il chart helm:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsStack PLG
Non sorprendere se non riesci a trovare questo acronimo, poiché è più conosciuto come Grafana Loki. In ogni caso, questo stack sta guadagnando popolarità poiché applica soluzioni tecniche ben ponderate. Potresti già aver sentito parlare di Grafana, uno strumento popolare per la visualizzazione. I suoi creatori, ispirandosi a Prometheus, hanno sviluppato Loki, un sistema di aggregazione dei log ad alte prestazioni e scalabile orizzontalmente. Loki indicizza solo i metadati e non i log stessi; questa soluzione tecnica lo ha reso facile da usare ed economicamente vantaggioso.
Promtail — agente per inviare i log dal sistema operativo al cluster Loki. Grafana — strumento di visualizzazione basato sui dati di Loki.
Loki è costruito sugli stessi principi di Prometheus, quindi è adatto per la memorizzazione e l analisi dei log di Kubernetes.
Architettura di Loki
Loki può essere eseguito sia in modalità di processo singolo, sia come più processi, permettendo così la scalabilità orizzontale.
Può anche funzionare sia come applicazione monolitica che come microservizio. L'esecuzione come processo singolo può essere utile per lo sviluppo locale o per il monitoraggio ridotto. Per l'implementazione industriale e carichi scalabili, si consiglia di adottare la variante microservizio. Le vie di scrittura e lettura dei dati sono separate, quindi può essere sintonizzato e scalato abbastanza finemente in base alle necessità.
Diamo un’occhiata all'architettura del sistema di raccolta dei log senza scendere nei dettagli:
E qui — una descrizione (architettura microservizio):
Componenti:
Promtail — un agente installato sui nodi (sotto forma di un insieme di servizi), estrae i registri dalle attività e si rivolge all'API di Kubernetes per ottenere i metadati con cui verranno contrassegnati i registri. Poi invia il registro al servizio principale Loki. Per la corrispondenza dei metadati, si applicano le stesse regole di etichettatura come in Prometheus.
Distributore — un servizio distributore che funge da buffer. Per elaborare milioni di record, compone i dati in arrivo, comprimendoli in blocchi man mano che arrivano. Funzionano simultaneamente più riceventi di dati, ma i registri appartenenti a un unico flusso di dati in ingresso devono trovarsi solo in uno di essi per tutti i suoi blocchi. Questo è organizzato sotto forma di un anello di riceventi e di hashing sequenziale. Per tolleranza agli errori e ridondanza, viene eseguita n volte (3, se non configurato).
Ingester — un servizio ricevente. I blocchi di dati arrivano compressi con registri aggiunti. Una volta che un blocco raggiunge una dimensione sufficiente, si esegue il caricamento del blocco nel database. I metadati vanno nell'indice, mentre i dati del blocco con il registro finiscono in Chunks (di solito archivio oggetti). Dopo il caricamento, il ricevente crea un nuovo blocco in cui verranno aggiunti nuovi record.
Index — database, DynamoDB, Cassandra, Google BigTable e altro.
Chunks — blocchi di registri in forma compressa, solitamente memorizzati in archivi oggetti, come S3.
Querier — il percorso di lettura che svolge tutto il lavoro pesante. Controlla l'intervallo di tempo e le etichette, poi esamina l'indice per cercare corrispondenze. Successivamente legge i blocchi di dati e li filtra per ottenere il risultato.
E ora diamo un'occhiata a tutto in azione.
Installazione
Per l'installazione in Kubernetes, è più semplice utilizzare helm. Supponiamo che tu l'abbia già installato e configurato ( nota del traduttore)
Aggiungiamo il repository e installiamo lo stack.
$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=falseDi seguito è riportato un esempio di dashboard che mostra i dati da Prometheus per le metriche Etcd e Loki per i registri dei pod Etcd.
E ora discutiamo dell'architettura di entrambi i sistemi, confrontandone anche le capacità.
Confronto
Linguaggio di query
In Elasticsearch viene utilizzato il Query DSL e il linguaggio di query Lucene, che garantiscono la possibilità di ricerca full-text. È un motore di ricerca potente e consolidato con un ampio supporto per gli operatori. Con esso, è possibile cercare per contesto e ordinare per rilevanza.
Dall'altra parte del ring c'è LogQL, utilizzato in Loki, erede di PromQL (linguaggio di query di Prometheus). Utilizza le etichette dei log per filtrare e selezionare i dati dei log. È possibile utilizzare alcuni operatori e funzioni aritmetiche, come descritto , ma in termini di funzionalità è inferiore rispetto al linguaggio di Elastic.
Poiché le query in Loki sono legate alle etichette, è facile confrontarle con le metriche, rendendo così più semplice organizzare il monitoraggio operativo.
Scalabilità
Entrambi gli stack sono orizzontalmente scalabili, ma con Loki è più semplice, poiché ha percorsi di lettura e scrittura dei dati separati e una architettura a microservizi. Loki può essere adattato alle vostre esigenze e può essere utilizzato per volumi molto grandi di dati log.
Multi-tenancy
La multi-tenancy del cluster è un tema comune per la riduzione dell'OPEX; entrambi gli stack forniscono multi-tenancy. Per Elasticsearch ci sono diversi di separazione dei clienti: indice separato per ogni cliente, instradamento basato sul cliente, campi unici per il cliente, filtri di ricerca. In Loki c'è in forma di intestazione HTTP X-Scope-OrgID.
Prezzo
Loki è molto economicamente efficace grazie al fatto che non indicizza i dati, ma solo i metadati. In questo modo si ottiene e di memoria (cache), poiché lo storage a oggetti è più economico di quello a blocchi, utilizzato nei cluster Elasticsearch.
Conclusione
Lo stack EFK può essere utilizzato per vari scopi, fornendo massima flessibilità e un'interfaccia multifunzionale Kibana per analisi, visualizzazione e query. Può essere ulteriormente migliorato con funzionalità di machine learning.
Lo stack Loki è utile nell'ecosistema Kubernetes grazie al meccanismo di rilevamento dei metadati. È facile abbinare i dati per il monitoraggio basato su serie temporali in Grafana e nei log.
Quando si tratta di costi e conservazione a lungo termine dei log, Loki è una scelta eccellente per entrare nelle soluzioni basate sul cloud.
Ci sono più alternative sul mercato - alcune potrebbero essere migliori per te. Ad esempio, per GKE c'è l'integrazione Stackdriver, che offre una soluzione eccellente per il monitoraggio. Non le abbiamo incluse nella nostra analisi in questo articolo.
Link:
L'articolo è stato tradotto e preparato per Habr dai dipendenti - corsi intensivi, video corsi e formazione aziendale da parte di esperti praticanti (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Fonte: habr.com
