Il monitoraggio è diventato una componente molto importante delle soluzioni cloud in crescita man mano che aumenta la complessità dei sistemi distribuiti. È necessario comprendere il loro comportamento. Abbiamo bisogno di strumenti scalabili in grado di raccogliere dati da tutti i servizi e fornire agli specialisti un'unica interfaccia con analisi delle prestazioni, dimostrazione degli errori, disponibilità e registri.
Questi stessi strumenti devono essere efficienti e produttivi. In questo articolo, esamineremo due stack tecnologici popolari: EFK (Elasticsearch) e PLG (Loki) ed esamineremo le loro architetture e differenze.
Pila EFK
Potresti aver già sentito parlare dei famosissimi ELK o EFK. Lo stack è costituito da diverse parti distinte: Elasticsearch (archiviazione di oggetti), Logstash o FluentD (raccolta e aggregazione di log) e Kibana per la visualizzazione.
Un tipico flusso di lavoro è simile al seguente:
elasticsearch — storage distribuito di oggetti con ricerca e analisi in tempo reale. Ottima soluzione per dati semistrutturati come i log. Le informazioni vengono salvate come documenti JSON, indicizzate in tempo reale e distribuite tra i nodi del cluster. Viene utilizzato un indice invertito contenente tutte le parole univoche e i documenti associati per la ricerca full-text, che a sua volta si basa sul motore di ricerca Apache Lucene.
FluenteD è un raccoglitore di dati che unifica i dati durante la raccolta e il consumo. Cerca di organizzare il più possibile i dati in JSON. La sua architettura è estensibile, ce ne sono altri , supportato dalla comunità, per tutte le occasioni.
Kibana - uno strumento di visualizzazione dei dati per Elasticsearch con varie funzionalità aggiuntive, ad esempio analisi di serie temporali, analisi di grafici, apprendimento automatico e altro ancora.
Architettura elasticsearch
I dati del cluster Elasticsearch vengono archiviati distribuiti su tutti i suoi nodi. Un cluster è costituito da più nodi per migliorare la disponibilità e la resilienza. Qualsiasi nodo può eseguire tutti i ruoli del cluster, ma nelle distribuzioni con scalabilità orizzontale su larga scala, ai nodi vengono in genere assegnate attività individuali.
Tipi di nodi del cluster:
- nodo master - gestisce il cluster, ne servono almeno tre, uno è sempre attivo;
- nodo dati: memorizza i dati indicizzati ed esegue vari compiti con essi;
- nodo di ingest: organizza le pipeline per la trasformazione dei dati prima dell'indicizzazione;
- nodo di coordinamento - instradamento delle richieste, riduzione della fase di elaborazione della ricerca, coordinamento dell'indicizzazione di massa;
- nodo di avviso: avvio di attività di avviso;
- nodo di machine learning: elaborazione delle attività di machine learning.
Il diagramma seguente mostra come i dati vengono archiviati e replicati tra i nodi per ottenere una maggiore disponibilità dei dati.
I dati di ciascuna replica vengono archiviati in un indice invertito, il diagramma seguente mostra come ciò accade:
Installazione
È possibile visualizzare i dettagli , userò il grafico del timone:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPila PLG
Non sorprenderti se non riesci a trovare questo acronimo, poiché è meglio conosciuto come Grafana Loki. In ogni caso, questo stack sta guadagnando popolarità perché utilizza soluzioni tecniche comprovate. Potresti aver già sentito parlare di Grafana, un popolare strumento di visualizzazione. I suoi creatori, ispirati da Prometeo, hanno sviluppato Loki, un sistema di aggregazione di log scalabile orizzontalmente e ad alte prestazioni. Loki indicizza solo i metadati, non le riviste stesse, una soluzione tecnica che gli consente di essere facile da usare ed economico.
Promtail - un agente per l'invio di log dal sistema operativo al cluster Loki. graminacee è uno strumento di visualizzazione basato sui dati di Loki.
Loki si basa sugli stessi principi di Prometheus, rendendolo particolarmente adatto per l'archiviazione e l'analisi dei log di Kubernetes.
Architettura loki
Loki può essere eseguito come processo singolo o come processi multipli, consentendo il ridimensionamento orizzontale.
Può anche funzionare come applicazione monolitica o come microservizio. L'esecuzione come processo unico può essere utile per lo sviluppo locale o per un monitoraggio minore. Per l'implementazione industriale e il carico di lavoro scalabile, si consiglia di utilizzare l'opzione microservizio. I percorsi per la scrittura e la lettura dei dati sono separati, quindi possono essere ottimizzati e ridimensionati secondo necessità.
Diamo un'occhiata all'architettura del sistema di raccolta dei log senza entrare nei dettagli:
Ed ecco la descrizione (architettura del microservizio):
Componenti:
Promtail — un agente installato sui nodi (come insieme di servizi), rimuove i log dalle attività e accede all'API Kubernetes per ottenere metadati che taggheranno i log. Quindi invia il registro al servizio Loki principale. La mappatura dei metadati supporta le stesse regole di tagging di Prometheus.
Distributore — un distributore di servizi che funge da cuscinetto. Per elaborare milioni di record, impacchetta i dati in ingresso, comprimendoli in blocchi man mano che arrivano. Diversi data sink sono in esecuzione contemporaneamente, ma i log appartenenti a un flusso di dati in entrata dovrebbero essere visualizzati solo in uno di essi per tutti i suoi blocchi. Questo è organizzato in un anello di sink e hashing sequenziale. Per la tolleranza agli errori e la ridondanza, questa operazione viene eseguita n volte (3 se non configurata).
Ingerire — destinatario del servizio. I blocchi di dati arrivano compressi con l'aggiunta dei log. Una volta che il blocco ha raggiunto dimensioni sufficienti, il blocco viene scaricato nel database. I metadati vanno all'indice e i dati dal blocco di log vanno ai Chunk (solitamente l'archiviazione di oggetti). Dopo il ripristino, il ricevitore crea un nuovo blocco in cui verranno aggiunte nuove voci.
Indice - database, DynamoDB, Cassandra, Google BigTable, ecc.
Bocconcini — blocchi di log in forma compressa, solitamente archiviati nell'object storage, ad esempio S3.
Interrogante - il percorso di lettura che fa tutto il lavoro sporco. Esamina l'intervallo di tempo e il timestamp, quindi esamina l'indice per trovare corrispondenze. Successivamente, legge blocchi di dati e li filtra per ottenere il risultato.
Ora vediamo tutto in azione.
Installazione
Il modo più semplice per eseguire l'installazione in Kubernetes è utilizzare helm. Partiamo dal presupposto che tu lo abbia già installato e configurato ( ca. traduttore)
Aggiungi un repository e installa uno 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 delle metriche Prometheus per Etcd e dei log dei pod Loki per Etcd.
Ora discutiamo dell'architettura di entrambi i sistemi e confrontiamo anche le loro capacità tra loro.
Confronto
Lingua di interrogazione
Elasticsearch utilizza Query DSL e il linguaggio di query Lucene per fornire funzionalità di ricerca full-text. È un motore di ricerca affermato e potente con un ampio supporto per gli operatori. Con esso, puoi cercare per contesto e ordinare per pertinenza.
Dall'altro lato del ring c'è LogQL, utilizzato in Loki, il successore di PromQL (Prometheus query Language). Utilizza i tag di registro per filtrare e selezionare i dati di registro. È possibile utilizzare alcuni operatori e operazioni aritmetiche come descritto , ma in termini di capacità è in ritardo rispetto al linguaggio elastico.
Poiché le query in Loki sono associate ai tag, sono facili da correlare con le metriche e, di conseguenza, è più facile organizzare il monitoraggio operativo.
scalabilità
Entrambi gli stack sono scalabili orizzontalmente, ma Loki rende tutto più semplice perché ha percorsi di lettura e scrittura separati e un'architettura a microservizi. Loki può essere personalizzato per soddisfare le tue esigenze e può essere utilizzato per volumi molto grandi di dati di registro.
Multilocazione
La multitenancy del cluster è un tema comune nell'abbreviazione OPEX, entrambi gli stack forniscono la multitenancy. Ce ne sono diversi per Elasticsearch separazione dei client: indice separato per ogni client, routing basato sui client, campi client univoci, filtri di ricerca. Loki sì sotto forma di un'intestazione HTTP X-Scope-OrgID.
costo
Loki è abbastanza conveniente perché non indicizza i dati, ma solo i metadati. Ciò si ottiene e memoria (cache), poiché l'archiviazione di oggetti è più economica dell'archiviazione a blocchi, utilizzata nei cluster Elasticsearch.
conclusione
Lo stack EFK può essere utilizzato per una varietà di scopi, fornendo la massima flessibilità e un'interfaccia Kibana ricca di funzionalità per analisi, visualizzazione e query. Può essere ulteriormente migliorato dalle funzionalità di apprendimento automatico.
Lo stack Loki è utile nell'ecosistema Kubernetes grazie al suo meccanismo di rilevamento dei metadati. Puoi correlare facilmente i dati per il monitoraggio in base alle serie temporali in Grafana e ai log.
Quando si tratta di costi e di archiviazione dei registri a lungo termine, Loki è un eccellente punto di accesso alle soluzioni cloud.
Ci sono più alternative sul mercato: alcune potrebbero essere migliori per te. Ad esempio, GKE dispone di un'integrazione Stackdriver che fornisce un'eccellente soluzione di monitoraggio. Non li abbiamo inclusi nella nostra analisi in questo articolo.
Links:
L'articolo è stato tradotto e preparato per Habr dai dipendenti — corsi intensivi, videocorsi e formazione aziendale da parte di specialisti (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Fonte: habr.com