Guía para decidir mejor
Qué monitorizar en un servidor web
Combina experiencia externa, aplicación, sistema y continuidad en alertas útiles.
Monitorizar un servidor web consiste en detectar si el servicio funciona y entender por qué falla antes de que el cliente lo comunique. No basta con ver la CPU: una web puede responder 200 y tener un checkout roto, o mostrar CPU baja mientras espera base de datos. Combina señales externas, recursos internos y pruebas de recorrido.
Cuatro capas de observación
| Capa | Señal útil | Acción si cambia |
|---|---|---|
| Experiencia externa | Disponibilidad HTTP, latencia y rutas críticas | Confirmar desde otra red y revisar alcance. |
| Aplicación | Errores PHP, respuestas 5xx, cola y tareas | Relacionar con despliegue, plugin o tarea. |
| Sistema | CPU, memoria disponible, swap, disco y E/S | Localizar saturación antes de ampliar. |
| Continuidad | Certificado, copias y prueba de restauración | Corregir antes del vencimiento o incidente. |
Define alertas que alguien pueda atender
Registra línea base en días normales y campañas. Alerta por condición sostenida y contexto, no por un pico inocuo de segundos. Para una tienda, vigila portada, categoría y una prueba controlada del flujo de compra; no envíes transacciones reales repetidas. Pon dueño, canal y horario a cada alarma, y documenta cómo comprobar si es falso positivo.
Relaciona síntomas antes de actuar
Si crecen los 503 y a la vez se agotan procesos PHP, examina peticiones lentas y colas. Si sube la latencia sin consumo de CPU, investiga E/S, consultas y red. Si un único país ve errores, revisa DNS, CDN y servicios externos. La medición de TTFB separa la respuesta inicial de la carga completa; la guía de error 503 sirve para triage específico.
Informe semanal sencillo
Un ejercicio de diagnóstico
Supón que la portada responde, pero la página de pago empieza a tardar. Primero confirma si el problema afecta a usuarios reales o solo a la sonda. Después relaciona hora, registros HTTP, errores de la aplicación, tiempo de la pasarela y carga de base de datos. Si una alerta no permite distinguir estas posibilidades, añádele contexto antes de elevar su sensibilidad. No desactives caché, WAF o plugins en producción por una única medición.
Anota incidentes, duración, causa confirmada, capacidad máxima observada, copias verificadas y acción preventiva. Compara periodos equivalentes y conserva el dato bruto antes de hacer cambios. Un panel bonito no sustituye una persona responsable. Si gestionas muchas instalaciones, aplica el proceso de hosting para varios clientes. Consulta con IDEIHOSTING qué métricas y avisos están disponibles en tu servicio concreto; no presupongas monitorización gestionada por el nombre del plan.
Antes de ampliar un plan, revisa tendencia y cuello de botella
Compara CPU sostenida, memoria disponible, swap, procesos PHP, base, E/S, disco y latencia de rutas dinámicas en una ventana representativa. Añade errores 5xx, colas y picos de campaña. Si solo sube el tiempo de una API externa, más RAM puede no ayudar; si el disco crece por copias locales, revisa retención antes de pagar por más capacidad. Define qué métrica justificaría ampliar, qué mejora esperas y cómo la medirás después. La guía de dimensionamiento ayuda a convertir datos en una decisión de plan.
Rutina semanal para varias webs alojadas
Una vez por semana, revisa alertas, errores nuevos, certificados próximos a vencer, estado de backups y una restauración ensayada según calendario; prueba formularios y rutas de compra donde corresponda. Comprueba espacio, versiones pendientes y cuentas con acceso, sin actualizar todas las webs críticas a la vez. Registra dueño, fecha, hallazgo y acción. Una incidencia urgente se atiende en el momento: la revisión semanal no reemplaza alarmas. Para tiendas, añade una comprobación del recorrido de pago y avisos operativos específicos.
Si salta una alarma, determina si el fallo afecta a todos. Para patrones difíciles, consulta errores intermitentes y fallos a horas fijas. Una tendencia de almacenamiento requiere diagnóstico del disco. Para interpretar informes de uptime, revisa qué mide el porcentaje de disponibilidad.