Modelos de Despliegue para una Arquitectura Escalable de Agregación de Logs usando Loki
Desplegar un Loki escalable no es una tarea sencilla. Ya hemos hablado sobre Loki en publicaciones anteriores en el sitio, y se está volviendo cada vez más popular, y su uso se vuelve mucho más regular cada día. Es por eso que creo que tiene sentido incluir otra publicación sobre la Arquitectura de Loki.
Loki tiene varias ventajas que lo promueven como una opción predeterminada para desplegar una Pila de Agregación de Logs. Una de ellas es su escalabilidad porque puedes ver a través de diferentes modelos de despliegue cuántos componentes te gustaría desplegar y sus responsabilidades. Así que el objetivo del tema es mostrarte cómo desplegar una solución escalable de Loki y esto se basa en dos conceptos: componentes disponibles y cómo los agrupas.
Así que comenzaremos con los diferentes componentes:
- ingester: responsable de escribir datos de logs en backends de almacenamiento a largo plazo (DynamoDB, S3, Cassandra, etc.) en la ruta de escritura y devolver datos de logs para consultas en memoria en la ruta de lectura.
- distributor: responsable de manejar flujos entrantes por parte de los clientes. Es el primer paso en la ruta de escritura para los datos de logs.
- query-frontend: servicio opcional que proporciona los puntos finales de la API del querier y puede usarse para acelerar la ruta de lectura.
- querier: servicio que maneja consultas usando el lenguaje de consulta LogQL, obteniendo logs de los ingesters y del almacenamiento a largo plazo.
- ruler: responsable de evaluar continuamente un conjunto de consultas configurables y realizar una acción basada en el resultado.
Luego puedes unirlos en diferentes grupos, y dependiendo del tamaño de estos grupos, tienes una topología de despliegue diferente, como se muestra a continuación:
- Monolito: Como puedes imaginar, todos los componentes se ejecutan juntos en una sola instancia. Esta es la opción más simple y se recomienda como un punto de partida de 100 GB / día. Incluso puedes escalar este despliegue, pero escalará todos los componentes simultáneamente, y debería tener un estado de objeto compartido.
- Modelo de Despliegue Escalable Simple: Este es el segundo nivel, y puede escalar hasta varios TB de logs por día. Consiste en dividir los componentes en dos perfiles diferentes: lectura y escritura.
- Microservicios: Eso significa que cada componente será gestionado de manera independiente, dándote todo el poder en tus manos para escalar cada uno de estos componentes por separado.
Definir el modelo de despliegue de cada instancia es muy fácil, y se basa en un solo parámetro llamado target. Así que dependiendo del valor del target seguirá uno de los modelos de despliegue anteriores:
- all (por defecto): Se desplegará en modo monolítico.
- write: Será la ruta de escritura en el modelo de despliegue escalable simple
- read: Será el grupo de lectura en el modelo de despliegue escalable simple
- ingester, distributor, query-frontend, query-scheduler, querier, index-gateway, ruler, compactor: Valores individuales para desplegar un solo componente para el modelo de despliegue de microservicios.
El argumento target ayudará para un tipo de despliegue on-premises. Aún así, si estás usando Helm para la instalación, Loki ya proporciona diferentes charts de helm para los otros modelos de despliegue:
- Chart de Helm para el Modelo Escalable Simple: https://github.com/grafana/helm-charts/tree/main/charts/loki-simple-scalable
- Chart de Helm para el Modelo de Microservicios: https://github.com/grafana/helm-charts/tree/main/charts/loki-distributed
- Chart de Helm para el Modelo Monolítico: https://github.com/grafana/helm-charts/tree/main/charts/loki
Pero todos esos charts de helm se basan en el mismo principio comentado anteriormente sobre definir el rol de cada instancia usando el argumento target, como puedes ver en la imagen a continuación:
