Cortex - aleiis/grafana-stack-validation GitHub Wiki

Cortex es un sistema de almacenamiento de series temporales de alto rendimiento y multi-tenant. Permite almacenar, indexar y consultar métricas. Se trata de una implementación de la API de Prometheus que permite almacenar métricas en un almacenamiento de series temporales distribuido.

Esta sección se centra en explicar el proceso de configuración y la recolección e ingesta de métricas, ya que toda la información sobre los módulos y la implementación de Cortex se puede encontrar en su documentación oficial: https://cortexmetrics.io/

Recolección e ingesta de datos

La recolección e ingesta de datos con Cortex comienza con la configuración de los clientes que envían las métricas y logs hacia Cortex. En nuestro caso, estos clientes son los agentes que van a recopilar métricas sobre los servicios que queremos monitorizar: cAdvisor y MySQL Server Exporter.

Por un lado, cAdvisor recopila métricas sobre los contenedores que tenemos corriendo sobre Docker y las expone en el puerto 8080. Por otro lado, MySQL Server Exporter recopila métricas sobre el rendimiento de la base de datos accediendo a ella con un usuario específico con algunos permisos especiales y las expone en el puerto 9104.

Una vez tenemos los agentes configurados, se debe configurar Prometheus para que haga scraping de estas métricas en los puertos mencionados y las envíe a Cortex. Para lograr esto hay que especificar en el YAML de configuración de Prometheus los endpoints HTTP de los que debe hacer scraping y el endpoint HTTP de Cortex donde debe enviar los datos utilizando el protocolo remote write de Prometheus.

Dentro de Cortex, los datos recogidos son procesados, almacenados e indexados de forma eficiente en una base de datos distribuida diseñada para gestionar grandes volúmenes de métricas de manera eficiente. Si queremos consultar métricas almacenadas en Cortex podermos hacerlo utilizando PromQL sobre el endpoint /prometheus.

Configuración

cAdvisor

No es necesario configurar manualmente cAdvisor para cada contenedor, ya tiene acceso a todo el sistema Docker. Para ello, lo único que hay que hacer es garantizarle acceso a ciertos volúmenes especificados en su documentación.

docker run
--volume=/:/rootfs:ro
--volume=/var/run:/var/run:rw
--volume=/sys/fs/cgroup/cpu,cpuacct:/sys/fs/cgroup/cpuacct,cpu
--volume=/var/lib/docker/:/var/lib/docker:ro
--publish=8080:8080
--detach=true
--name=cadvisor
--privileged=true
google/cadvisor:latest

Además, cAdvisor expone una web UI en su puerto:

http://<hostname>:<port>/

Más información en su repositorio de GitHub: https://github.com/google/cadvisor

MySQL Server Exporter

El primer paso es garantizarle el acceso al exportados a la base de datos. Esto implica crear un usuario de solo lectura con permisos para acceder a las métricas de MySQL. Este usuario puede ser creado ejecutando el siguiente script SQL:

CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'XXXXXXXX' WITH MAX_USER_CONNECTIONS 3;
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';
FLUSH PRIVILEGES;
  • 'exporter' es el nombre del usuario.
  • 'localhost' es el host desde el que se permite la conexión del usuario. En este caso, solo se permitirá la conexión cuando el cliente MySQL esté en el mismo servidor físico o máquina virtual que el servidor MySQL. Si queremos permitir que el usuario se conecte desde cualquier host debemos usar el comodín %.
  • 'XXXXXXXX' es la contraseña del usuario.

Una vez tenemos el usuario creado ya podemos iniciar el exportador para que se conecte a la base de datos y empiece a recopilar métricas. Para ello debemos especificar la dirección, el usuario y la contraseña. En nuestro caso hemos especificado la dirección y el usuario con CLI flags (--mysqld.address y --mysqld.username) y la contraseña con variables de entorno (MYSQLD_EXPORTER_PASSWORD).

Una vez tenemos iniciado el exportador ya podemos hacer scraping en el puerto especificado, por defecto 9104.

Más información en su repositorio de GitHub: https://github.com/prometheus/mysqld_exporter

Prometheus

Prometheus solo necesita un YAML de configuración para poder funcionar. Este fichero debe contener los siguientes apartados:

  • scrape_configs define un conjunto de jobs de los que debe hacer scraping. Cada job define una serie de instancias, que son los endpoints de los que debe hacer scraping. Por ejemplo:
scrape_configs:
- job_name: cadvisor
  static_configs:
  - targets:
    - cadvisor:8080
- job_name: mysql
  static_configs:
  - targets:
    - database-exporter:9104
  • remote_write define una serie de URL donde debe reenviar las métricas tras hacer scraping. Por ejemplo:
remote_write:
  - url: http://cortex:9009/api/v1/push

Cortex

De la misma forma que Prometheus, Cortex solo necesita un YAML de configuración para funcionar. Este fichero especifica en detalle el funcionamiento de Cortex, aunque hay muchos valores que pueden mantenerse por defecto y no es necesario declarar. Existen muchos casos de uso pero en este caso desplegamos Cortex de forma monolítica. Aquí se explican algunas secciones definidas en este caso:

  • target: Define los módulos de Cortex que se deben iniciar y a los que va dirigida esta configuración. En caso de querer desplegar Cortex de forma monolítica debemos usar el comodín all para lanzar solamente los módulos imprescindibles. Además, all es el valor por defecto.

  • auth_enabled: Desactiva la autenticación, lo que significa que no es necesario proporcionar una cabecera X-Scope-OrgID en las solicitudes HTTP, y se utiliza un valor ficticio (fake) por defecto.

  • server: Define la configuración del servidor, como el puerto HTTP en el que escuchará (9009) y parámetros para gestionar el tamaño y la cantidad de mensajes que el servidor puede recibir o enviar a través de gRPC.

  • limits: Establece un límite en la cantidad de nombres de etiquetas por serie de métricas (40 en este caso).

  • distributor: Configura cómo se distribuyen las solicitudes entre los "ingesters". En este caso, se especifica que las solicitudes se distribuyan en función de todas las etiquetas y se habilita la verificación de salud para los ingesters.

  • ingester_client: Configura la comunicación con los "ingesters", estableciendo un tamaño máximo para los mensajes y habilitando la compresión en formato gzip.

  • ingester: Define los parámetros para el "ingester". En este caso, se usa un almacén en memoria para la configuración del anillo de consistencia de estos, y se define un factor de replicación de 1. También especificamos que cada "ingester" debe tener 512 tokens dentro del anillo y que el tiempo en estado "ready" y "leaving" son 0 segundos.

  • blocks_storage: Configura el almacenamiento de bloques. Utiliza almacenamiento en el sistema de archivos local (filesystem), aunque también se pueden usar otros servicios como S3, GCS o Azure. El sistema de archivos local solo debe utilizarse como demostrador, para producción debería configurarse otro servicio.

  • compactor: Define la configuración del "compactor", que se encarga de compactar los bloques del "block storage".

Se puede encontrar más información sobre los módulos y la arquitectura de Cortex en su documentación: https://cortexmetrics.io/docs/

También se pueden encontrar ejemplos de otros casos de uso en su repositorio de GitHub: https://github.com/cortexproject/cortex

Por último, si necesita ayuda para redactar su archivo de configuración puede referirse a la referencia de configuración de Cortex: https://cortexmetrics.io/docs/configuration/configuration-file/

⚠️ **GitHub.com Fallback** ⚠️