A monitorización converteuse nun compoñente moi importante das solucións na nube en crecemento a medida que aumenta a complexidade dos sistemas distribuídos. É necesario comprender o seu comportamento. Necesitamos ferramentas escalables que poidan recoller datos de todos os servizos e proporcionar aos especialistas unha única interface con análise de rendemento, demostración de erros, dispoñibilidade e rexistros.
Estas mesmas ferramentas deben ser eficientes e produtivas. Neste artigo, analizaremos dúas pilas tecnolóxicas populares: EFK (Elasticsearch) e PLG (Loki) e examinaremos as súas arquitecturas e diferenzas.
pila EFK
Quizais xa escoitou falar sobre os moi populares ELK ou EFK. A pila consta de varias partes distintas: Elasticsearch (almacenamento de obxectos), Logstash ou FluentD (recollida e agregación de rexistros) e Kibana para a visualización.
Un fluxo de traballo típico é así:
Elasticsearch — almacenamento de obxectos distribuído con busca e análise en tempo real. Excelente solución para datos semiestruturados como rexistros. A información gárdase como documentos JSON, indézase en tempo real e distribúese entre os nodos do clúster. Utilízase un índice invertido, que contén todas as palabras únicas e os documentos asociados para a busca de texto completo, que á súa vez está baseado no buscador Apache Lucene.
Fluido D é un colector de datos que unifica os datos ao recollelos e consumilos. Tenta organizar os datos en JSON o máximo posible. A súa arquitectura é extensible, hai máis , apoiado pola comunidade, para todas as ocasións.
kibana - unha ferramenta de visualización de datos para Elasticsearch con varias capacidades adicionais, por exemplo, análise de series temporais, análise de gráficos, aprendizaxe automática e moito máis.
Arquitectura Elasticsearch
Os datos do clúster de Elasticsearch almacénanse repartidos en todos os seus nodos. Un clúster consta de varios nodos para mellorar a dispoñibilidade e a resistencia. Calquera nodo pode desempeñar todas as funcións do clúster, pero nas implantacións a gran escala, os nodos adoitan asignarse tarefas individuais.
Tipos de nodos de clúster:
- nodo mestre: xestiona o clúster, necesítanse polo menos tres, un sempre activo;
- nodo de datos: almacena datos indexados e realiza varias tarefas con el;
- ingest node: organiza canalizacións para transformar datos antes da indexación;
- nodo de coordinación - solicitudes de enrutamento, redución da fase de procesamento de busca, coordinación da indexación masiva;
- alerting node — iniciar tarefas de alerta;
- nodo de aprendizaxe automática: procesamento de tarefas de aprendizaxe automática.
O seguinte diagrama mostra como se almacenan e replican os datos entre os nodos para conseguir unha maior dispoñibilidade de datos.
Os datos de cada réplica gárdanse nun índice invertido; o seguinte diagrama mostra como ocorre isto:
Instalación
Os detalles pódense ver , Vou usar o gráfico de timón:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticspila PLG
Non te estrañes se non atopas este acrónimo, xa que é máis coñecido como Grafana Loki. En calquera caso, esta pila está gañando popularidade porque utiliza solucións técnicas comprobadas. Quizais xa escoitou falar de Grafana, unha popular ferramenta de visualización. Os seus creadores, inspirados en Prometheus, desenvolveron Loki, un sistema de agregación de rexistros de alto rendemento escalable horizontalmente. Loki indexa só os metadatos, non as propias revistas, unha solución técnica que permite que sexa fácil de usar e rendible.
Promtail - un axente para enviar rexistros desde o sistema operativo ao clúster de Loki. grafana é unha ferramenta de visualización baseada en datos de Loki.
Loki está construído sobre os mesmos principios que Prometheus, polo que é moi axeitado para almacenar e analizar rexistros de Kubernetes.
Arquitectura Loki
Loki pódese executar como un só proceso ou como varios procesos, permitindo a escala horizontal.
Tamén pode funcionar como unha aplicación monolítica ou como un microservizo. Executar como un proceso único pode ser útil para o desenvolvemento local ou para un seguimento menor. Para a implementación industrial e a carga de traballo escalable, recoméndase utilizar a opción de microservizo. Os camiños para escribir e ler datos están separados, polo que se poden axustar e escalar finamente segundo sexa necesario.
Vexamos a arquitectura do sistema de recollida de rexistros sen entrar en detalles:
E aquí está a descrición (arquitectura de microservizos):
Compoñentes:
Promtail — un axente instalado nos nodos (como un conxunto de servizos), elimina os rexistros das tarefas e accede á API de Kubernetes para obter metadatos que etiquetarán os rexistros. Despois envía o rexistro ao servizo principal de Loki. A asignación de metadatos admite as mesmas regras de etiquetado que Prometheus.
Distribuidor — un distribuidor de servizos que funciona como un buffer. Para procesar millóns de rexistros, empaqueta os datos entrantes, comprimindoos en bloques a medida que chegan. Varios sumidoiros de datos están a executarse simultáneamente, pero os rexistros pertencentes a un fluxo de datos entrante só deberían aparecer nun deles para todos os seus bloques. Isto organízase nun anel de pías e hashing secuencial. Para tolerancia a fallos e redundancia, isto faise n veces (3 se non está configurado).
Inxerir - receptor do servizo. Os bloques de datos chegan comprimidos cos rexistros engadidos. Unha vez que o bloque ten o tamaño suficiente, o bloque lévase á base de datos. Os metadatos van ao índice e os datos do bloque de rexistro van a Chunks (normalmente almacenamento de obxectos). Despois do reinicio, o receptor crea un novo bloque onde se engadirán novas entradas.
Índice - base de datos, DynamoDB, Cassandra, Google BigTable, etc.
Anacos — bloques de rexistro en forma comprimida, normalmente almacenados no almacenamento de obxectos, por exemplo, S3.
Consultador - o camiño de lectura que fai todo o traballo sucio. Mira o intervalo de tempo e a marca de tempo, e despois mira o índice para atopar coincidencias. A continuación, le bloques de datos e fíltraos para obter o resultado.
Agora vexamos todo en acción.
Instalación
A forma máis sinxela de instalar en Kubernetes é empregar Helm. Supoñemos que xa o instalou e configurou ( aprox. tradutor)
Engade un repositorio e instala unha 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ón móstrase un exemplo de panel que mostra os datos das métricas de Prometheus para Etcd e os rexistros de pod de Loki para Etcd.
Agora imos discutir a arquitectura de ambos os sistemas, e tamén comparar as súas capacidades entre si.
Comparación
Linguaxe de consulta
Elasticsearch usa Query DSL e a linguaxe de consulta Lucene para ofrecer capacidades de busca de texto completo. É un motor de busca establecido e potente con amplo soporte de operador. Con el, pode buscar por contexto e ordenar por relevancia.
No outro lado do anel está LogQL, usado en Loki, o sucesor de PromQL (linguaxe de consulta de Prometheus). Usa etiquetas de rexistro para filtrar e seleccionar os datos de rexistro. É posible utilizar algúns operadores e aritmética como se describe , pero en canto a capacidades está por detrás de Elastic language.
Dado que as consultas en Loki están asociadas con etiquetas, son fáciles de correlacionar coas métricas e, como resultado, son máis fáciles de organizar o seguimento operativo.
Escalabilidade
Ambas as pilas son escalables horizontalmente, pero Loki faino máis doado porque ten camiños separados de lectura e escritura e unha arquitectura de microservizos. Loki pódese personalizar para adaptarse ás túas necesidades e pódese usar para volumes moi grandes de datos de rexistro.
Multitenencia
O multitenancy de clúster é un tema común na abreviatura OPEX, ambas as pilas proporcionan multitenancy. Hai varios para Elasticsearch separación de clientes: índice separado para cada cliente, enrutamento baseado no cliente, campos de cliente únicos, filtros de busca. Loki ten en forma de cabeceira HTTP X-Scope-OrgID.
Custa
Loki é bastante rendible debido ao feito de que non indexa os datos, só os metadatos. Isto conséguese e memoria (caché), xa que o almacenamento de obxectos é máis barato que o almacenamento en bloque, que se usa nos clústeres de Elasticsearch.
Conclusión
A pila EFK pódese usar para unha variedade de propósitos, proporcionando a máxima flexibilidade e unha interface Kibana rica en funcións para análise, visualización e consultas. Pódese mellorar aínda máis grazas ás capacidades de aprendizaxe automática.
A pila de Loki é útil no ecosistema de Kubernetes debido ao seu mecanismo de descubrimento de metadatos. Podes correlacionar facilmente os datos para o seguimento en función de series temporais en Grafana e rexistros.
Cando se trata de custos e almacenamento de rexistros a longo prazo, Loki é un excelente punto de entrada ás solucións na nube.
Hai máis alternativas no mercado, algunhas poden ser mellores para ti. Por exemplo, GKE ten unha integración Stackdriver que ofrece unha excelente solución de monitorización. Non os incluímos na nosa análise neste artigo.
Referencias:
O artigo foi traducido e preparado para Habr polos empregados — cursos intensivos, cursos de vídeo e formación corporativa de especialistas en exercicio (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Fonte: www.habr.com