En casi toda operación hay una base de datos que “no se toca”: corre una aplicación crítica, lleva años funcionando y está en una versión que ya nadie quiere migrar por miedo a romper algo. El problema aparece cuando quieres monitorearla y descubres que las herramientas modernas simplemente no se conectan con ella. Aquí contamos cómo resolvimos ese escenario con un driver personalizado sobre Zabbix.
Qué es una base de datos “backlevel” y por qué duele monitorearla
Llamamos backlevel a las bases de datos que corren en versiones antiguas o fuera de soporte, por ejemplo un SQL Server 2008 o anterior que sigue en producción. No es un caso raro: es más común de lo que a nadie le gustaría admitir.
El dolor llega al intentar monitorearlas. Los drivers, plugins y templates modernos asumen versiones recientes del motor y de sus protocolos de conexión. Cuando apuntan a un servidor antiguo, la conexión falla: incompatibilidades en el handshake TLS, en la versión del protocolo o en las librerías cliente. El resultado es un servidor crítico volando a ciegas, sin métricas ni alertas.
La solución: un driver personalizado que sí habla el idioma antiguo
En lugar de forzar el driver moderno o quedarnos sin datos, construimos un driver de monitoreo propio en Java, empaquetado con su JRE embebido. Esto es clave por dos razones:
- Compatibilidad: usamos librerías y un runtime capaces de establecer la conexión con la versión antigua del motor, algo que el stack moderno rechaza.
- Autonomía: al llevar su propio Java embebido, el driver no depende de lo que esté (o no esté) instalado en el servidor. Se despliega y funciona, sin pelear con versiones del sistema.
El driver ejecuta las consultas contra la base de datos usando las herramientas cliente nativas (SQLCMD / ODBC) y devuelve los resultados en el formato que Zabbix entiende.
Cómo se integra con Zabbix
La pieza que conecta todo es el Zabbix Agent 2 y sus UserParameters. En lugar de depender del item nativo de ODBC, definimos parámetros propios que invocan al driver:
db.odbc.discovery[*]para el descubrimiento de bajo nivel (LLD).db.odbc.get[*]para la recolección de métricas.
Cada uno llama al drivermonitoreo.jar con los argumentos de conexión y la consulta a ejecutar. El agente reporta los resultados al servidor de Zabbix, que se encarga del resto: crear items automáticamente, graficar, disparar alertas y correlacionar.
Las consultas SQL viven en un archivo de configuración externo (configure.ini), separado del código. Esto nos permite ajustar o agregar métricas sin recompilar el driver: basta con editar la consulta. Es un detalle pequeño que ahorra muchísimo tiempo en el mantenimiento.
El descubrimiento automático hace el trabajo pesado
Una base de datos no es un solo objeto: tiene múltiples bases, trabajos programados y, a veces, grupos de disponibilidad. El Low-Level Discovery (LLD) de Zabbix recorre todo eso automáticamente. Con consultas de descubrimiento el driver detecta:
- Las bases de datos presentes en la instancia.
- Los jobs del Agent que están habilitados.
- Los grupos de disponibilidad (Always On), cuando existen.
Zabbix toma esa lista y crea los items correspondientes por cada elemento encontrado. Si mañana aparece una base de datos nueva, se empieza a monitorear sola, sin intervención manual.
Qué terminamos monitoreando
Con este enfoque obtenemos una visión completa de la salud del motor, incluso en versiones antiguas. Entre las métricas que recogemos están:
- Estado de cada base de datos (online, en recuperación, etc.).
- Contadores de rendimiento del motor, como el buffer cache hit ratio, el ratio de caché de planes y las tablas de trabajo servidas desde caché.
- Estado y duración de los jobs del Agent, con el resultado de su última ejecución.
- Respaldos: tiempo transcurrido desde el último backup por base de datos y su duración.
- Salud de los grupos de disponibilidad y del estado de sincronización.
- Uptime y versión del motor.
Con esos datos, un servidor que antes estaba a ciegas ahora tiene tableros en tiempo real y alertas: si un backup no corrió, si un job falló o si el rendimiento se degrada, el equipo se entera antes que el usuario.
Por qué este enfoque importa para el negocio
Reemplazar o migrar una base de datos legacy es un proyecto costoso y arriesgado que muchas veces no está en el presupuesto del año. Mientras tanto, ese sistema sigue siendo crítico. Poder monitorearlo con la misma plataforma con la que vigilas el resto de tu infraestructura significa:
- Cero puntos ciegos: hasta lo más viejo queda cubierto.
- Una sola consola: no necesitas otra herramienta ni otro contrato solo para el sistema antiguo.
- Prevención real: detectas respaldos que no corren y fallas de rendimiento antes de que se conviertan en una caída.
En resumen
Las limitaciones de los drivers modernos no tienen por qué dejarte a ciegas con tus sistemas antiguos. Con un driver personalizado, un runtime embebido y la flexibilidad de los UserParameters de Zabbix, es posible monitorear bases de datos backlevel de forma robusta, mantenible y con descubrimiento automático. La tecnología antigua no es excusa para no tener visibilidad.
En ZMR Cloud construimos integraciones de monitoreo con Zabbix a la medida, incluso para los sistemas que otras herramientas dan por perdidos. Conversemos sobre tu caso.