Monitoreo de una implementación de MongoDB autogestionada

Estrategias de seguimiento

MongoDB proporciona 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 informes en tiempo real de las actividades de la base de datos.

• MongoDB ofrece varias comandos de base de datos que devuelven estadísticas sobre el 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 monitorea las implementaciones de MongoDB en ejecución para recopilar datos y proporcionar visualización y alertas basadas en esos datos.

• MongoDB Ops Manager es una solución local disponible en MongoDB Enterprise Advanced que monitorea las implementaciones de MongoDB en ejecución para recopilar datos y proporcionar visualización y 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 ofrece una descripción general de los métodos de generación de informes distribuidos con MongoDB. También ofrece ejemplos de los tipos de preguntas que cada método puede abordar mejor.

Registro de procesos

Durante el funcionamiento normal, mongod las instancias mongos y reportan un registro en tiempo real de toda la actividad y operaciones del servidor, ya sea a la salida estándar o a un archivo de registro. Las siguientes configuraciones de tiempo de ejecución controlan estas opciones.

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

• verbosity. Aumenta la cantidad de información que se escribe en el registro o la salida. También puede modificar el nivel de detalle del registro durante la ejecución con el parámetro logLevel db.setLogLevel() o el método del shell.

• pathPermite el registro en un archivo, en lugar de la salida estándar. Debe especificar la ruta completa del archivo de registro al configurar 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 mensajes recientes del mongod registro del proceso.

• logRotate. Rota los archivos de registro solo para procesos.mongod Consulte 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 desee analizar el rendimiento de la base de datos como aplicación. EnMongoDB Performance, se describen algunos de los factores operativos que pueden influir en el rendimiento.

Replicación y Monitoreo

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:

• Creciente presión de caché en el servidor principal.

• Las operaciones realizadas durante el periodo de retardo no se replican en uno o más servidores secundarios. Si utiliza la replicación para garantizar la persistencia de los datos, los retrasos excepcionalmente largos pueden afectar la integridad de su 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 registro de operaciones solo se puede configurar durante la primera ejecución mediante el argumento--oplogSizedel comandomongodo, preferiblemente, la opciónoplogSizeMBdel archivo de configuración de MongoDB. Si no se especifica esto en la línea de comandos antes de ejecutar con la opción--replSet, mongodcreará un registro de operaciones de tamaño predeterminado.

  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()

Fragmentación y monitorización

En la mayoría de los casos, los componentes de los clústeres fragmentados se benefician de la misma monitorización y análisis que las demás instancias de MongoDB. Además, los clústeres requieren una monitorización adicional para garantizar que los datos se distribuyan eficazmente entre los nodos y que las operaciones de fragmentación funcionen correctamente.

use config
db.locks.find()

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

Vigilante del nodo de almacenamiento

El perro guardián del nodo de almacenamiento 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

De forma predeterminada, el sistema de vigilancia del nodo de almacenamiento está deshabilitado. Solo puede habilitarlo en unmongodal iniciar el sistema configurando el parámetrowatchdogPeriodSecondscon un entero mayor o igual a 60. Sin embargo, una vez habilitado, puede pausar el sistema de vigilancia del nodo de almacenamiento y reiniciarlo durante la ejecución. Consulte el parámetrowatchdogPeriodSecondspara obtener más información.

Si alguno de los sistemas de archivos que contienen los directorios supervisados ​​deja de responder, el sistema de vigilancia del nodo de almacenamiento finaliza el y sale con el código mongod de 61 estado. Si el es mongod 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 el principal.

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

El tiempo máximo que puede tardar el Storage Node Watchdog en detectar un sistema de archivos que no responde y finalizar es casi el doble del valor watchdogPeriodSeconds de.