- \n
- Qu\u00e9 es la monitorizaci\u00f3n de bases de datos<\/a><\/li>\n
- Por qu\u00e9 es importante monitorizar bases de datos<\/a><\/li>\n
- Database Performance Monitoring vs Database Activity Monitoring<\/a><\/li>\n
- M\u00e9tricas clave en la monitorizaci\u00f3n de bases de datos<\/a><\/li>\n
- Monitorizaci\u00f3n seg\u00fan el tipo de base de datos<\/a><\/li>\n
- Problemas habituales que detecta la monitorizaci\u00f3n<\/a><\/li>\n
- Buenas pr\u00e1cticas para monitorizar bases de datos<\/a><\/li>\n
- Qu\u00e9 debe tener una herramienta de monitorizaci\u00f3n de bases de datos<\/a><\/li>\n
- Monitorizaci\u00f3n de bases de datos, observabilidad y CMDB<\/a><\/li>\n
- C\u00f3mo ayuda Pandora FMS a monitorizar bases de datos<\/a><\/li>\n
- Preguntas frecuentes<\/a><\/li>\n
- Conclusi\u00f3n<\/a><\/li>\n<\/ul>\n
[\/et_pb_text][\/et_pb_column][et_pb_column type=\u00bb3_4″ _builder_version=\u00bb4.27.0″ _module_preset=\u00bbdefault\u00bb custom_css_main_element=\u00bbz-index:0!important;\u00bb global_colors_info=\u00bb{}\u00bb][et_pb_text admin_label=\u00bbseccion\u00bb module_id=\u00bb1″ module_class=\u00bbittopicscontent\u00bb _builder_version=\u00bb4.27.5″ _module_preset=\u00bbdefault\u00bb z_index=\u00bb0″ custom_margin=\u00bb0px||0px||true|false\u00bb custom_padding=\u00bb0px||0px||false|false\u00bb custom_css_main_element=\u00bbfont-family:%22Pandora-Light%22;\u00bb locked=\u00bboff\u00bb global_colors_info=\u00bb{}\u00bb]Cuando John Lennon cantaba que vivir es f\u00e1cil con los ojos cerrados, se nota que no trabajaba en tecnolog\u00eda, donde la ceguera es la primera estrofa del desastre. Es imposible gestionar lo que no ves<\/strong>. Por eso, lo primero en IT es obtener claridad total sobre lo que ocurre en nuestra infraestructura. Y dentro de ella, la base de datos es uno de los subsistemas m\u00e1s cr\u00edticos<\/strong>. De ah\u00ed la importancia de su monitorizaci\u00f3n.
\nSi la base de datos cae, se pone en marcha el domin\u00f3 que nos arruina la semana, porque lo siguiente en desmoronarse son las aplicaciones, luego los clientes, los informes, las automatizaciones y, finalmente, la moral y cordura del equipo de guardia.
\nPor eso, esta gu\u00eda recorre qu\u00e9 es la monitorizaci\u00f3n de bases de datos, qu\u00e9 m\u00e9tricas controlar, qu\u00e9 problemas detecta<\/strong>, qu\u00e9 buenas pr\u00e1cticas aplicar y c\u00f3mo encaja en nuestra estrategia global de observabilidad.
\nCon ella, seremos due\u00f1os de un Palantir que nos permitir\u00e1 saber todo y, m\u00e1s importante a\u00fan, actuar a tiempo antes de que las inevitables chispas se conviertan en incendio.<\/p>\nQu\u00e9 es la monitorizaci\u00f3n de bases de datos<\/h2>\n
Comencemos con la inevitable teor\u00eda.
\nLa monitorizaci\u00f3n de bases de datos consiste en supervisar de manera continua la disponibilidad, rendimiento, consultas, conexiones, almacenamiento, replicaci\u00f3n, errores y capacidad<\/strong> de los motores que sostienen nuestros datos cr\u00edticos. El objetivo es detectar problemas antes de que afecten al servicio<\/strong>.
\nO dicho de otro modo, ser El guardi\u00e1n entre el centeno y no esperar a que el usuario nos grite amablemente que la web va lenta. Antes de llegar a ese punto, una monitorizaci\u00f3n nos debe permitir detectar y corregir.<\/p>\n![](\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\")
<\/p>\nVisi\u00f3n general y consolidada de MySQL en Pandora FMS, que permite controlar visual y r\u00e1pidamente el estado de las bases de datos<\/p>\n
Por qu\u00e9 es importante monitorizar bases de datos<\/h2>\n
Las razones son tan obvias como ignoradas a menudo:<\/p>\n
- \n
- Reducir ca\u00eddas de servicio:<\/Strong> al ver que se produce una saturaci\u00f3n de conexiones antes de que esta colapse el servicio.<\/li>\n
- Detectar cualquier degradaci\u00f3n antes de que llegue al usuario<\/strong>: as\u00ed, una consulta que pasa de 50 ms a 800 ms es un aviso sobre el que actuar antes de que se convierta en problema.<\/li>\n
- Evitar saturaci\u00f3n de almacenamiento<\/strong>: porque el espacio en disco se suele llenar despacio cuando nadie mira, en lugar de golpear de pronto.<\/li>\n
- Optimizar consultas y recursos:<\/strong> identificando las queries que nos est\u00e1n gripando el motor de la BBDD.<\/li>\n
- Anticipar problemas de capacidad<\/strong>: sabiendo cu\u00e1nto nos queda antes de pelearnos con finanzas para conseguir m\u00e1s hardware o un scale-out.<\/li>\n
- Reducir el MTTR<\/strong>: principalmente, consiguiendo que el equipo deje de apagar fuegos con una venda en los ojos.<\/li>\n
- Entender dependencias<\/strong> entre base de datos, aplicaci\u00f3n, servidor y red.<\/li>\n<\/ul>\n
Ahora est\u00e1 de moda el concepto de \u00abCaja Negra\u00bb en IT y, sin monitorizaci\u00f3n, la base de datos se convierte en una<\/strong> que solo da se\u00f1ales de vida cuando deja de darlas. Entonces, solo queda correr con un desfibrilador como en esas series de m\u00e9dicos donde todos se l\u00edan con todos.<\/p>\n
Database Performance Monitoring vs Database Activity Monitoring<\/h2>\n
Cuando la monitorizaci\u00f3n de bases de datos sale a la palestra, estos dos enfoques la acompa\u00f1an y conviene conocerlos y no mezclarlos:<\/p>\n
- \n
- Database Performance Monitoring (DPM)<\/strong>: es una monitorizaci\u00f3n orientada al rendimiento y las operaciones. As\u00ed, controla latencias, consultas lentas, throughput, conexiones, locks, uso de CPU, memoria, disco y red, replicaci\u00f3n, almacenamiento y disponibilidad. Es decir, que es lo que se entiende habitualmente por \u00abmonitorizar la base de datos\u00bb.<\/li>\n
- Database Activity Monitoring (DAM)<\/strong>: en este caso, la monitorizaci\u00f3n est\u00e1 orientada a actividad, seguridad y auditor\u00eda. De este modo, observa accesos a datos, usuarios y sesiones, consultas sensibles, cambios no autorizados, comportamiento an\u00f3malo y cumplimiento normativo.<\/li>\n<\/ul>\n
Sabiendo esto, esta gu\u00eda se centra en el primer enfoque DPM de rendimiento, disponibilidad y operaci\u00f3n<\/strong>, aunque conviene saber que la monitorizaci\u00f3n de actividad tambi\u00e9n forma parte de una estrategia completa cuando hay requisitos regulatorios o de auditor\u00eda.<\/p>\n
M\u00e9tricas clave en la monitorizaci\u00f3n de bases de datos<\/h2>\n
<\/p>\nSelecci\u00f3n de m\u00e9tricas en Pandora FMS para monitorizar una base de datos Oracle<\/p>\n
En la pr\u00e1ctica, una monitorizaci\u00f3n proporciona m\u00e9tricas, pero claro, en la vida siempre ha habido clases y no todas deben pesar lo mismo en nuestras decisiones.
\nEso y que un dashboard lleno de gr\u00e1ficas que nadie mira solamente es ruido caro.
\nPor eso, este es el grano que debemos separar de la paja y tener siempre vigilado.<\/p>\nDisponibilidad y estado del servicio<\/h3>\n
Lo primero a controlar es que las BBDD funcionen, obviamente. Eso implica indicadores clave como:<\/p>\n
- \n
- Uptime<\/Strong> o disponibilidad del motor.<\/li>\n
- Respuesta a chequeos de salud<\/Strong>.<\/li>\n
- Errores <\/Strong>de conexi\u00f3n.<\/li>\n
- Estado<\/Strong> de nodos o instancias en cl\u00faster.<\/li>\n<\/ul>\n
Rendimiento<\/h3>\n
Adem\u00e1s de que funcionen, nos pagan para que lo hagan eficazmente <\/strong>y no arrastren los pies en las consultas. Esto implica el control de m\u00e9tricas como:<\/p>\n
- \n
- Latencia<\/strong> de dichas consultas.<\/li>\n
- Tiempo de respuesta<\/strong> medio y percentil 95\/99.<\/li>\n
- Consultas lentas<\/strong> (slow queries).<\/li>\n
- Throughput<\/strong> en consultas por segundo.<\/li>\n
- Locks, deadlocks y waits<\/strong>.<\/li>\n<\/ul>\n
Uso de recursos<\/h3>\n
Eficacia y eficiencia no son lo mismo y queremos las dos cosas, de modo que funcionar r\u00e1pidamente no implique que los procesadores se calienten m\u00e1s que el Sol <\/strong>o desperdiciar una memoria RAM que ya vale m\u00e1s que mis ri\u00f1ones.
\nPara eso controlamos:<\/p>\n- \n
- CPU<\/strong> consumida por el motor.<\/li>\n
- Memoria<\/strong> usada y libre (buffer pool y cach\u00e9).<\/li>\n
- Disco<\/strong> (espacio libre, IOPS, latencia…).<\/li>\n
- Red<\/strong> (tr\u00e1fico y errores).<\/li>\n<\/ul>\n
Conexiones y sesiones<\/h3>\n
Aqu\u00ed nos interesa el qui\u00e9n, c\u00f3mo y cu\u00e1nto del uso<\/strong>, lo que implica conocer:<\/p>\n
- \n
- Conexiones activas<\/strong> y m\u00e1ximas configuradas.<\/li>\n
- Saturaci\u00f3n del pool <\/strong>de conexiones.<\/li>\n
- Sesiones bloqueadas <\/strong>o en espera.<\/li>\n<\/ul>\n
Almacenamiento y crecimiento<\/h3>\n
Las bases de datos tienden a lo mismo que yo, engordar misteriosamente<\/strong>, sobre todo, cuando nadie mira lo que hago.
\nPara evitar que nuestras BBDD lo ocupen todo como los tribbles de Star Trek, debemos vigilar:<\/p>\n- \n
- Tama\u00f1o<\/strong> de bases de datos y tablas.<\/li>\n
- Crecimiento<\/strong> por unidad de tiempo.<\/li>\n
- Espacio libre<\/strong> en tablespaces o vol\u00famenes.<\/li>\n
- Estado de \u00edndices <\/strong>(uso, fragmentaci\u00f3n).<\/li>\n
- Volumen de logs<\/strong> (transaccionales y de aplicaci\u00f3n).<\/li>\n<\/ul>\n
Replicaci\u00f3n, clustering y alta disponibilidad<\/h3>\n
Estos indicadores son esenciales en la monitorizaci\u00f3n de una gesti\u00f3n moderna<\/strong> de BBDD:<\/p>\n
- \n
- Lag de replicaci\u00f3n<\/strong> para evitar que los usuarios accedan a datos desactualizados.<\/li>\n
- Estado de r\u00e9plicas<\/strong> y si est\u00e1n en l\u00ednea, retrasadas o ca\u00eddas.<\/li>\n
- Failover y conmutaciones<\/strong> para los casos de fallos, emergencias o mantenimientos.<\/li>\n
- Sincronizaci\u00f3n de nodos<\/strong> para verificar la coherencia de los datos entre ellos y asegurar que el quorum est\u00e9 activo para mantener la integridad del sistema.<\/li>\n<\/ul>\n
Backups y recuperaci\u00f3n<\/h3>\n
No importa que seamos los mejores y m\u00e1s r\u00e1pidos, el desastre nos alcanzar\u00e1 eventualmente, as\u00ed que tambi\u00e9n tenemos que ser humildes y trabajar con red (de seguridad, no de Internet, aunque esa tambi\u00e9n).
\nPara ello, debemos controlar:<\/p>\n- \n
- El estado del \u00faltimo backup<\/strong>.<\/li>\n
- Antig\u00fcedad de la \u00faltima copia correcta<\/strong>, lo que de verdad alimenta nuestro Objetivo de Punto de Recuperaci\u00f3n (RPO por sus siglas en ingl\u00e9s).<\/li>\n
- Errores <\/strong>en procesos de copia.<\/li>\n
- Duraci\u00f3n de la \u00faltima restauraci\u00f3n de prueba<\/strong>. Esta es la forma honesta de validar el RTO (Objetivo de Tiempo de Recuperaci\u00f3n), porque un backup que no se restaura es una falsa ilusi\u00f3n de seguridad.<\/li>\n<\/ul>\n
Monitorizaci\u00f3n seg\u00fan el tipo de base de datos<\/h2>\n
<\/p>\nPandora FMS monitorizando un cl\u00e1sico intemporal corporativo, una base de datos IBM DB2<\/p>\n
Igual que las m\u00e9tricas no son iguales entre s\u00ed, las bases de datos tampoco<\/Strong>. As\u00ed, cada modelo de dichos datos pide su propio enfoque de monitorizaci\u00f3n<\/strong>.
\nSi bien aqu\u00ed no puedo entrar a fondo en la explicaci\u00f3n de cada uno (a ver, poder puedo, pero convertir\u00eda esto en La historia interminable), tienes una gu\u00eda completa de los tipos de bases de datos<\/A>. All\u00ed cubrimos la taxonom\u00eda y aqu\u00ed nos centramos en qu\u00e9 vigilar en cada caso.
\nComo veremos, habr\u00e1 cosas comunes a todas las BBDD (como la disponibilidad o latencia, por ejemplo) y otras m\u00e1s concretas del tipo de base de datos, como el traversal o tiempo de recorrido si hablamos de bases de datos de grafos.<\/p>\nBases de datos relacionales<\/h3>\n
Aqu\u00ed incluimos MySQL, PostgreSQL, Oracle, SQL Server o MariaDB<\/strong> y es raro que en nuestra infraestructura IT no tengamos una (o varias m\u00e1s bien) de estas.
\nAqu\u00ed hay que enfatizar:<\/p>\n- \n
- Consultas <\/strong>lentas.<\/li>\n
- Locks.<\/li>\n
- Conexiones<\/strong>.<\/li>\n
- \u00cdndices.<\/li>\n
- Replicaci\u00f3n<\/strong>.<\/li>\n
- Almacenamiento.<\/li>\n
- Transacciones.<\/li>\n<\/ul>\n
Por supuesto, el primer paso para arrancar son sus documentaciones oficiales: PostgreSQL<\/A>, MySQL<\/A>, SQL Server<\/a> y Oracle<\/a>.<\/p>\n
Bases de datos NoSQL documentales<\/h3>\n
En este caso suenan nombres como MongoDB, Couchbase o RavenDB<\/strong>. Aqu\u00ed es prioritario controlar:<\/p>\n
- \n
- Operaciones<\/strong> por segundo.<\/li>\n
- Uso de memoria.<\/li>\n
- Replicaci\u00f3n<\/strong>.<\/li>\n
- \u00cdndices.<\/li>\n
- Tiempos <\/strong>de consulta.<\/li>\n
- Errores.<\/li>\n
- Crecimiento<\/strong> de colecciones.<\/li>\n<\/ul>\n
Para ello, MongoDB tiene documentaci\u00f3n espec\u00edfica<\/a> y en esta gu\u00eda sobre c\u00f3mo monitorizar RavenDB<\/a> entramos al detalle para echarte una mano.
\nPor otra parte, si quieres una visi\u00f3n m\u00e1s amplia del lado no relacional de las BBDD, esta gu\u00eda de bases de datos NoSQL<\/a> traza un buen dibujo del panorama.<\/p>\nBases de datos clave-valor y cach\u00e9<\/h3>\n
Redis o Riak <\/strong>salen a jugar al campo en este caso y debemos vigilar bien:<\/p>\n
- \n
- Memoria <\/strong>consumida.<\/li>\n
- Expiraci\u00f3n <\/strong>de claves por TTL (expired keys).<\/li>\n
- Expulsiones<\/strong> por presi\u00f3n de memoria (las llamadas evictions que, ojo, no son lo mismo que las expiraciones).<\/li>\n
- Fallos y aciertos del cache.<\/li>\n
- Persistencia.<\/li>\n
- Conexiones.<\/li>\n
- Latencia<\/strong>.<\/li>\n<\/ul>\n
- Expiraci\u00f3n <\/strong>de claves por TTL (expired keys).<\/li>\n
- Antig\u00fcedad de la \u00faltima copia correcta<\/strong>, lo que de verdad alimenta nuestro Objetivo de Punto de Recuperaci\u00f3n (RPO por sus siglas en ingl\u00e9s).<\/li>\n
- Estado de r\u00e9plicas<\/strong> y si est\u00e1n en l\u00ednea, retrasadas o ca\u00eddas.<\/li>\n
- Crecimiento<\/strong> por unidad de tiempo.<\/li>\n
- Saturaci\u00f3n del pool <\/strong>de conexiones.<\/li>\n
- Memoria<\/strong> usada y libre (buffer pool y cach\u00e9).<\/li>\n
- Tiempo de respuesta<\/strong> medio y percentil 95\/99.<\/li>\n
- Respuesta a chequeos de salud<\/Strong>.<\/li>\n
- Database Activity Monitoring (DAM)<\/strong>: en este caso, la monitorizaci\u00f3n est\u00e1 orientada a actividad, seguridad y auditor\u00eda. De este modo, observa accesos a datos, usuarios y sesiones, consultas sensibles, cambios no autorizados, comportamiento an\u00f3malo y cumplimiento normativo.<\/li>\n<\/ul>\n
- Detectar cualquier degradaci\u00f3n antes de que llegue al usuario<\/strong>: as\u00ed, una consulta que pasa de 50 ms a 800 ms es un aviso sobre el que actuar antes de que se convierta en problema.<\/li>\n
- Por qu\u00e9 es importante monitorizar bases de datos<\/a><\/li>\n
![](\"https:\/\/pandorafms.com\/wp-content\/uploads\/2024\/12\/agentes-y-modulos-mysql.png\")
<\/p>\n![](\"https:\/\/pandorafms.com\/wp-content\/uploads\/2025\/08\/Oracle-032025.png\")
<\/p>\n![](\"https:\/\/pandorafms.com\/wp-content\/uploads\/2025\/08\/metricas-aws-b.png\")
<\/p>\n![](\"https:\/\/pandorafms.com\/wp-content\/uploads\/2026\/06\/Captura-pfms.png\")
<\/p>\n