Iniciar sesión en Kubernetes: EFK vs PLG

Iniciar sesión en Kubernetes: EFK vs PLG

El monitoreo se ha convertido en un componente muy importante de las crecientes soluciones en la nube a medida que aumenta la complejidad de los sistemas distribuidos. Es necesario comprender su comportamiento. Necesitamos herramientas escalables que puedan recopilar datos de todos los servicios y proporcionar a los especialistas una interfaz única con análisis de rendimiento, demostración de errores, disponibilidad y registros.

Estas mismas herramientas deben ser eficientes y productivas. En este artículo, veremos dos pilas de tecnología populares: EFK (Elasticsearch) y PLG (Loki) y examinaremos sus arquitecturas y diferencias.

pila EFK

Es posible que ya haya oído hablar de los muy populares ELK o EFK. La pila consta de varias partes distintas: Elasticsearch (almacenamiento de objetos), Logstash o FluentD (recolección y agregación de registros) y Kibana para visualización.

Un flujo de trabajo típico se ve así:

Iniciar sesión en Kubernetes: EFK vs PLG

Elasticsearch — almacenamiento de objetos distribuidos con búsqueda y análisis en tiempo real. Excelente solución para datos semiestructurados como registros. La información se guarda como documentos JSON, se indexa en tiempo real y se distribuye entre los nodos del clúster. Se utiliza un índice invertido que contiene todas las palabras únicas y los documentos asociados para la búsqueda de texto completo, que a su vez se basa en el motor de búsqueda Apache Lucene.

FluidoD es un recolector de datos que unifica los datos al momento de recolectarlos y consumirlos. Intenta organizar los datos en JSON tanto como sea posible. Su arquitectura es extensible, hay más cientos de extensiones diferentes, apoyado por la comunidad, para todas las ocasiones.

Kibana - una herramienta de visualización de datos para Elasticsearch con varias capacidades adicionales, por ejemplo, análisis de series temporales, análisis de gráficos, aprendizaje automático y más.

Arquitectura de búsqueda elástica

Los datos del clúster de Elasticsearch se almacenan distribuidos en todos sus nodos. Un clúster consta de varios nodos para mejorar la disponibilidad y la resiliencia. Cualquier nodo puede realizar todas las funciones del clúster, pero en implementaciones de gran escala, a los nodos generalmente se les asignan tareas individuales.

Tipos de nodos del clúster:

  • nodo maestro: gestiona el clúster, se necesitan al menos tres, uno siempre está activo;
  • nodo de datos: almacena datos indexados y realiza diversas tareas con ellos;
  • nodo de ingesta: organiza canalizaciones para transformar datos antes de indexarlos;
  • nodo coordinador: enrutamiento de solicitudes, reducción de la fase de procesamiento de búsqueda, coordinación de indexación masiva;
  • nodo de alerta: lanzamiento de tareas de alerta;
  • Nodo de aprendizaje automático: procesamiento de tareas de aprendizaje automático.

El siguiente diagrama muestra cómo se almacenan y replican los datos entre nodos para lograr una mayor disponibilidad de datos.

Iniciar sesión en Kubernetes: EFK vs PLG

Los datos de cada réplica se almacenan en un índice invertido; el siguiente diagrama muestra cómo sucede esto:

Iniciar sesión en Kubernetes: EFK vs PLG

Instalación

Se pueden ver los detalles aquí, usaré el gráfico de timón:

$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elastics

Pila de PLG

No te sorprendas si no encuentras este acrónimo, ya que es más conocido como Grafana Loki. En cualquier caso, esta pila está ganando popularidad porque utiliza soluciones técnicas probadas. Quizás ya hayas oído hablar de Grafana, una popular herramienta de visualización. Sus creadores, inspirados en Prometheus, desarrollaron Loki, un sistema de agregación de registros de alto rendimiento y escalable horizontalmente. Loki indexa sólo los metadatos, no las revistas en sí, una solución técnica que permite que sea fácil de usar y rentable.

Pagano - un agente para enviar registros desde el sistema operativo al clúster Loki. Grafana es una herramienta de visualización basada en datos de Loki.

Iniciar sesión en Kubernetes: EFK vs PLG

Loki se basa en los mismos principios que Prometheus, lo que lo hace muy adecuado para almacenar y analizar registros de Kubernetes.

arquitectura loki

Loki se puede ejecutar como un proceso único o como procesos múltiples, lo que permite el escalado horizontal.

Iniciar sesión en Kubernetes: EFK vs PLG

También puede funcionar como aplicación monolítica o como microservicio. Ejecutarlo como un proceso único puede resultar útil para el desarrollo local o para un seguimiento menor. Para implementación industrial y carga de trabajo escalable, se recomienda utilizar la opción de microservicio. Las rutas para escribir y leer datos están separadas, por lo que se pueden ajustar y escalar con precisión según sea necesario.

Veamos la arquitectura del sistema de recopilación de registros sin entrar en detalles:

Iniciar sesión en Kubernetes: EFK vs PLG

Y aquí está la descripción (arquitectura de microservicio):

Iniciar sesión en Kubernetes: EFK vs PLG

Componentes:

Pagano — un agente instalado en nodos (como un conjunto de servicios), elimina registros de tareas y accede a la API de Kubernetes para obtener metadatos que etiquetarán los registros. Luego envía el registro al servicio principal de Loki. El mapeo de metadatos admite las mismas reglas de etiquetado que Prometheus.

Distribuidores — un distribuidor de servicios que funciona como amortiguador. Para procesar millones de registros, empaqueta los datos entrantes, comprimiéndolos en bloques a medida que llegan. Se ejecutan varios receptores de datos simultáneamente, pero los registros que pertenecen a un flujo de datos entrante solo deberían aparecer en uno de ellos para todos sus bloques. Esto está organizado en un anillo de sumideros y hash secuencial. Para tolerancia a fallas y redundancia, esto se hace n veces (3 si no está configurado).

Ingestión — receptor del servicio. Los bloques de datos llegan comprimidos con registros agregados. Una vez que el bloque tiene un tamaño suficiente, se vacía en la base de datos. Los metadatos van al índice y los datos del bloque de registro van a Chunks (generalmente almacenamiento de objetos). Después del reinicio, el receptor crea un nuevo bloque donde se agregarán nuevas entradas.

Iniciar sesión en Kubernetes: EFK vs PLG

Home - base de datos, DynamoDB, Cassandra, Google BigTable, etc.

Trozos — bloques de registro en forma comprimida, generalmente almacenados en un almacenamiento de objetos, por ejemplo, S3.

interrogador - el camino de lectura que hace todo el trabajo sucio. Mira el rango de tiempo y la marca de tiempo, y luego mira el índice para encontrar coincidencias. A continuación, lee bloques de datos y los filtra para obtener el resultado.

Ahora veamos todo en acción.

Instalación

La forma más sencilla de instalar en Kubernetes es utilizar helm. Suponemos que ya lo has instalado y configurado (y la tercera versión! aprox. traductor)

Agregue un repositorio e instale 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=false

A continuación se muestra un panel de ejemplo que muestra datos de Prometheus para las métricas de Etcd y Loki para los registros de pods de Etcd.

Iniciar sesión en Kubernetes: EFK vs PLG

Ahora analicemos la arquitectura de ambos sistemas y también comparemos sus capacidades entre sí.

Comparación

Lenguaje de consulta

Elasticsearch utiliza Query DSL y el lenguaje de consulta Lucene para proporcionar capacidades de búsqueda de texto completo. Es un motor de búsqueda potente y establecido con un amplio soporte de operadores. Con él, puedes buscar por contexto y ordenar por relevancia.

En el otro lado del anillo está LogQL, utilizado en Loki, el sucesor de PromQL (lenguaje de consulta Prometheus). Utiliza etiquetas de registro para filtrar y seleccionar datos de registro. Es posible utilizar algunos operadores y aritmética como se describe. aquí, pero en términos de capacidades está por detrás del lenguaje Elastic.

Dado que las consultas en Loki están asociadas con etiquetas, son fáciles de correlacionar con métricas y, como resultado, es más fácil organizar el monitoreo operativo.

Escalabilidad

Ambas pilas son escalables horizontalmente, pero Loki lo hace más fácil porque tiene rutas de lectura y escritura separadas y una arquitectura de microservicio. Loki se puede personalizar para satisfacer sus necesidades y se puede utilizar para grandes volúmenes de datos de registro.

Multi Alquiler

La multiinquilino del clúster es un tema común en el acrónimo OPEX; ambas pilas proporcionan multiinquilino. Hay varios para Elasticsearch formas de separación de clientes: índice separado para cada cliente, enrutamiento basado en el cliente, campos de cliente únicos, filtros de búsqueda. Loki tiene apoyar en forma de encabezado HTTP X-Scope-OrgID.

costo de

Loki es bastante rentable debido al hecho de que no indexa los datos, sólo los metadatos. Esto logra ahorro en almacenamiento y memoria (caché), ya que el almacenamiento de objetos es más económico que el almacenamiento en bloques, que se utiliza en los clústeres de Elasticsearch.

Conclusión

La pila EFK se puede utilizar para una variedad de propósitos, proporcionando máxima flexibilidad y una interfaz Kibana rica en funciones para análisis, visualización y consultas. Puede mejorarse aún más mediante capacidades de aprendizaje automático.

La pila Loki es útil en el ecosistema de Kubernetes debido a su mecanismo de descubrimiento de metadatos. Puede correlacionar fácilmente datos para el seguimiento en función de series temporales en Grafana y registros.

Cuando se trata de costos y almacenamiento de registros a largo plazo, Loki es un excelente punto de entrada a las soluciones en la nube.

Hay más alternativas en el mercado; algunas pueden ser mejores para usted. Por ejemplo, GKE tiene una integración de Stackdriver que proporciona una excelente solución de monitoreo. No los incluimos en nuestro análisis de este artículo.

Enlaces:

El artículo fue traducido y preparado para Habr por empleados Centro de entrenamiento Slurm — cursos intensivos, cursos en vídeo y formación corporativa impartidos por especialistas en ejercicio (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Fuente: habr.com

Añadir un comentario