La supervisió s'ha convertit en un component molt important de les solucions en núvol en creixement amb la complexitat creixent dels sistemes distribuïts. Cal entendre el seu comportament. Necessitem eines escalables que puguin recopilar dades de tots els serveis i oferir als especialistes una única interfície amb anàlisi de rendiment, demostració d'errors, disponibilitat i registres.
Aquestes mateixes eines han de ser eficients i productives. En aquest article, analitzarem dues piles de tecnologia populars: EFK (Elasticsearch) i PLG (Loki) i analitzarem les seves arquitectures i diferències.
pila EFK
És possible que ja hagis sentit parlar dels populars ELK o EFK. La pila consta de diverses parts separades: Elasticsearch (emmagatzematge d'objectes), Logstash o FluentD (recollida i agregació de registres) i Kibana per a la visualització.
Un flux de treball típic és el següent:
Elasticsearch — Emmagatzematge d'objectes distribuït amb cerca i anàlisi en temps real. Una solució excel·lent per a dades semiestructurades com els registres. La informació s'emmagatzema com a documents JSON, s'indexa en temps real i es distribueix entre els nodes del clúster. S'utilitza un índex invertit que conté totes les paraules úniques i documents relacionats per a la cerca de text complet, que al seu torn es basa en el motor de cerca Apache Lucene.
Fluït D és un recopilador de dades que unifica les dades a mesura que es recullen i es consumeixen. Intenta organitzar les dades en JSON tant com sigui possible. La seva arquitectura és extensible, n'hi ha més , amb el suport de la comunitat, per a totes les ocasions.
Kibana és una eina de visualització de dades per a Elasticsearch amb diverses funcions addicionals, com ara anàlisi de sèries temporals, gràfics, aprenentatge automàtic i molt més.
Arquitectura Elasticsearch
Les dades del clúster d'Elasticsearch s'emmagatzemen repartides per tots els seus nodes. El clúster consta de diversos nodes per millorar la disponibilitat i la resiliència. Qualsevol node pot realitzar totes les funcions del clúster, però en desplegaments grans i escalables, els nodes solen assignar tasques separades.
Tipus de nodes de clúster:
- node mestre: gestiona el clúster, en necessiteu almenys tres, un sempre està actiu;
- node de dades: emmagatzema dades indexades i realitza diverses tasques amb elles;
- node d'ingestió: organitza canalitzacions per a la transformació de dades abans de la indexació;
- node de coordinació: encaminament de sol·licituds, reducció de la fase de processament de cerca, coordinació de la indexació massiva;
- node d'alerta: llançament de tasques de notificació;
- node d'aprenentatge automàtic: processament de tasques d'aprenentatge automàtic.
El diagrama següent mostra com les dades es persisteixen i es repliquen entre els nodes per aconseguir una major disponibilitat de dades.
Les dades de cada rèplica s'emmagatzemen en un índex invertit, el diagrama següent mostra com passa això:
Instal · lació
Els detalls es poden veure , utilitzaré el gràfic del timó:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticspila PLG
No us estranyeu si no trobeu aquest acrònim, ja que és més conegut com a Grafana Loki. En qualsevol cas, aquesta pila està guanyant popularitat perquè utilitza solucions tècniques ben ajustades. És possible que ja hagis sentit parlar de Grafana, una eina de visualització popular. Els seus creadors, inspirats en Prometeu, van desenvolupar Loki, un sistema d'agregació de registres d'alt rendiment i escalable horitzontal. Loki només indexa les metadades, no les revistes, aquesta solució tècnica ha fet que sigui fàcil d'utilitzar i rendible.
Promtail - un agent per enviar registres des del sistema operatiu al clúster Loki. Grafana és una eina de visualització basada en dades de Loki.
Loki es basa en els mateixos principis que Prometheus, de manera que és molt adequat per emmagatzemar i analitzar els registres de Kubernetes.
Arquitectura Loki
Loki es pot executar com a procés únic o com a processos múltiples, permetent l'escala horitzontal.
També pot funcionar tant com a aplicació monolítica com com a microservei. L'execució com a procés únic pot ser útil per al desenvolupament local o per a un seguiment detallat. Per a la implementació industrial i la càrrega de treball escalable, es recomana utilitzar l'opció de microservei. Els camins d'escriptura i lectura de dades estan separats, de manera que es poden ajustar i escalar amb precisió segons sigui necessari.
Vegem l'arquitectura del sistema de recollida de registres sense detalls:
I aquí teniu la descripció (arquitectura de microserveis):
Components:
Promtail - un agent instal·lat als nodes (com a conjunt de serveis), elimina els registres de les tasques i accedeix a l'API de Kubernetes per obtenir metadades que s'utilitzaran per marcar els registres. A continuació, envia el registre al servei principal de Loki. Per a la concordança de metadades, s'admeten les mateixes regles d'etiquetatge que a Prometheus.
Distribuïdor - distribuïdor de serveis, que funciona com a buffer. Per processar milions de registres, empaqueta les dades entrants, comprimint-les en blocs a mesura que arriben. S'estan executant diversos embornals de dades al mateix temps, però els registres que pertanyen al mateix flux de dades entrants haurien d'acabar només en un d'ells per a tots els seus blocs. Això s'organitza com un anell de receptors i hashing seqüencial. Per a la tolerància a errors i la redundància, es fa n vegades (3 si no està configurat).
ingerir - receptor del servei. Els blocs de dades es comprimeixen amb registres afegits. Tan bon punt el bloc té una mida suficient, el bloc s'envia a la base de dades. Les metadades van a l'índex i les dades del bloc de registre van a Chunks (normalment emmagatzematge d'objectes). Després del restabliment, el receptor crea un nou bloc on s'afegiran nous registres.
Index - base de dades, DynamoDB, Cassandra, Google BigTable i molt més.
Trossos - blocs de registres en forma comprimida, normalment emmagatzemats a l'emmagatzematge d'objectes, per exemple, S3.
Consultant és un camí de lectura que fa tota la feina bruta. Mira l'interval de temps i la marca de temps, i després mira l'índex per buscar coincidències. A continuació, llegeix blocs de dades i els filtra per obtenir el resultat.
Ara veiem-ho tot a la feina.
Instal · lació
La manera més senzilla d'instal·lar-lo a Kubernetes és utilitzar Helm. Suposem que ja l'heu instal·lat i configurat ( aprox. traductor)
Afegim un repositori i posem una pila.
$ 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=falseA continuació es mostra un tauler d'exemple que mostra les dades de Prometheus for Etcd i mètriques de Loki per als registres de pods Etcd.
I ara parlem de l'arquitectura d'ambdós sistemes, així com comparem les seves capacitats entre si.
Comparació
Llenguatge de consulta
Elasticsearch utilitza el llenguatge de consulta Query DSL i Lucene per proporcionar la capacitat de cerca de text complet. És un motor de cerca potent establert amb un ampli suport d'operadors. Amb ell, podeu cercar per context i ordenar per rellevància.
A l'altre costat de l'anell hi ha el LogQL de Loki, successor de PromQL (llenguatge de consulta de Prometheus). Utilitza etiquetes de registre per filtrar i seleccionar dades de registre. És possible utilitzar alguns operadors i aritmètica tal com es descriu , però pel que fa a les capacitats, es queda per darrere del llenguatge Elastic.
Com que les sol·licituds a Loki estan associades amb etiquetes, són fàcils de correlacionar amb mètriques, per tant, és més fàcil organitzar el seguiment operatiu amb elles.
Escalabilitat
Les dues piles són escalables horitzontalment, però amb Loki és més fàcil perquè té camins de lectura i escriptura separats i té una arquitectura de microservei. Loki es pot personalitzar segons les vostres necessitats i es pot utilitzar per a volums molt grans de dades de registre.
Multiarrendament
L'arrendament múltiple de clúster és un tema comú per a la reducció d'OPEX, ambdues piles ofereixen multiarrendament. N'hi ha diversos per a Elasticsearch separació de clients: índex separat per client, encaminament basat en el client, camps exclusius del client, filtres de cerca. Loki ho té com a capçalera HTTP X-Scope-OrgID.
Cost
Loki és molt rendible pel fet que no indexa dades, només metadades. Així, i memòria (caché), ja que l'emmagatzematge d'objectes és més barat que l'emmagatzematge de blocs, que s'utilitza als clústers d'Elasticsearch.
Conclusió
La pila EFK es pot utilitzar per a diversos propòsits, proporcionant la màxima flexibilitat i una interfície Kibana rica per a l'anàlisi, la visualització i les consultes. Es pot millorar encara més amb les capacitats d'aprenentatge automàtic.
La pila Loki és útil a l'ecosistema Kubernetes a causa del mecanisme de descobriment de metadades. Podeu correlacionar fàcilment les dades per al seguiment en funció de sèries temporals a Grafana i registres.
Quan es tracta de costos i retenció de registres a llarg termini, Loki és una opció excel·lent per entrar al núvol.
Hi ha més alternatives al mercat, algunes poden ser millors per a tu. Per exemple, GKE té una integració de Stackdriver que ofereix una gran solució de supervisió. No els hem inclòs en la nostra anàlisi d'aquest article.
Enllaços:
L'article va ser traduït i preparat per a Habr pels empleats — intensius, cursos de vídeo i formació corporativa de professionals (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Font: www.habr.com