Los replicasets de MongoDb nos proporcionan alta disponibilidad y balanceo de las lecturas pero esto no es la panacea ya que si algún nodo del RS está funcionando incorrectamente las lecturas realizadas serán mas lentas de lo normal, mediante PMM y query analytics seremos capaces de detectar este tipo de problemas y actuar en consecuencia.

Continuando con la instalación de un RS de MongoDb vamos a montar la monitorización de este.

PRIMARY

Accedemos a la CLI de MongoDb para crear el usuario de monitorización:

Creamos el usuario de monitorización:

use admin
db.getSiblingDB("admin").createUser({
    user: "pmm",
    pwd: "PASSWORDMONIT",
    roles: [
        { role: "clusterMonitor", db: "admin" },
        { role: "readAnyDatabase", db: "admin" }
    ]
})

NOTA: Si utilizamos un arbitro, debemos recordar que el arbitro NO replica datos, por lo tanto no tendrá el usuario utilizado por PMM2 y será imposible crearlo manualmente ya que no es PRIMARY, en tal caso no es posible monitorizarlo con PMM2. De todos modos el uso de arbitros en Mongo está desaconsejado.

TODOS

Si queremos una monitorización básica simplemente añadimos el exporter:

Pero si queremos utilizar el query analyzer de Percona tendremos que habilitar el log de las queries, para ello tendremos que arrancar MongoDb con ciertos parámetros:

Los parámetros son los siguientes:

• profile: Si su valor es 0 no se realizará profiling alguno, si su valor es 1 se logearán las queries que tarden mas de slowms, si su valor es 2 se logearán todas las queries.
• slowms: Umbral a partir del cual se logeará la query si profile está a 1.
• slowOpSampleRate: Valor de 0 a 1, indica el ratio de slowqueries a logear.

Estos parámetros se pueden indicar en el fichero de configuración de MongoDb:

operationProfiling:
    mode: slowOp
    slowOpThresholdMs: 200
    slowOpSampleRate: 0.2

El parámetro mode permite varios valores:

• off: Logging de queries deshabilitado
• slowOp: Se logean solo las queries slow
• all: Se logean todas las queries

Reiniciamos el servicio:

Añadimos el exporter de MongoDb indicando el usuario y password de monitorización:

Comprobamos que se haya añadido el exporter:

En targets podemos ver los 3 exporters:

En grafana las gráficas del RS:

NOTA: Si ya teníamos alguno de los nodos monitorizado antes de meterlo en el RS, habrá que eliminar el exporter y volver a ponerlo.

Las alertas de BrokenMongoDBExporter tendrán una severidad de warning ya que en un RS hay varios nodos.

- name: mongoDbRules
  rules:
  - alert: BrokenMongoDBExporter
    expr: up{service_type="mongodb"} == 0
    for: 5m
    labels:
      severity: warning

  - alert: MongoDBRplSetProblem
    expr: sum(mongodb_mongod_replset_member_health == 0) by (name)
    for: 5m
    labels:
      severity: warning

NOTA: Si en la alerta no hacemos el sum by (name) cuando caiga un nodo del RS saldrán varias alertas, una por cada nodo que siga activo.

Podemos ver la alerta al apagar un nodo del RS:

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

La monitorización normal en PMM funciona en base a un exporter que se instala en el servidor, pero si no tenemos acceso a este servidor cabe la posibilidad de monitorizar la base datos mediante un acceso a la base de datos:

PMM2: Remote services monitoring – monitor MySQL, PostgreSQL, and MongoDB from PMM Server without the need for client installation