La gestión de operaciones de bases de datos consiste en un 80 % en leer e interpretar sus sistemas de seguimiento. Cientos de métricas se pueden interpretar y combinar de varias maneras para brindarle información detallada sobre sus sistemas de base de datos y cómo optimizarlos. Cuando se ejecutan múltiples sistemas de bases de datos, el monitoreo de estos sistemas puede convertirse en una tarea bastante ardua. Si la interpretación y combinación de métricas toma mucho tiempo, ¿no sería genial si esto pudiera automatizarse de alguna manera?
Es por eso que creamos asesores de bases de datos en ClusterControl:pequeños scripts que pueden interpretar y combinar métricas para usted y brindarle consejos cuando corresponda. Para MySQL, hemos creado una extensa biblioteca de las verificaciones de monitoreo de MySQL más utilizadas. Pero también para MongoDB tenemos una amplia biblioteca de asesores a tu disposición. Para esta publicación de blog, hemos seleccionado los nueve más importantes para usted. Describiremos todos y cada uno de ellos en detalle.
Los nueve asesores de MongoDB que cubriremos en esta publicación de blog son:
- Verificación de opciones de montaje en disco
- Comprobación numérica
- Porcentaje de bloqueo de colección (MMAP)
- Retraso de replicación
- Ventana de replicación
- Bases de datos y colecciones no fragmentadas (solo clúster fragmentado)
- Comprobación de autenticación habilitada
- Comprobación de estado de autenticación/autorización
- Detección de errores (nuevo asesor)
Asesor de opciones de montaje en disco
Es muy importante tener sus discos montados de la manera más óptima. Con el asesor de opciones de montaje en disco de ClusterControl, observamos más de cerca su disco de datos a diario. En este asesor, investigamos el sistema de archivos utilizado, las opciones de montaje y la configuración del programador de io del sistema operativo.
Comprobamos si tus discos han sido montados con noatime y nodiratime. Configurarlos disminuirá el rendimiento de los discos, ya que en cada acceso a un archivo o directorio, la hora de acceso debe escribirse en el disco. Dado que esto sucede continuamente en las bases de datos, esta es una buena configuración de rendimiento y también aumenta la durabilidad de sus SSD.
Para los sistemas de archivos, recomendamos utilizar sistemas de archivos modernos como xfs, zfs, ext4 o btrfs. Estos sistemas de archivos se crean teniendo en cuenta el rendimiento. Se recomienda que el programador de io esté en noop o fecha límite. Fecha límite ha sido el valor predeterminado para las bases de datos durante años, pero gracias a un almacenamiento más rápido como los SSD, noop programador tiene más sentido hoy en día.
Asesor de cheques Numa
Para MongoDB habilitamos nuestro NUMA consultar asesor. Este asesor comprobará si NUMA (Memoria de acceso no uniforme) se ha habilitado en su sistema, y si este es el caso, para apagarlo.
Cuando se ha habilitado la memoria de acceso no uniforme, la CPU del servidor solo puede dirigirse directamente a su propia memoria y no a las otras CPU de la máquina. De esta manera, la CPU solo puede asignar memoria desde su propio espacio de memoria, y asignar cualquier exceso dará como resultado el uso de intercambio. Esta arquitectura tiene un fuerte beneficio de rendimiento en aplicaciones multiprocesador que asignan todas las CPU, pero como MongoDB no es una aplicación multiprocesador, disminuirá considerablemente el rendimiento y podría generar un gran uso de intercambio.
Porcentaje de bloqueo de colección (MMAP)
Como MMAP es un sistema de almacenamiento basado en archivos, no es compatible con el bloqueo de nivel de documento que se encuentra en WiredTiger y RocksDB. En cambio, el nivel más bajo de bloqueo para MMAP es la colección de cerraduras. Esto significa que cualquier escritura en una colección (insertar, actualizar o eliminar) bloqueará toda la colección. Si el porcentaje de bloqueos es demasiado alto, esto indica que tiene problemas de contención en la colección. Cuando no se aborda correctamente, esto podría detener su rendimiento de escritura. Por lo tanto, tener un asesor que le advierta por adelantado es muy útil.
Asesor de retraso de replicación de MongoDB
Si escala MongoDB para lecturas a través de secundarios, es muy importante vigilar el retraso de la replicación. Los controladores del cliente MongoDB solo usarán secundarios que no se retrasen demasiado, de lo contrario, puede correr el riesgo de entregar datos obsoletos.
Dentro de MongoDB, el principal realizará un seguimiento del estado de replicación de sus secundarios. El asesor obtendrá la información de replicación y protegerá el retraso de la replicación. Si el retraso se vuelve demasiado alto, enviará una advertencia o un mensaje de estado crítico.
Asesor de ventana de replicación de MongoDB
Junto al retraso de la replicación, la ventana de replicación es una métrica importante a observar. El registro de operaciones de MongoDB es una colección única, que se ha limitado en un tamaño (preestablecido). Una vez que el registro de operaciones llega al final y se necesita almacenar una nueva transacción, desalojará la transacción más antigua para dejar espacio para la nueva transacción. La ventana de replicación refleja la cantidad de segundos entre la transacción más antigua y la más nueva en el registro de operaciones.
Esta métrica es muy importante, ya que necesita saber durante cuánto tiempo puede sacar un secundario del replicaSet, antes de que ya no pueda ponerse al día con el maestro debido a que está demasiado atrasado en la replicación. Además, si una secundaria comienza a retrasarse, sería bueno saber cuánto tiempo podemos tolerar esto antes de que la secundaria ya no pueda ponerse al día.
En el shell de MongoDB, hay una función disponible para calcular la ventana de replicación. Este asesor en ClusterControl usa la función para hacer el mismo cálculo. El beneficio sería que ahora puede recibir una alerta en una ventana de replicación demasiado corta.
Varios nueves Conviértase en un administrador de bases de datos de MongoDB - Llevando MongoDB a la producción Obtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar MongoDBDescargar gratisMongoDB Un-Sharded Databases and Collections Advisor
En un clúster de MongoDB fragmentado, el enrutador de fragmentos de MongoDB asigna todas las bases de datos y recopilaciones no fragmentadas a un fragmento primario predeterminado. Este fragmento principal puede variar entre las bases de datos y las colecciones, pero en general, este sería el fragmento con la mayor cantidad de espacio disponible en el disco.
Tener una base de datos o una colección sin fragmentar no representa un riesgo inmediato para su clúster. Sin embargo, si una aplicación o un usuario comienza a escribir grandes volúmenes de datos en uno de estos, el fragmento principal podría llenarse rápidamente y crear una interrupción en este fragmento. Como la base de datos o la colección no está fragmentada, no podrá utilizar otros fragmentos.
Por eso hemos creado un asesor que evitará que esto suceda. El asesor escaneará todas las bases de datos y colecciones y le avisará si no se ha fragmentado.
Comprobación de autenticación habilitada
Sin habilitar la autenticación en MongoDB, cualquier usuario que inicie sesión será tratado como administrador. Este es un riesgo serio ya que normalmente las tareas administrativas, como crear usuarios o hacer copias de seguridad, ahora están disponibles para cualquiera. Esto, combinado con los servidores MongoDB expuestos, resultó en los recientes ataques de rescate de MongoDB, mientras que una simple habilitación de la autenticación habría evitado la mayoría de estos casos.
Hemos implementado un asesor que verifica si sus servidores MongoDB tienen habilitada la autenticación. Esto se puede hacer explícitamente estableciendo esto en la configuración, o implícitamente habilitando el archivo de claves de replicación. Si este asesor no detecta que se ha habilitado la autenticación, debe actuar de inmediato, ya que su servidor es vulnerable a verse comprometido.
Comprobación de estado de autenticación/autorización
Además del asesor habilitado para la autenticación, también hemos creado un asesor que realiza una verificación de cordura tanto para la autenticación como para la autorización en MongoDB.
En MongoDB, la autenticación y la autorización no se ubican en una ubicación central, sino que se realizan y almacenan en el nivel de la base de datos. Normalmente, los usuarios se conectarán a la base de datos y se autenticarán en la base de datos que pretenden utilizar. Sin embargo, con las concesiones correctas, también es posible autenticarse en otras bases de datos (no relacionadas) y seguir utilizando otra base de datos. Normalmente esto está perfectamente bien, a menos que un usuario tenga derechos excesivos (como el rol de administrador) sobre otra base de datos.
En este asesor, verificamos si estos roles excesivos están presentes y si podrían representar una amenaza. También verificamos al mismo tiempo si hay contraseñas débiles y fáciles de adivinar.
Detección de errores (nuevo asesor)
En MongoDB, cualquier error encontrado será contado o registrado. Dentro de MongoDB hay una gran variedad de posibles errores:afirmaciones de usuario, afirmaciones regulares, advertencias e incluso excepciones internas del servidor. Si hay tendencias en estos errores, es probable que haya una mala configuración o un problema de aplicación.
Este asesor observará las estadísticas de errores de MongoDB (afirmaciones) y le dará sentido a esto. ¡Interpretamos las tendencias encontradas y damos consejos sobre cómo disminuir los errores en su entorno MongoDB!
