Supervisión de una implementación autogestionada de MongoDB

Estrategias de supervisión

MongoDB ofrece varios métodos para recopilar datos sobre el estado de una instancia de MongoDB en ejecución:

• MongoDB distribuye un conjunto de utilidades que proporcionan reporte en tiempo real sobre las actividades de la base de datos.

• MongoDB ofrece varias comandos de base de datos que devuelven estadísticas respecto al estado actual de la base de datos con mayor fidelidad.

• MongoDB Atlas es una base de datos como servicio alojada en la nube para ejecutar, supervisar y mantener implementaciones de MongoDB.

• MongoDB Cloud Manager es un servicio alojado que supervisa las implementaciones de MongoDB en ejecución para recopilar datos y ofrecer visualización y alertas en función de esos datos.

• MongoDB Ops Manager es una solución on-premises disponible en MongoDB Enterprise Advanced que supervisa las implementaciones activas de MongoDB para recopilar datos, proporcionar visualización y emitir alertas basadas en esos datos.

Cada estrategia puede ayudar a responder diferentes preguntas y es útil en distintos contextos. Estos métodos son complementarios.

Herramientas de informes de MongoDB

Esta sección brinda una visión general de los métodos de reporte distribuidos con MongoDB. También ofrece ejemplos de los tipos de preguntas que cada método es más adecuado para ayudarle a abordar.

Registro de procesos

Durante el funcionamiento normal, las instancias mongod y mongos informan de una cuenta activa de toda la actividad y operaciones del servidor ya sea en la salida estándar o en una entrada de registro. Los siguientes ajustes de ejecución controlan estas opciones.

• quiet. Limita la cantidad de información escrita en el registro o de salida.

• verbosity. Aumenta la cantidad de información escrita en el registro o salida. También puedes modificar el nivel de verbosidad del registro durante el tiempo de ejecución con el parámetro logLevel o el método db.setLogLevel() en la shell.

• path. Permite el registro en un archivo, en lugar de en la salida estándar. Debe especificar la ruta completa de la entrada de registro al ajustar esta configuración.

• logAppend. Agrega información a un archivo de registro en lugar de sobrescribir el archivo.

mongod -v --logpath /var/log/mongodb/server1.log --logappend

Los siguientes comandos de base de datos también afectan el registro:

• getLog. Muestra los mensajes recientes del registro de procesos mongod.

• logRotate. Rota las entradas de registro solo para los procesos de mongod. Consulta Rotar archivos de registro.

db.clients.insertOne( { "name" : "Joe", "PII" : "Sensitive Information" } )

{
   "t": { "$date": "2024-07-19T15:36:55.024-07:00" },
   "s": "I",
   "c": "COMMAND",
   ...
   "attr": {
      "type": "command",
      ...
      "appName": "mongosh 2.2.10",
      "command": {
         "insert": "clients",
         "documents": [
            {
               "name": "Joe",
               "PII": "Sensitive Information",
               "_id": { "$oid": "669aea8792c7fd822d3e1d8c" }
            }
         ],
         "ordered": true,
         ...
      }
      ...
   }
}

{
   "t": { "$date": "2024-07-19T15:36:55.024-07:00" },
   "s": "I",
   "c": "COMMAND",
   ...
   "attr": {
      "type": "command",
      ...
      "appName": "mongosh 2.2.10",
      "command": {
         "insert": "###",
         "documents": [
            {
               "name": "###",
               "PII": "###",
               "_id": "###"
            }
         ],
         "ordered": "###",
         ...
      }
      ...
   }
}

Diagnóstico de problemas de rendimiento

Al desarrollar y operar aplicaciones con MongoDB, es posible que desees analizar el rendimiento tanto de la base de datos como de la aplicación. MongoDB Performance discute algunos de los factores operativos que pueden influir en el rendimiento.

Replicación y supervisión

Además de los requisitos básicos de monitorización para cualquier instancia de MongoDB, en el caso de los conjuntos de réplicas, los administradores deben monitorizar el retardo de replicación. El "retardo de replicación" se refiere al tiempo que se tarda en copiar (es decir, replicar) una operación de escritura del servidor principal al secundario. Un pequeño retraso puede ser aceptable, pero surgen problemas importantes a medida que aumenta el retardo de replicación, como:

• Aumenta la presión del caché en el nodo primario.

• Las operaciones que ocurrieron durante el período de retraso no se replican en uno o más secundarios. Si utilizas la replicación para garantizar la persistencia de los datos, retrasos excepcionalmente largos pueden afectar la integridad de tu conjunto de datos.

• Si el atraso de la replicación supera la longitud del operation log (oplog), entonces MongoDB tendrá que realizar una sincronización inicial en el secundario, copiando todos los datos del primario y reconstruyendo todos los índices. [1] Esto es poco común en circunstancias normales, pero si se configura el oplog para que sea más pequeño que el valor por defecto, puede surgir este problema.

  Nota

  El tamaño del oplog solo se puede configurar durante la primera ejecución utilizando el argumento --oplogSize para el comando mongod, o, de preferencia, la configuración oplogSizeMB en el archivo de configuración de MongoDB. Si no especifica esto en la línea de comandos antes de ejecutar con la opción --replSet, mongod creará un oplog de tamaño por defecto.

  De forma predeterminada, el registro 5 de operaciones representa el por ciento del espacio de disco disponible en 64sistemas de bits. Para obtener más información sobre cómo cambiar el tamaño del registro de operaciones, consulte Cambiar el tamaño del registro de operaciones de los miembros del conjunto de réplicas autoadministradas.

rs.status()

Particionado y supervisión

En la mayoría de los casos, los componentes de los clústeres fragmentados se benefician de la misma supervisión y análisis que todas las demás instancias de MongoDB. Además, los clústeres requieren un mayor supervisión para garantizar que los datos se distribuyan eficazmente entre los nodos y que las operaciones de particionamiento funcionen de manera adecuada.

use config
db.locks.find()

db.locks.find( { _id : "balancer" } )

Vigilante del nodo de almacenamiento

El nodo de almacenamiento Watchdog monitorea los siguientes directorios de MongoDB para detectar falta de respuesta del sistema de archivos:

• El directorio --dbpath

• El directorio journal dentro del directorio --dbpath

• El directorio del archivo --logpath

• El directorio del archivo --auditPath

Por defecto, el Watchdog del nodo de almacenamiento está deshabilitado. Solo puedes habilitar el Watchdog de nodos de almacenamiento en un mongod durante el inicio configurando el parámetro watchdogPeriodSeconds a un número entero mayor o igual a 60. Sin embargo, una vez habilitado, puedes pausar el watchdog del nodo de almacenamiento y reiniciarlo durante el tiempo de ejecución. Consulte el parámetro watchdogPeriodSeconds para más detalles.

Si alguno de los sistemas de archivos que contienen los directorios monitoreados deja de responder, el sistema de vigilancia del nodo de almacenamiento finaliza el mongod y sale con un código de estado de 61. Si el mongod es el principal de un conjunto de réplicas, la finalización inicia una conmutación por error, lo que permite que otro miembro se convierta en principal.

Una vez que un mongod haya terminado, puede que no sea posible reiniciarlo limpiamente en la misma máquina.

El tiempo máximo que el Watchdog del nodo de almacenamiento puede tardar en detectar un sistema de archivos no receptivo y finalizar es casi dos veces el valor de watchdogPeriodSeconds.