PMM2 Vol0


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:

docker network create --driver bridge pmm-net

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:

docker pull percona/pmm-server:2

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.

docker create -v /srv --name pmm-data percona/pmm-server:2 /bin/true

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:

touch prometheusConf/prometheus.base.yml
docker run -d -p 80:80 -p 443:443 -v $PWD/prometheusConf/prometheus.base.yml:/srv/prometheus/prometheus.base.yml --volumes-from pmm-data --dns 8.8.8.8 --dns-search=alfaexploit.com --network=pmm-net --name pmm-server --restart always percona/pmm-server:2

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:

docker stop pmm-server && docker start pmm-server

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:

docker exec -it pmm-server bash
[root@c848f5caa91c ~]# cat /etc/prometheus.yml
rule_files:
- /srv/prometheus/rules/*.rules.yml
[root@c848f5caa91c ~]# cat /srv/prometheus/rules/pmm.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:

wget https://repo.percona.com/apt/percona-release_latest.generic_all.deb
dpkg -i percona-release_latest.generic_all.deb
apt-get update
apt-get install pmm2-client
pmm-admin config --server-insecure-tls --server-url=https://admin:PASSWORD@PMM_SERVER:443

Gentoo:

wget https://www.percona.com/downloads/pmm2/2.6.1/binary/tarball/pmm2-client-2.6.1.tar.gz
tar xvzf pmm2-client-2.6.1.tar.gz
cd pmm2-client-2.6.1
./install_tarball

Añadimos los binarios instalados al path:

PATH=$PATH:/usr/local/percona/pmm2/bin

Hacemos el cambio permanente:

cd
echo "PATH=$PATH:/usr/local/percona/pmm2/bin" >> .bashrc
echo "export BASH_ENV=~/.bashrc" >> .bash_profile
echo "if [ -f ~/.bashrc ]; then source ~/.bashrc; fi" >> .bash_profile

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

pmm-agent setup --config-file=/usr/local/percona/pmm2/config/pmm-agent.yaml --server-insecure-tls --server-address=PMM_SERVER:443 --server-username=admin  --server-password="PASSWORD"

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:

pmm-agent --config-file=/usr/local/percona/pmm2/config/pmm-agent.yaml

En otra consola podemos ver los exporters:

pmm-admin list
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:

echo "nohup pmm-agent --config-file=/usr/local/percona/pmm2/config/pmm-agent.yaml &" > /etc/local.d/pmm.start
chmod 700 /etc/local.d/pmm.start

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:

docker stop pmm-server && docker start pmm-server

Ahora las alertas ya salen unificadas:


TROUBLESHOOTING

Ver los logs del CT:

docker logs -f pmm-server
docker exec -it pmm-server /bin/bash
tail /srv/logs/pmm-managed.log

Información útil del CT:

docker inspect pmm-server

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:

pmm-admin list
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:

curl -k -u admin:PASSWORD -X POST "https://PMM_SERVER/v1/Updates/Check" | jq

Paramos el PMM actual y renombramos el CT:

docker stop pmm-server
docker rename pmm-server pmm-server-backup

Nos bajamos la última versión de PMM:

docker pull percona/pmm-server:2

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

docker run -d -p 80:80 -p 443:443 -v $PWD/prometheusConf/prometheus.base.yml:/srv/prometheus/prometheus.base.yml --volumes-from pmm-data --dns 8.8.8.8 --dns-search=alfaexploit.com --network=pmm-net --name pmm-server --restart always percona/pmm-server:2

Comprobamos que esté corriendo la versión correcta:

docker ps
curl -k -u admin:PASSWORD -X POST "https://PMM_SERVER/v1/Updates/Check" | jq

Eliminamos el backup:

docker rm pmm-server-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.

Si te ha gustado el artículo puedes invitarme a un redbull aquí.
Si tienes cualquier pregunta siempre puedes enviarme un Email o escribir en el grupo de Telegram de AlfaExploit.
Autor: kr0m -- 15/04/2020 23:24:12 -- Categoria: Monitoring