Loki: recopilación de registros utilizando el enfoque de Prometeo

Saludo, Khabrovites! En previsión del inicio de un nuevo conjunto para el curso de Prácticas y herramientas de DevOps, hemos preparado para usted una traducción de material interesante.





Este artículo es una breve introducción a Loki. El proyecto Loki es apoyado por Grafana y tiene como objetivo recopilar registros de forma centralizada (desde servidores o contenedores).

La principal fuente de inspiración para Loki fue Prometeo con la idea de aplicar sus enfoques de gestión de registros:

  • uso de etiquetas (etiquetas) para el almacenamiento de datos
  • bajo consumo de recursos

Volveremos a los principios de Prometeo y daremos algunos ejemplos de su uso en el contexto de Kubernetes.

Algunas palabras sobre Prometeo


Para comprender completamente cómo funciona Loki, es importante dar un paso atrás y recordar un poco a Prometeo.

Una de las características distintivas de Prometheus es la extracción de métricas de los puntos de recolección (a través de exportadores) y su almacenamiento en TSDB (Base de datos de series temporales, base de datos de series temporales) con la adición de metadatos en forma de etiquetas.

Por qué es necesario


Recientemente, Prometheus se ha convertido en el estándar de facto en el mundo de los contenedores y Kubernetes: su instalación es muy simple, y el clúster de Kubernetes inicialmente tiene un punto final para Prometheus. Prometheus también puede recuperar métricas de aplicaciones implementadas en un contenedor, mientras retiene ciertas etiquetas. Por lo tanto, el monitoreo de aplicaciones es muy fácil de implementar.

Desafortunadamente, todavía no existe una solución llave en mano para administrar registros, y debe encontrar una solución para usted:

  • servicio en la nube administrado para centralizar registros (AWS, Azure o Google)
  • monitoreo como servicio de monitoreo de servicio (por ejemplo, Datadog)
  • creando su propio servicio de recopilación de registros.

Para la tercera opción, tradicionalmente utilicé Elasticsearch, a pesar de que no siempre estaba contento con él (especialmente su gravedad y complejidad de la configuración).

Loki fue diseñado para simplificar la implementación de acuerdo con los siguientes principios:

  • ser fácil de comenzar
  • consume pocos recursos
  • trabajar independientemente sin ningún mantenimiento especial
  • Complementar Prometeo para ayudar a investigar errores

Sin embargo, esta simplicidad se logra a través de algunos compromisos. Una de ellas es no indexar contenido. Por lo tanto, la búsqueda de texto no es muy efectiva o rica y no permite estadísticas sobre el contenido del texto. Pero como Loki quiere ser el equivalente de grep y complementar el Prometeo, esto no es un defecto.

Investigación del incidente


Para comprender mejor por qué Loki no necesita indexación, volvamos al método de investigación de incidentes utilizado por los desarrolladores de Loki:


1 Alerta → 2 Panel de control → 3 Adhoc Query → 4 Agregación de registros → 5 Seguimiento distribuido → 6 ¡Arreglar!
(1 Advertencia → 2 Paneles → 3 Consulta adhoc → 4 Agregación de registros → 5 Seguimiento distribuido → 6 Corrección!)


La idea es que recibamos alguna alerta (Notificación de holgura, SMS, etc.) y después de eso:

  • Grafana
  • (, Prometheus)
  • (, Elasticsearch)
  • , (Jaeger, Zipkin .)
  • , , .

Aquí, en el caso de la pila Grafana + Prometheus + Elasticsearch + Zipkin, tendrás que usar cuatro herramientas diferentes. Para reducir el tiempo, sería bueno poder realizar todos estos pasos con una herramienta: Grafana. Vale la pena señalar que este enfoque de investigación se ha implementado en Grafana desde la versión 6. Por lo tanto, es posible acceder a los datos de Prometheus directamente desde Grafana.


Pantalla del explorador dividida entre Prometheus y Loki

En esta pantalla, puede ver los registros de Loki relacionados con las métricas de Prometheus utilizando el concepto de pantalla dividida. A partir de la versión 6.5, Grafana le permite procesar la identificación de rastreo en las entradas de registro de Loki para seguir los enlaces a sus herramientas de rastreo distribuidas favoritas (Jaeger).

Prueba local de Loki


La forma más fácil de probar Loki localmente es usar docker-compose. El archivo docker-compose está en el repositorio de Loki. Puede obtener el repositorio utilizando el siguiente comando git:

$ git clone https://github.com/grafana/loki.git


Luego debe ir al directorio de producción:

$ cd production

Después de eso, puede obtener la última versión de las imágenes de Docker:

$ docker-compose pull

Finalmente, la pila Loki se inicia con el siguiente comando:

$ docker-compose up

Arquitectura Loki


Aquí hay un pequeño diagrama con la arquitectura Loki:


Principios de la arquitectura Loki El

cliente web lanza aplicaciones en el servidor, Promtail recopila registros y los envía a Loki, el cliente web también envía metadatos a Loki. Loki agrega todo y lo transfiere a Grafana.
Loki está en marcha. Para ver los componentes disponibles, ejecute el siguiente comando:

$ docker ps


En el caso de un Docker recién instalado, el comando debería devolver el siguiente resultado:

IMAGE               PORTS                  NAMES
grafana/promtail:                          production_promtail_1
grafana/grafana: m  0.0.0.0:3000->3000/tcp production_grafana_1
grafana/loki: late  80/tcp,0.0.0.0:3100... production_loki_1

Vemos los siguientes componentes:

  • Promtail: agente para centralizar registros
  • Grafana: una herramienta de tablero famosa
  • Loki: un demonio de centralización de datos

Dentro del marco de una infraestructura clásica (por ejemplo, basada en máquinas virtuales), se debe implementar un agente Promtail en cada máquina. Grafana y Loki se pueden instalar en la misma máquina.

Despliegue de Kubernetes


La instalación de los componentes de Loki en Kubernetes será la siguiente:

  • daemonSet para implementar el agente Promtail en cada máquina en un clúster de servidores
  • Despliegue Loki
  • y, por último, el despliegue de Grafana.

Afortunadamente, Loki está disponible como un paquete Helm, lo que facilita su implementación.

Instalación a través de Helm


Helm ya debería estar instalado. Se puede descargar desde el repositorio de GitHub del proyecto. Se instala desempacando el archivo que coincide con su arquitectura y agregando timón $PATH.

Nota: Helm versión 3.0.0 se lanzó recientemente. Dado que hubo muchos cambios, se recomienda al lector que espere un poco antes de usarlo primero .


Agregar una fuente para Helm


El primer paso es agregar el repositorio "loki" con el siguiente comando:

$ helm add loki https://grafana.imtqy.com/loki/charts

Después de eso, puede buscar paquetes llamados "loki":

$ helm search loki

Resultado:

loki/loki       0.17.2 v0.4.0 Loki: like Prometheus, but for logs.
loki/loki-stack 0.19.1 v0.4.0 Loki: like Prometheus, but for logs.
loki/fluent-bit 0.0.2  v0.0.1 Uses fluent-bit Loki go plugin for...
loki/promtail   0.13.1 v0.4.0 Responsible for gathering logs and...

Estos paquetes tienen las siguientes características:

  • el paquete loki / loki solo coincide con el servidor Loki
  • El paquete loki / fluent-bit le permite implementar DaemonSet usando fluent-bin para recopilar registros en lugar de Promtail
  • paquete loki / promtail contiene un agente de recopilación de archivos de registro
  • El paquete loki / loki-stack le permite implementar inmediatamente Loki junto con Promtail.

Instalación de Loki


Para implementar Loki en Kubernetes, ejecute el siguiente comando en el espacio de nombres "monitoreo":

$ helm upgrade --install loki loki/loki-stack --namespace monitoring

Para guardar en el disco, agregue la opción --set loki.persistence.enabled = true:

$ helm upgrade --install loki loki/loki-stack \
              --namespace monitoring \
              --set loki.persistence.enabled=true

Nota: si desea implementar Grafana al mismo tiempo, agregue el parámetro--set grafana.enabled = true

Cuando ejecuta este comando, debe obtener el siguiente resultado:

LAST DEPLOYED: Tue Nov 19 15:56:54 2019
NAMESPACE: monitoring
STATUS: DEPLOYED
RESOURCES:
==> v1/ClusterRole
NAME AGE
loki-promtail-clusterrole 189d
NOTES:
The Loki stack has been deployed to your cluster. Loki can now be added as a datasource in Grafana.
See <a href="http://docs.grafana.org/features/datasources/loki/">http://docs.grafana.org/features/datasources/loki/</a> for more details.

Al observar el estado de los hogares en el espacio de nombres de "monitoreo", veremos que todo se expande:

$ kubectl -n monitoring get pods -l release=loki

Resultado:

NAME                 READY  STATUS   RESTARTS  AGE
loki-0               1/1    Running  0         147m
loki-promtail-9zjvc  1/1    Running  0         3h25m
loki-promtail-f6brf  1/1    Running  0         11h
loki-promtail-hdcj7  1/1    Running  0         3h23m
loki-promtail-jbqhc  1/1    Running  0         11h
loki-promtail-mj642  1/1    Running  0         62m
loki-promtail-nm64g  1/1    Running  0         24m

Todas las vainas están funcionando. ¡Ahora es el momento de hacer algunas pruebas!

Conectar a Grafana


Para conectarte a Grafana bajo Kubernetes, debes abrir un túnel en su parte inferior. El siguiente es el comando para abrir el puerto 3000 para el hogar de Grafana:

$ kubectl -n port-forward monitoring svc/loki-grafana 3000:80

Otro punto importante es la necesidad de recuperar la contraseña de administrador de Grafana. La contraseña se mantiene loki-grafanaen secreto en un campo .data.admin-useren formato base64.

Para restaurarlo, debe ejecutar el siguiente comando:

$ kubectl -n monitoring get secret loki-grafana \
 --template '{{index .data "admin-password" | base64decode}}'; echo

Use esta contraseña con la cuenta de administrador predeterminada (admin).

Definiendo una fuente de datos Loki en Grafana


En primer lugar, asegúrese de que se haya creado la fuente de datos Loki (Configuración / Fuente de datos).
Aquí hay un ejemplo:


Ejemplo de configuración de una fuente de datos para Loki

Al hacer clic en "Prueba" puede verificar la conexión con Loki.

Hacer solicitudes a Loki


Ahora ve a la sección "Explorar" de Grafana. Al recibir registros de contenedores, Loki agrega metadatos de Kubernetes. Por lo tanto, se hace posible ver los registros de un contenedor específico.

: Por ejemplo, el siguiente promtail de consulta se utilizará para seleccionar los registros del contenedor {container_name = "promtail"}.
Además, asegúrese de seleccionar su fuente de datos Loki aquí.

Esta solicitud devolverá la actividad de los contenedores de la siguiente manera:


El resultado de la solicitud en Grafana

Agregar al tablero


Comenzando con Grafana 6.4, puede poner información sobre los registros directamente en el tablero. Después de eso, el usuario podrá cambiar rápidamente entre el número de solicitudes en su sitio a los rastreos de la aplicación.

El siguiente es un ejemplo de un tablero que implementa esta interacción: Un


ejemplo de un tablero con métricas de Prometheus y registros de Loki

Futuro loki


Comencé a usar Loki en mayo / junio con la versión 0.1. Hoy ya se lanzó la versión 1, e incluso 1.1 y 1.2.

Es cierto que la versión 0.1 no era lo suficientemente estable. Pero 0.3 ya mostró signos reales de madurez, y las próximas versiones (0.4, luego 1.0) solo fortalecieron esta impresión.

Después de 1.0.0, nadie puede tener excusas para no usar esta maravillosa herramienta.

Las mejoras adicionales no deberían afectar a Loki, sino más bien su integración con la excelente Grafana. De hecho, Grafana 6.4 ya tiene una buena integración con paneles.

Grafana 6.5, que se lanzó recientemente, mejora aún más esta integración al reconocer automáticamente el contenido de los registros en formato JSON.

El siguiente video muestra un pequeño ejemplo de este mecanismo:


Uso de cadenas de Loki mostradas en Grafana

Se hace posible usar uno de los campos JSON, por ejemplo, para:

  • enlaces a herramientas externas
  • filtrado de contenido de registro

Por ejemplo, puede hacer clic en traceId para ir a Zipkin o Jaeger.

Tradicionalmente, esperamos sus comentarios y lo invitamos a un seminario web abierto , donde hablaremos sobre cómo se desarrolló la industria DevOps durante 2019 y discutiremos las posibles vías de desarrollo para 2020.

Source: https://habr.com/ru/post/undefined/


All Articles