Percona Monitoring and Management o PMM es un conjunto de herramientas que nos permitirán monitorizar de forma rápida y sencilla nuestros servidores y en especial las bases de datos, si habilitamos todas las opciones nos mostrará muchísima información útil acerca de querys lentas, bloqueos y demás problemas relacionados con MySQL y MongoDB.

La monitorización de las métricas se realiza mediante Prometheus y la visualización de estas mediante Grafana .

Toda la instalación se realizará sobre Docker ya que simplifica tanto la instalación como las futuras actualizaciones del servidor.

Creamos una user-denfined network para poder utilizar los nombres de los CTs directamente, cuando reiniciemos CTs las direcciones ip cambiarán pero no tendremos que tocar la configuración gracias a haber utilizado nuestra user-defined network, en una instalación básica este aspecto no tiene importancia pero cuando configuremos Alertmanager sí que resultará de utilidad:

Actualizar a PMM2 no permite la migración de los datos antiguos, se debe reinstalar todo desde cero.

PMM necesita aproximadamente 1Gb de almacenamiento por cada base de datos a monitorizar con una retención de una semana, en cuanto a RAM se necesitan 2Gb por cada servidor de base de datos pero este requisito no es lineal por ejemplo para 20 nodos se necesitan 16Gb, no 40.

Actualmente el versionado de PMM funciona del siguiente modo:

• pmm-server:latest -> Indica la última release de la rama PMM 1.X
• pmm-server:2 -> Indica la última release de la rama PMM 2

Nos bajamos la imagen de Docker de PMM2:

Creamos el CT donde se almacenarán los datos de PMM, este no estará corriendo tan solo nos servirá como CT de almacenamiento, en actualizaciones futuras borraremos el CT de PMM pero los datos persistirán entre actualizaciones ya que estos residen en este otro CT.

Creamos el CT PMM y mapeamos el fichero prometheus.base.yml este nos permitirá poder realizar una configuración personalizada de Prometheus, ahora por ahora lo dejamos vacío, tan solo lo creamos:

Accedemos a la interfaz web de PMM:
http://PMM_IP (admin/admin)

Cambiamos el password

Realizamos la configuración básica de PMM:

PMM -> PMM Settings

Ajustamos los parámetros según nuestras necesidades:

Configuramos la URL del Alertmanager, en futuros artículos explicaré como montarlos, ahora por ahora tan solo lo dejamos configurado y pegamos las reglas de las alertas:

Alertmanager URL:
http://pmm-alertmanager:9093

Alertmanager rules:

groups:
- name: genericRules
  rules:
  - alert: BrokenNodeExporter
    expr: up{agent_type="node_exporter"} == 0
    for: 5m
    labels:
      severity: critical

Reiniciamos el PMM:

NOTA: El reinicio de Prometheus es un proceso pesado, tarda bastante(4m) en volver a estar operativa la interfaz web.

Comprobamos desde la interfaz de Prometheus que las reglas estén cargadas:

Status -> Rules

En Alerts podremos ver la lista de alertas:

También podemos comprobar dentro del CT que el fichero contenga las alarmas definidas:

rule_files:
- /srv/prometheus/rules/*.rules.yml

groups:
- name: genericRules
  rules:
  - alert: BrokenNodeExporter
    expr: up{agent_type="node_exporter"} == 0
    for: 5m
    labels:
      severity: critical

El cliente se instala del siguiente modo:

Ubuntu:

Gentoo:

Añadimos los binarios instalados al path:

Hacemos el cambio permanente:

Para que los exporters funcionen primero hay que configurar/arrancar el agente:

Si hacemos un setup incorrecto la segunda vez que lo ejecutemos nos dirá:

Failed to register pmm-agent on PMM Server: Node with name "kr0mtest" already exists..

Tendremos que añadir la opción: –force al comando

Arrancamos manualmente el pmm-agent para comprobar que no da ningún problema:

En otra consola podemos ver los exporters:

Service type  Service name         Address and port  Service ID

Agent type                  Status     Agent ID                                        Service ID
pmm_agent                   Connected  /agent_id/aba88792-1544-420a-a091-cbffe93f9232 
node_exporter               Running    /agent_id/d35f58b3-a4e8-4367-8659-d726adf3641a

Demonizamos el agente:

En la interfaz de Grafana ya podremos ver datos:

En PMM2 se han cambiado bastantes cosas respecto a la versión anterior, una de ellas es que realiza varios colectas(scraps) de los datos a distintas frecuencias, los datos que habitualmente cambian se colectan con mayor frecuencia y los mas estáticos con menor frecuencia, esto presenta un problema cuando salta una alarma, aparece tripliclada:

job="node_exporter_agent_id_d35f58b3-a4e8-4367-8659-d726adf3641a_hr-5s"
job="node_exporter_agent_id_d35f58b3-a4e8-4367-8659-d726adf3641a_mr-10s"
job="node_exporter_agent_id_d35f58b3-a4e8-4367-8659-d726adf3641a_lr-1m0s"

Hay que unificar las alarmas cuando agent_id, agent_type, alertname, alertname, machine_id, node_id, node_id, node_name, node_type y severity coincidan.

En la captura podemos ver la alarma triplicada, si le damos al enlace de la expresión nos llevará al ejecutor de querys.

Aquí podemos ir adaptando las querys hasta que cuadren con las alertas que necesitemos, en este caso si unificamos por node_name solo saca un resultado:

sum(up{agent_type="node_exporter"} == 0) by (node_name)

Modificamos la configuración de las alertas:

Alertmanager rules:

groups:
- name: genericRules
  rules:
  - alert: BrokenNodeExporter
    expr: sum(up{agent_type="node_exporter"} == 0) by (node_name)
    for: 5m
    labels:
      severity: critical

Reiniciamos el PMM:

Ahora las alertas ya salen unificadas:

TROUBLESHOOTING
Ver los logs del CT:

Información útil del CT:

Para saber si estamos colectando correctamente una métrica podemos consultarla en la interfaz de Prometheus, Status -> Targets pero nos pedirá autenticación, el usuario es siempre pmm y el password el id del exporter que estemos consultando.

Consultamos los exporters en el servidor:

Service type  Service name         Address and port  Service ID

Agent type                  Status     Agent ID                                        Service ID
pmm_agent                   Connected  /agent_id/d94f4797-68df-4832-835f-e2b742f3a189  
node_exporter               Running    /agent_id/7e985a11-eb50-4c7a-9569-834666c3a934

En este caso solo hay uno cuyo password es: /agent_id/7e985a11-eb50-4c7a-9569-834666c3a934

También se puede consultar en la interfaz web de Prometheus en la etiqueta agent_id:

UPDATE
Comprobamos la versión del PMM actual:

Paramos el PMM actual y renombramos el CT:

Nos bajamos la última versión de PMM:

Arrancamos el nuevo PMM reutilizando el CT de almacenamiento de datos, de este modo no hay pérdida de métricas entre actualizaciones:

Comprobamos que esté corriendo la versión correcta:

Eliminamos el backup:

También se puede actualizar desde la interfaz web(corre un playbook de Ansible) pero si la versión está bugeada no habrá marcha atrás:
http://PMMSERVER/graph/d/pmm-home/home-dashboard

Podemos leer las notas de lanzamiento de las versiones aquí .

NOTA: En caso de reinstalación total del padre(servidor Docker) habrá que hacer backup de cualquier fichero que importemos dentro del CT y del CT de datos.