El 29 de junio de 2020, a las 00:28 UTC, la aplicación de gestión de clientes de GitLab (customers.gitlab.com) empezó a devolver errores 500. GitLab, que desde hace años lleva su gestión de incidentes en público —cualquiera puede leer hoy el issue original en su plataforma—, documentó la causa con la misma franqueza con la que documenta todo lo demás: un directorio de logs duplicado, olvidado desde una migración en noviembre del año anterior, más una acumulación de ficheros sin rotar, habían dejado la partición /var/log del servidor al 100 % de su capacidad. La alerta que disparó el aviso no fue nada sofisticado: el espacio en disco para los registros se había agotado. El equipo de guardia entró, eliminó los logs sobrantes, reinició los servicios y en solo veinte minutos —a las 00:48 UTC— el sistema volvía a responder con normalidad.
No hay nada exótico en esta historia, y esa es exactamente la razón por la que merece contarse. En 2020, GitLab ya operaba una plataforma cloud native con microservicios, contenedores y toda la sofisticación que cabría esperar de una de las empresas más influyentes del ecosistema DevOps. Y aun así, lo que tumbó el servicio durante veinte minutos fue el problema más viejo de la informática: un disco que se llenó porque nadie limpió unos logs a tiempo. Seis años después, con modelos de IA en producción y trazas distribuidas atravesando quince microservicios, ese riesgo no ha desaparecido en absoluto. Simplemente ha quedado tapado por la conversación, mucho más vistosa, sobre observabilidad de aplicaciones.
El punto ciego de las herramientas de APM (y la ilusión del «todo en uno»)
Las plataformas de APM y observabilidad moderna que dominan el mercado —con Dynatrace, Datadog o New Relic a la cabeza— prometen romper los silos de herramientas ofreciendo una visión unificada desde la experiencia del usuario hasta el último rincón de la infraestructura. Es una promesa potente y, en muchos aspectos, real: sus motores de correlación automática y análisis de causas raíz resuelven incidentes complejos mejor que nada de lo que existía hace una década.
Sin embargo, esta misma especialización crea una paradoja técnica. Por un lado, la atención del equipo de implementación suele volcarse casi por entero en lo más vistoso: instrumentar trazas distribuidas, medir tiempos de respuesta de base de datos y construir dashboards de negocio. En ese proceso, la monitorización de bajo nivel del sistema operativo se da por descontada y queda en segundo plano. Por otro lado, la propia naturaleza de estas plataformas —diseñadas para detectar anomalías dinámicas y patrones de tráfico— a veces complica de forma innecesaria algo tan prosaico como configurar una alerta limpia sobre la tasa de llenado de un volumen concreto, obligándote a pelearnos con algoritmos de detección que no siempre reaccionan bien ante un crecimiento repentino de ficheros de log.
Cuando el problema no es una transacción lenta sino que un proceso batch nocturno agota la memoria de un nodo que no atiende peticiones HTTP, esa señal queda ahogada por el ruido. Y es exactamente aquí donde el enfoque de la monitorización de infraestructura tradicional —encarnado en herramientas como Zabbix, Nagios, Icinga o la combinación clásica de Prometheus con Node Exporter— sigue manteniendo una vigencia incontestable. No porque sean mejores en todo, sino porque su único cometido es vigilar la salud del hierro y del sistema operativo sin asumir nada sobre la aplicación que corre encima.
Veinte años vigilando lo mismo, y sin embargo distinto
Zabbix cumplió veinte años en 2025. La empresa que lo mantiene, fundada en Riga en 2005 por Alexei Vladishev, lo celebró con una frase que resume bien la continuidad del propósito: «hace veinte años, Zabbix empezó como una idea para dar soporte a nuestra solución de monitorización fiable y escalable de código abierto; hoy, tanto el producto como la compañía cuentan con la confianza de empresas, gobiernos y comunidades» en más de 160 países. Es el mismo tipo de herramienta que hace veinte años: agentes ligeros, comprobaciones activas y pasivas, umbrales configurables sobre CPU, memoria, disco, procesos, servicios de red. Nada de esto ha dejado de hacer falta.
Lo interesante es que Zabbix tampoco se ha quedado congelado en 2005. Con la llegada de la versión 8.0 LTS, prevista para 2026, el propio proyecto empieza a hablar explícitamente de «observabilidad completa» —métricas, logs y trazas— e incorpora soporte nativo de OpenTelemetry, además de un tipo de dato JSON pensado para estructuras más complejas y una función de «shared data» que evita recolectar la misma información varias veces en entornos dinámicos y containerizados. Es un movimiento revelador: la herramienta que nació para vigilar hierro físico no ha intentado competir con Prometheus o con las plataformas de APM en su terreno de trazas distribuidas; ha optado por absorber ese vocabulario nuevo sin abandonar lo que siempre hizo bien, que es la vigilancia de infraestructura de bajo nivel con muy poco overhead.
MONITORIZACIÓN CLÁSICA (Zabbix, Nagios, ...) OBSERVABILIDAD DE APLICACIÓN (APM)
═══════════════════════════════════════════ ════════════════════════════════════
[ Host / VM / nodo ] [ Transacción de usuario ]
├─ CPU ──► umbral ──► alerta │
├─ Memoria ──► umbral ──► alerta ▼
├─ Disco ──► umbral ──► alerta [ Traza distribuida a través de
└─ Servicio arriba/abajo ──► alerta varios microservicios ]
│
Pregunta que responde bien: ▼
"¿está el disco a punto de llenarse?" Pregunta que responde bien:
"¿por qué fue lenta esta petición?"
El caso de uso que casi nadie diseña con cuidado: la alerta de «esto se va a llenar»
Hay una categoría de alerta que parece trivial de definir bien y en la práctica casi nunca lo es: avisar de que un disco se va a llenar antes de que se llene, con margen suficiente para actuar, y sin generar tanto ruido que el equipo acabe ignorándolo. Un umbral fijo del 90% de uso de disco suena razonable hasta que te encuentras con un servidor de logs cuyo consumo crece a ritmo lineal predecible y otro cuyo consumo puede dispararse en minutos por un proceso que se queda colgado escribiendo sin control —el mismo umbral no sirve igual de bien para los dos, y una herramienta de monitorización clásica bien configurada permite matizar esto con comprobaciones basadas en tendencia (cuánto está creciendo el uso, no solo en qué punto está ahora), algo que muchas plataformas de APM, centradas en otra capa del problema, ni siquiera exponen como opción de primera clase.
Lo mismo aplica al consumo de CPU y memoria a nivel de sistema operativo. Una plataforma de APM te dirá, con mucho detalle, qué proceso de tu aplicación consume más CPU dentro de la propia aplicación. Pero si el problema es que un proceso completamente ajeno a tu stack aplicativo —un backup mal programado, un cron que nadie recuerda haber creado, un demonio de logging del propio sistema— se está comiendo la memoria del nodo, esa señal vive en la capa de sistema operativo, no en la capa de aplicación, y es ahí exactamente donde las herramientas de monitorización de infraestructura de toda la vida siguen aportando un valor que ninguna plataforma de APM, por sofisticada que sea, sustituye del todo.
Honestidad sobre lo que Zabbix y las herramientas clásicas no hacen bien
Sería igual de deshonesto presentar Zabbix como una alternativa completa a un stack moderno de observabilidad que presentar un APM como sustituto de la monitorización de infraestructura. Zabbix nació con un modelo de agente/servidor pensado para hosts relativamente estables, y aunque su soporte de OpenTelemetry en la versión 8.0 es un paso real hacia el mundo cloud native, sigue sin tener la profundidad de correlación automática entre trazas y código que ofrecen los productos de APM diseñados desde el origen para microservicios efímeros en Kubernetes. Configurar bien Zabbix en un entorno con autoscaling agresivo, donde los nodos aparecen y desaparecen en minutos, exige un trabajo de automatización (auto-registro de hosts, plantillas dinámicas) que no siempre es trivial, y que herramientas nativas de Kubernetes dan por resuelto de fábrica.
Tampoco conviene idealizar el pasado: gran parte de la razón por la que «un disco lleno» sigue tumbando servicios en 2026 no es que la tecnología para prevenirlo no exista —lleva existiendo veinte años—, sino que en la prisa por adoptar la observabilidad moderna, muchos equipos han dado por sentado que las herramientas de APM cubren también esa capa, y han dejado de prestarle a la monitorización clásica la atención operativa que exige: revisar umbrales, mantener plantillas actualizadas, comprobar que las alertas de verdad llegan a alguien que puede actuar. Una herramienta de veinte años bien mantenida sigue siendo mejor que una plataforma de última generación mal configurada.
Lo que hay que llevarse de esto
Ninguna de las dos capas sustituye a la otra, y esa es la conclusión menos vendible pero más honesta. Una plataforma de APM o de observabilidad moderna es imprescindible para entender qué le pasa a una aplicación distribuida en microservicios, pero no fue diseñada para avisarte de que el disco de logs de un nodo va a agotarse dentro de seis horas. Una herramienta de monitorización clásica como Zabbix sigue siendo, veinte años después, una de las formas más fiables y baratas de vigilar exactamente ese tipo de señal de bajo nivel, y su evolución reciente hacia el soporte de OpenTelemetry muestra que el propio ecosistema es consciente de que el futuro no es elegir una capa u otra, sino conseguir que hablen el mismo idioma. El servicio que se cayó en GitLab en 2020 no lo tumbó un modelo de IA mal calibrado ni una traza sin instrumentar: lo tumbó un disco lleno, exactamente el tipo de problema que la monitorización más antigua y menos glamurosa sigue estando ahí para atrapar antes de que llegue a las tres de la madrugada de nadie.
Fuentes:
- GitLab — 2020-06-29: Customers app out of disk space (issue público)
- Zabbix — Zabbix Celebrates 20 Years of Open-Source Excellence
- Hawatel — Zabbix 7.0 LTS vs. Zabbix 8.0 LTS: Evolution or revolution in observability and beyond?
- Zabbix — Kubernetes monitoring and integration with Zabbix
