Guía de configuración de monitorización de bases de datos

Antes de empezar

Las comprobaciones de base de datos no se ejecutan desde la red pública distribuida de monitorización de HostTracker como sí lo hace una comprobación Http o Ping, así que este formulario no tiene ninguna sección de Ubicaciones de monitorización. En su lugar, cada comprobación marca a tu servidor desde la propia infraestructura privada de comprobación de HostTracker, usando dos direcciones de origen fijas: 4.207.101.172 y 20.107.152.200 (norte de Europa). Antes de guardar el monitor, añade ambas direcciones a la lista de permitidos del firewall o del grupo de seguridad de tu servidor de base de datos, y asegúrate de que el servidor acepta conexiones en su puerto desde internet público, o al menos desde esas dos direcciones. Si el puerto no es accesible, cada comprobación falla con un error de conexión sin importar cómo esté configurado el resto del monitor.

Configura la propia cuenta de monitorización antes de empezar: crea un usuario de base de datos dedicado a la comprobación, concédele solo lo que la comprobación necesita (normalmente solo la capacidad de conectar, más SELECT sobre la tabla que toque tu consulta), y evita reutilizar una cuenta de aplicación o de administrador. Si la consulta que planeas ejecutar cambia datos, dale a esa cuenta acceso de escritura solo a la tabla concreta implicada, nada más amplio.

Base de datos objetivo

Tres campos identifican a qué se conecta la comprobación, y están encima de las secciones plegables porque son obligatorios:

• Server type: un desplegable con los proveedores admitidos: Microsoft SQL Server, Oracle, MySQL, PostgreSQL y Firebird.
• Server : Port: el nombre de host o la IP del servidor de base de datos, y su puerto. Cambiar el tipo de servidor rellena automáticamente el puerto por defecto habitual de ese proveedor (1433 para SQL Server, 1521 para Oracle, 3306 para MySQL, 5432 para PostgreSQL, 3050 para Firebird); solo hace falta sobrescribirlo si tu servidor escucha en otro puerto.
• Database (o, para Oracle, Service e Instance name (SID) en su lugar): el nombre de la base de datos a la que conectar. Para Oracle puedes indicar el nombre del servicio, el SID, o ambos, según cómo esté configurado tu listener.

Debajo, un campo opcional de Nombre te deja etiquetar el monitor para alertas, informes y widgets, útil en cuanto tienes más de una comprobación de base de datos y necesitas distinguirlas de un vistazo.

Configuración principal

Este grupo contiene el calendario y los dos interruptores de propósito general que comparte cada tipo de comprobación:

• Intervalo: con qué frecuencia se ejecuta la comprobación, ofrecido desde 10 minutos hasta 24 horas (10, 15, 30, 45 minutos, y luego 1, 2, 4, 6, 12 y 24 horas), más una alternativa de calendario por cron para una cadencia menos regular. Las comprobaciones de base de datos no ofrecen los intervalos por debajo de 10 minutos que sí ofrecen otros tipos de comprobación.
• Etiquetas: etiquetas de texto libre para agrupar y filtrar monitores en otras partes del panel.
• Registro completo: guarda cada resultado individual de la comprobación en lugar de solo resúmenes agrupados, útil cuando necesitas ver los tiempos de respuesta o los valores exactos a lo largo del tiempo en lugar de solo el historial de activo/caído.
• Abrir estadísticas: hace compartible la página de estadísticas y registro de este monitor, incluso con personas que no han iniciado sesión.

Conexión

Con el objetivo ya fijado arriba, esta sección cubre cómo se autentica la comprobación y cómo maneja un intento de conexión fallido:

• DB user name y DB user password: las credenciales de la cuenta de monitorización descrita arriba. Ambos son opcionales: déjalos en blanco si tu base de datos permite una conexión de confianza o anónima desde una dirección en la lista de permitidos, algo que hacen algunas configuraciones internas.
• El propio panel muestra las dos direcciones de origen desde las que se hacen las comprobaciones (4.207.101.172, 20.107.152.200) con un recordatorio de incluirlas en la lista de permitidos del firewall de tu base de datos; es el mismo requisito cubierto en Antes de empezar, repetido aquí porque es exactamente donde viven las credenciales.
• Retry on connect fail: un interruptor, activado por defecto, que reintenta el intento de conexión una vez antes de marcar la comprobación como fallida. Solo cubre el propio paso de conexión, no la consulta.

Validación de respuesta

Esta es la decisión clave en una comprobación de base de datos: si estás probando que la conexión funciona, o que una consulta concreta se sigue comportando como se espera.

• Query: déjalo vacío y la comprobación solo prueba la conexión: se abre y se cierra, y esa es toda la comprobación. Rellénalo con cualquier SQL que tu cuenta de monitorización tenga permiso de ejecutar (un SELECT, o una sentencia que cambie datos como UPDATE, DELETE o INSERT) y la comprobación lo ejecuta en cada sondeo y puede juzgar el resultado.
• Query result (solo se muestra una vez que se introduce una consulta): elige Scalar value para leer lo que haya en la primera columna de la primera fila devuelta (la opción natural para un SELECT, o para un UPDATE/INSERT que use una cláusula OUTPUT), o Row count para leer cuántas filas se vieron afectadas (la opción natural para un UPDATE, DELETE o INSERT simple sin conjunto de resultados propio).
• Result verification: una comparación que aplicar a ese valor: No verification (la consulta solo tiene que ejecutarse sin error), Equal to, Not equal to, Greater than, Less than, In range, u Out of range. Las opciones de mayor/menor que y de rango añaden uno o dos campos numéricos, con un interruptor de incluido/excluido en cada límite del rango.
• Retry query on error: un interruptor, activado por defecto, que reintenta la ejecución de la consulta una vez si falla, independiente del reintento a nivel de conexión de arriba.

Elige solo conexión cuando lo único que necesitas saber es que la base de datos es accesible y acepta conexiones; detecta las caídas totales. Elige una consulta con verificación de resultado cuando la simple accesibilidad se perdería el problema real: una tabla que dejó de recibir filas nuevas, un contador guardado que se sale de un rango normal, o un dato concreto que siempre debería estar presente.

Suscripciones de alerta

Elige qué contactos se enteran de este monitor y para qué eventos: Up, Down y Repeat (un recordatorio repetido mientras la comprobación sigue en Down). Un único interruptor suscribe a todos los contactos a Up/Down a la vez, o puedes elegir contactos y eventos individuales en la tabla de debajo.

Suscripciones de informes

Aparte de las alertas, elige quién recibe informes periódicos de uptime y rendimiento de este monitor (diarios, semanales o mensuales) por correo.

Ejemplo resuelto

Vigilar una base de datos PostgreSQL de producción de la que depende una aplicación: Server type PostgreSQL, Server : Port db.example.com:5432, Database myapp_prod. Se introduce una cuenta dedicada de solo lectura en Conexión, y primero se añaden ambas IP de origen al grupo de seguridad de la base de datos. El campo Query lleva SELECT COUNT(*) FROM orders WHERE created_at > now() - interval '1 hour', Query result es Scalar value, y Result verification es Greater than con un límite de 0: si no se ha registrado ningún pedido en la última hora, algo aguas arriba ha dejado de escribir, y la comprobación pasa a Down aunque la base de datos sea accesible. El intervalo es de 15 minutos, ambos interruptores de reintento se dejan activados para que un fallo pasajero no dispare una falsa alerta, las alertas van a la suscripción Up/Down de todo el equipo, y un informe semanal va al propietario de la cuenta.

Solución de problemas

• Todas las comprobaciones fallan con un error de conexión. La causa más habitual es un firewall que no se ha abierto para las dos direcciones de origen de HostTracker; confirma que 4.207.101.172 y 20.107.152.200 están en la lista de permitidos, y que el propio puerto está abierto para ellas.
• La conexión tiene éxito pero falla la autenticación. Comprueba que el nombre de usuario y la contraseña de la BD son correctos y que la cuenta tiene permiso para conectarse a la base de datos indicada, no solo al servidor.
• Una consulta que funciona bien en una herramienta cliente no devuelve nada aquí. Un UPDATE, DELETE o INSERT simple sin cláusula OUTPUT no tiene ningún conjunto de resultados que leer como Scalar value; cambia Query result a Row count, o añade una cláusula OUTPUT si necesitas recuperar los datos de la fila.
• La verificación de resultado nunca se dispara. Confirma que la comparación y los campos numéricos coinciden con el rango que esperas: un límite fijado como excluido en lugar de incluido es una forma fácil de hacer que un límite nunca se dispare.
• Fallos aislados ocasionales que sospechas que son pasajeros. Ambos interruptores de reintento están activados por defecto y ya reintentan una vez antes de dar la comprobación por fallida; si los fallos siguen siendo frecuentes, el problema es más probablemente un problema real de conectividad o de consulta que ruido.

Relacionado

• Monitorización de consultas de base de datos: la página de producto de este tipo de comprobación.
• Guía de monitorización de CPU, RAM y disco: otra comprobación que se ejecuta desde la infraestructura privada de HostTracker en lugar de la red pública, útil junto a una comprobación de base de datos en el mismo servidor.
• Guía de monitorización SNMP: para leer valores directamente de hardware de red en lugar de una base de datos.
• Modo de aserciones y reglas de validación de respuesta: el lenguaje de reglas de validación de respuesta usado en otros sitios de los tipos de comprobación de HostTracker.
• Todas las funciones de monitorización de HostTracker: ve cada tipo de comprobación en paralelo.
• 503 Service Unavailable: el estado que devuelve un sitio cuando la base de datos detrás de él deja de responder.
• Todas las guías de monitorización: la guía de configuración de cada otro tipo de comprobación.