Esta pagina se ve mejor con JavaScript habilitado

PMM2 Redis

 ·  🎃 kr0m

Como ya sabemos Prometheus permite la monitorización de un amplio abanico de servicios, esta monitorización se lleva a cabo mediante determinados exporters que colectan las métricas consumidas por Prometheus, en este artículo explicaré como montar dos servidores Redis en modo master/slave y como monitorizarlos mediante PMM2.

Compilamos e instalamos Redis:

emerge -av dev-db/redis

Habilitamos el servicio en el arranque:

rc-update add redis default
/etc/init.d/redis start

En el master bindeamos el servicio a todas las ips y le asignamos un password de acceso:

vi /etc/redis.conf

bind 0.0.0.0
requirepass PASSWORD

Aplicamos la configuración reiniciando el servicio:

/etc/init.d/redis restart

En el slave realizamos la misma configuración que en el master pero además le indicamos quién es su master y con que password conectar a este:

vi /etc/redis.conf

bind 0.0.0.0
requirepass PASSWORD
slaveof MASTER_IP 6379
masterauth PASSWORD

Aplicamos la configuración reiniciando el servicio:

/etc/init.d/redis restart

Comprobamos que el slave esté sincronizado con el master:

redis-cli -a PASSWORD info

# Replication  
role:slave  
master_host:MASTER_IP  
master_port:6379  
master_link_status:up

En la lista de exporters de la web de Prometheus podemos encontrar el exporter de Redis .

Compilamos e instalamos las dependencias para compilar el exporter:

emerge -av dev-lang/go dev-vcs/git

Nos bajamos el exporter y lo compilamos:

mkdir go
export GOPATH=/root/go
export GOPATH=$(go env GOPATH)
go get github.com/oliver006/redis_exporter
cd /root/go/bin/
export REDIS_PASSWORD=PASSWORD

Arrancamos manualmente el exporter para comprobar que no haya ningún problema:

./redis_exporter

Creamos un script de arranque:

vi /etc/local.d/redis_exporter.start

nohup /root/go/bin/redis_exporter --redis.password=PASSWORD --web.listen-address=127.0.0.1:9121 &

Le asignamos los permisos necesarios y arrancamos el servicio:

chmod 700 /etc/local.d/redis_exporter.start
/etc/local.d/redis_exporter.start

Comprobamos que se haya bindeado a la dirección ip correcta:

netstat -nputa|grep LISTEN|grep 9121

tcp        0      0 127.0.0.1:9121          0.0.0.0:*               LISTEN      5526/redis_exporter 

Comprobamos que en local podamos obtener las métricas:

curl http://127.0.0.1:9121/metrics|grep -v ‘#’

Para proteger el acceso al exporter por password utilizaremos la autenticación de Nginx:

emerge -av www-servers/nginx

Configuramos Nginx para que pida password si la petición no proviene del servidor PMM:

vi /etc/nginx/nginx.conf

...
server {
  listen SERVER_IP:9121;
  server_name _;

  location / {
      satisfy any;
      allow  PMM_SERVER_IP/32;
      auth_basic "Restricted Content";
      auth_basic_user_file /etc/nginx/.htpasswd;
      deny all;
      
      proxy_pass http://127.0.0.1:9121;
  }
}
...

Generamos el fichero de passwords:

emerge -av app-admin/apache-tools
htpasswd -c /etc/nginx/.htpasswd admin

Reiniciamos Nginx:

/etc/init.d/nginx restart

Comprobamos que desde el servidor PMM no pida password:

curl http://SERVER_IP:9121/metrics|grep -v ‘#’

Desde cualquier otra localización si que debería de pedir password:

curl --user admin:PASSWORD http://SERVER_IP:9121/metrics|grep -v ‘#’

Telegrambot y la API de PMM necesitan la etiqueta node_name para identificar correctamente el servidor y que las alarmas aparezcan con el la información correcta:

vi prometheusConf/prometheus.base.yml

scrape_configs:
- job_name: redis_exporter
  static_configs:
  - targets:
    - SERVER1:9121
    - SERVER2:9121
  relabel_configs:
  - source_labels: [__address__]
    target_label: node_name

NOTA: La source_label la podemos averiguar si vamos a Status -> Targets y mantenemos el cursor encima de las labels.

Recargamos la configuración de PMM:

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

Las alertas de Prometheus serían estas, recordad que en PMM2 las alertas se configuran desde Grafana( http://pmm.alfaexploit.com/graph/d/pmm-settings/) :

- name: redisRules
  rules:
  - alert: RedisDown
    expr: redis_up == 0
    for: 5m
    labels:
      severity: critical
  - alert: RedisMem
    expr: redis_memory_used_bytes > (60 * node_memory_MemTotal) / 100
    for: 5m
    labels:
      severity: critical
  - alert: RedisRejectingConnections
    expr: delta(redis_rejected_connections_total[1m]) > 5
    for: 5m
    labels:
      severity: critical
  - alert: BrokenRedisSlave
    expr: redis_master_last_io_seconds == -1
    for: 5m
    labels:
      severity: critical
  - alert: BrokenRedisSlave
    expr: redis_master_last_io_seconds_ago == -1
    for: 5m
    labels:
      severity: critical

Recargamos la configuración de PMM:

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

Si paramos un master por ejemplo, saltarán las alarmas de RedisDown por el master y BrokenRedisSlave por el slave:

Si hemos seguido la guía sobre Alertmanager  veremos en Telegram alertas como esta:

Importamos en grafana el template de redis para ver las gráficas de las métricas:


Pegamos el json del template :

Le damos a Load.

Asignamos un nombre al dashboard:

Le damos a Import.

El resultado final es este:

Si te ha gustado el artículo puedes invitarme a un RedBull aquí