Guía de configuración de monitorización de CPU, RAM y disco

Antes de empezar

No hay ningún agente instalable de HostTracker para este tipo de comprobación, ni tampoco un selector de Ubicaciones de monitorización por monitor. El sondeo se ejecuta desde la propia infraestructura privada de comprobación de HostTracker, no desde la red pública distribuida. La comprobación funciona al revés: tu servidor expone un pequeño endpoint que responde con un único número, y HostTracker lo consulta con un calendario. Hay tres formas de proporcionar ese endpoint, elegidas con el ajuste Value provider de abajo, y elijas la que elijas tiene que estar desplegada y accesible antes de crear el monitor:

• Escribe tú mismo el endpoint (la opción custom). Responde un pequeño objeto JSON, que es la opción que prefieren muchos equipos ya que nada que no hayan escrito ellos mismos se ejecuta nunca en su servidor.
• Despliega el recolector PHP ya hecho de HostTracker en un servidor web Linux/Unix.
• Despliega el manejador ASP.NET 4.0 ya hecho de HostTracker en un servidor IIS/Windows.

Un host sin ningún acceso entrante en absoluto no se puede sondear. Lo que hay que exponer es una URL de solo lectura que devuelve un número, no un puerto de gestión, pero sí tiene que estar expuesta a los verificadores de HostTracker.

Fuente de monitorización

No hay captura de pantalla disponible para esta sección, pero cada control en ella sigue necesitando explicación, ya que es lo que hace distinto a este tipo de comprobación del resto del panel.

• Value provider: un desplegable con tres opciones. Value provider - your own web service (custom): tu endpoint responde {"v": 12.34, "e": "error text", "vs": "version string"}, y tiene que estar presente al menos un valor o una cadena de error, así que un endpoint que devuelve solo {"v": 42.5} reporta 42,5 en cada comprobación. HostTracker collector - PHP, for *nix web servers: necesita shell_exec activado en php.ini (llama por debajo a top, free y df), más las extensiones mysql/mysqli para una lectura de tiempo de conexión a MySQL. HostTracker collector - ASP.NET 4.0, for IIS/Windows: la identidad del pool de aplicaciones necesita permisos para leer contadores de rendimiento y el registro, y Network Service normalmente basta. Los dos recolectores ya hechos se descargan desde esta sección y hay que desplegarlos a mano en el servidor objetivo; HostTracker nunca empuja nada a tu servidor automáticamente.
• El campo de monitor URL justo debajo se etiqueta Full monitor url para la opción custom (la dirección exacta del endpoint, marcada tal cual) o Base monitor url para un recolector ya hecho (la raíz del sitio bajo la que se desplegó el script del recolector; HostTracker le añade el propio nombre de archivo del recolector).
• Una vez que se selecciona un recolector ya hecho, aparece un desplegable de Counter type: CPU usage %, RAM usage %, Disk or file system usage %, Port connection time (ms), MySQL connection time (ms), y, solo en ASP.NET, SQL Server connection time (ms) y Windows performance counter. Cada uno trae su propio campo: una letra de disco o una ruta *nix, un host y un puerto, una cadena de conexión (con un enlace de formato de ejemplo), o un trío de categoría / nombre / instancia para un contador de rendimiento (la instancia puede quedar en blanco para la que hay por defecto, a menudo _Total).

Configuración principal

La Configuración principal de este tipo no tiene captura de pantalla dedicada, así que aquí está cada control:

• Intervalo: de 1 minuto hasta 24 horas, más una alternativa de calendario por cron. Un minuto encaja con una máquina crítica para el negocio; 5 o 10 minutos son de sobra para una tendencia más lenta como el uso de disco.
• Etiquetas: etiquetas de texto libre para agrupar y filtrar monitores.
• Registro completo: guarda cada valor sondeado individualmente en lugar de solo resúmenes agrupados.
• 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.
• Retry on connect fail: un interruptor, activado por defecto, que reintenta una vez antes de marcar un fallo de obtención como un error directo.
• Los controles de Value provider, monitor URL y Counter type descritos en Fuente de monitorización arriba también viven en este grupo del panel.

Validación de respuesta

Aquí es donde conviertes una lectura en bruto en una alerta, y es donde los lectores suelen atascarse. Un umbral fijado demasiado ajustado se dispara en cada pico normal, y uno fijado demasiado holgado nunca se dispara hasta que ya es tarde para que importe.

• Error condition: se muestra en la captura en su valor por defecto, no condition, que significa que el monitor solo reporta el valor sin ningún veredicto Down. Elegir equals, not equal to, less than o greater than revela un campo numérico para el límite; elegir inside range u outside range revela dos, un límite inferior y uno superior.
• Overloads before Down: aparece en cuanto se selecciona cualquier condición distinta de "no condition". Es un deslizador de 0 a 20: el número de comprobaciones consecutivas que ya tienen que estar incumpliendo la condición antes de que el monitor pase a Down. En 0, una sola lectura que incumpla cuenta de inmediato; en 3, por ejemplo, hacen falta tres comprobaciones seguidas por encima del límite. HostTracker evalúa esto de forma centralizada, no la máquina que se está vigilando, y es lo que decide si el monitor es útil o si está gritando lobo constantemente. Un servidor cuya carga de CPU tiene picos de unos segundos varias veces por hora necesita un antirrebote por encima de 0, o cada pico normal se convierte en una alerta.

Elegir el propio umbral es una decisión de criterio específica de lo que estés vigilando. No hay un único número correcto, así que dale atención real en lugar de dejar el valor por defecto. Una propiedad útil de esta comprobación: un fallo de obtención (el recolector es inaccesible, agota el tiempo de espera, o devuelve algo que no se puede interpretar) se reporta como error de inmediato y nunca cuenta para el antirrebote de arriba, así que una conexión inestable al recolector no puede satisfacer un recuento de sobrecargas consecutivas pensado para una presión de recursos genuina.

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 elige contactos y eventos individuales en la tabla de debajo.

Suscripciones de informes

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

Ejemplo resuelto

Vigilar el espacio en disco de un servidor Linux que ya ejecuta PHP: descomprime el recolector PHP ya hecho en el servidor y confirma que es accesible en su propia URL. Pon Value provider en la opción del recolector PHP, el monitor URL en la dirección base del sitio, Counter type en Disk or file system usage %, y la ruta del sistema de archivos en /dev/sda1. Pon Error condition en greater than, con un límite de 90 (por ciento), y Overloads before Down en 3, así que hacen falta tres lecturas consecutivas por encima del 90% antes de que se dispare una alerta. Un pico breve de una tarea de copia de seguridad no lo va a disparar, pero un llenado sostenido sí. El intervalo es de 10 minutos, y CPU y RAM tienen sus propios monitores aparte en el mismo servidor con el mismo recolector.

Solución de problemas

• El recolector es inaccesible. Un host sin ningún acceso entrante en absoluto no se puede sondear. Confirma que el endpoint responde desde fuera de tu propia red, en una ruta difícil de adivinar si te preocupa la exposición, ya que no acepta ningún comando y no cambia nada.
• El monitor avisa con un número claramente equivocado. La comprobación reporta lo que reporte el recolector. Arregla el endpoint, y considera que reporte la cadena de error opcional en lugar de un número malo cuando algo va mal de su lado.
• Las alertas se disparan con cada pico menor. Sube Overloads before Down en lugar del propio umbral. Dejarlo en 0 hace que cuente cualquier pico único.
• El recolector PHP reporta "shell_exec is denied on server." Las lecturas de CPU, RAM y disco llaman todas por debajo a comandos del sistema, así que confirma que shell_exec no está en la lista de funciones desactivadas de php.ini.
• Una comprobación de contador de rendimiento de Windows da error. La identidad del pool de aplicaciones necesita permisos para leer contadores de rendimiento y el registro; si todavía no es Network Service, prueba a ponerlo así.

Relacionado

• Todas las guías de monitorización: el punto central para cada tipo de comprobación de HostTracker.
• Qué es la monitorización de servidores: para qué sirven estas lecturas y cómo encajan junto a las comprobaciones de disponibilidad.
• Monitorización de servidor: CPU, RAM y disco: la página de producto de este tipo de comprobación.
• Guía de monitorización SNMP: la vía alternativa a las mismas métricas en hardware que no puede ejecutar un recolector, como routers y switches.
• Monitorización de consultas de base de datos: para vigilar directamente las consultas y resultados de una base de datos, más allá de un número de tiempo de conexión.
• Guía de la comprobación de base de datos: otra comprobación que se ejecuta desde la infraestructura privada de HostTracker.
• Herramienta gratuita de comprobación de puertos: una forma rápida de confirmar que un puerto es accesible antes de montar todo un monitor de tiempo de conexión alrededor.
• Modo de aserciones y reglas de validación de respuesta: el lenguaje de reglas de validación de respuesta usado en otros sitios de HostTracker.