Cobertura

Qué monitoriza

No se configura nada por host. El agente llega, descubre qué corre en la máquina y lo vigila. Esa es la pieza que hace que todo lo de abajo sea útil: sin ella, cada detector sería un alta manual por servidor.

Sistema

• CPU, memoria, disco e inodos — Con el detalle por punto de montaje, no un porcentaje global que esconde el disco que se llena.
• Carga descompuesta — El load average mezcla lo que quiere CPU con lo que está parado esperando disco. Aquí van separados: «carga 40 y el servidor no da más» y «carga 40 pero nadie usa CPU, es el disco» son el mismo número y averías opuestas.
• RAID por software — Si un disco se cae del array, el sistema sigue funcionando exactamente igual hasta que se cae el segundo. Ese silencio es el problema.
• E/S por disco y por interfaz — Lecturas, escrituras y tiempo de espera por dispositivo; bytes y paquetes por cada interfaz de red. El detalle que dice cuál de los discos está aguantando todo.
• Sistemas de ficheros en sólo lectura — Cuando el kernel encuentra errores graves de E/S, remonta en sólo lectura. Todo parece seguir funcionando y nada se puede escribir, que es de las averías que más tardan en descubrirse.
• Presión del sistema (PSI) — Cuánto esperan de verdad los procesos por CPU, memoria o E/S. Un servidor al 40 % de CPU puede estar ahogado, y esto lo dice.
• Muertes por falta de memoria — Quién mató al proceso y por qué, distinguiendo el OOM real de una señal cualquiera.
• Procesos, con eBPF — Ejecuciones y muertes con su causa, leídas del kernel. Sin muestreo: no se pierde el proceso que vivió dos segundos.

Contenedores

• Docker y Docker Swarm — Contenedores en marcha con su consumo de CPU, memoria, disco y red, y sus eventos. Entiende que en Swarm un reinicio de task es normal y una caída no.
• Salud de cada contenedor — Healthchecks que fallan, procesos matados por límite de memoria, reinicios en bucle, PIDs agotados y throttling de CPU: el que explica por qué un contenedor va lento sin que nada aparezca como caído.
• Kubernetes — Los pods que corren en el nodo, con su namespace y su consumo. Desde el propio nodo, sin credenciales del clúster.
• Kata Containers — Distingue el runtime: un sandbox de Kata se reporta como tal, con la versión instalada.
• Registries — El registro de imágenes del que depende tu despliegue.

Paneles de hosting

• Plesk — El panel y sus servicios.
• Copias de seguridad de Plesk — Si dejan de hacerse, te enteras antes que tú mismo. Nadie mira las copias hasta que hay que restaurar, y entonces ya es tarde.
• HestiaCP — El panel y lo que lo sostiene.

Aplicaciones

• Correo: Zimbra y Carbonio — Los servicios de la plataforma de correo, que es donde más se nota una caída.
• Bases y cachés: MySQL, Redis, Memcached
• Web: PHP-FPM y Varnish — Incluida la eficacia real de la caché, no sólo si el proceso vive.
• systemd y certificados — Unidades que fallan y certificados que caducan, que es el aviso que siempre llega tarde.

Telefonía

• Asterisk — Canales y llamadas activas, llamadas procesadas, endpoints PJSIP disponibles y no disponibles, contactos, colas y miembros. Se lee por el socket CLI local: ni abre ni necesita SIP ni AMI.

Plataformas

• AWS: EC2 y CloudWatch — Por el perfil de instancia con IMDSv2. Sin guardar ninguna access key.
• Proxmox — El hipervisor y lo que corre encima.

Hardware

• Discos SMART — El aviso que llega semanas antes del fallo, si alguien lo mira.
• GPUs NVIDIA — Incluidos los errores XID, que son los que explican por qué se cayó el trabajo.

Red

• Calidad hacia donde te importe — Latencia, jitter y pérdida de paquetes contra los destinos que elijas. No «hay red o no», sino cómo de buena es.
• Equipos MikroTik — Se descubren por su protocolo de vecindad, que emiten cada 60 segundos. Pasado ese rato, el silencio ya no es casualidad.
• Vecinos de red — Qué hay alrededor del host.