Loki es un sistema de agregación de logs creado por GrafanaLabs, es escalable horizontalmente, puede contar con alta disponibilidad y está inspirado en Prometheus.

A menudo es comparado con el stack ELK (Elasticsearch, Logstash y Kibana), resaltando su facilidad de configuración y ahorro de costes. Éste está basado en Elasticsearch, un servicio que va mucho más allá de la agregación y búsqueda de logs. Por el contrario, Loki se centra únicamente en los logs.

Una diferencia importante es que en el caso de Loki no se está indexando el contenido de los logs, sino metadatos de los mismos en forma de labels.

Otra de las ventajas de Loki es que puede utilizar múltiples sistemas de almacenamiento, incluyendo almacenamiento de objetos. Esto hace que sea ideal para mantener grandes cantidades de log con un coste reducido al utilizar servicios como AWS S3 o Google Cloud Storage.

El stack de Loki está compuesto por varias piezas de software, siendo la principal Loki. A continuación describimos sus componentes:

• Promtail: Es el agente que se instala en las instancias de las cuales queremos obtener logs y se encarga de enviarlos al servicio de Loki. Además de enviar los logs, podemos parsearlos y modificar los labels que se han obtenido dinámicamente de las trazas. Este componente del stack no es estrictamente necesario. De hecho, si ya contamos con algún otro agente shipper de logs configurado, como por ejemplo Logstash del stack ELK, podemos utilizarlo también junto con Loki por medio de un plugin.
• Loki: Es el servicio principal que se encarga de almacenar los logs y ejecutar las queries sobre ellos. A su vez, está dividido en múltiples componentes que pueden ser configurados de forma independiente.
• Grafana: El producto estrella de Grafana Labs utilizado por multitud de proyectos, como por ejemplo PMM. Este dashboard se utiliza para lanzar las queries a Loki y visualizar los resultados.

Hemos mencionado que el servicio de Loki se divide a su vez en múltiples componentes. Estos pueden ser divididos y ejecutados independientemente, llegando a escalar horizontalmente cada uno de ellos. A este tipo de despliegue de loki se le llama modo microservicios.

Es especialmente útil cuando se está tratando con un gran volumen de datos, cuando se hace un uso intensivo del servicio a nivel de queries o en general cuando se requiere tener control sobre alguno de los componentes.

Este modo aumenta notablemente la complejidad de la configuración, pero es el que ofrece un mayor rendimiento. Está especialmente pensado para utilizarse en Kubernetes y Grafana Labs contando con un chart de Helm para su despliegue.

Imagen de Grafana, fuente. The Grafana Labs Marks are trademarks of Grafana Labs, and are used with Grafana Labs’ permission. We are not affiliated with, endorsed or sponsored by Grafana Labs or its affiliates

Errores comunes

Uno de los problemas más comunes en los despliegues pequeños de Loki, es decir, con un único nodo y pocos cientos de GB de logs, es recibir errores en Grafana al hacer búsquedas en un rango de tiempo elevado. Esto se debe a que tanto Grafana como Loki cuentan con múltiples configuraciones de timeouts en su arquitectura que pueden estar tirando la query que ejecutamos. Es una medida de seguridad para frenar queries que no están respondiendo correctamente.

Dependiendo de la versión de Loki y Grafana que estemos utilizando podemos llegar a ver errores como 502 y 504, context canceled, error processing requests Unknown error during query transaction.

Para poder diagnosticar estos errores es necesario tener acceso al log de Loki, donde sí obtendremos más información.

En estos casos, el problema viene habitualmente por el servidor http del servicio de loki que se encarga de recibir la respuesta de la query, que es ejecutada por el servicio de querier. Estos timeouts están configurados por defecto a 30s. Una vez aumentado este valor, podemos seguir teniendo problemas ya que es la propia query la que llega al valor de tiemout y se corta. Por defecto, el timeout de las queries es de un minuto.

Las variables a editar en la configuración de Loki son:

querier.query_timeout
server.http_server_read_timeout
server.http_server_write_timeout
server.http_server_idle_timeout

No es recomendable configurar unos valores de timeouts muy elevados ya que puede ser contraproducente cuando sí que se esté produciendo un problema con las queries.

Si se ve necesario configurar un valor alto puede ser un síntoma de que el despliegue actual de Loki no está cubriendo las necesidades. En este caso habría que considerar pasar a un despliegue de microservicios donde se puede escalar el componente encargado de ejecutar las queries, querier.

Si te ha interesado este articulo no dudes en decírnoslo en nuestras redes sociales para que continuemos creando más contenido sobre Loki, Grafana y la observabilidad en la nube.