Cómo monitorizar recursos del servidor sin complicarte

Cómo monitorizar recursos del servidor sin complicarte

Un servidor no debería administrarse a ciegas. Si una web va lenta, WordPress se bloquea, nginx devuelve errores o una base de datos consume demasiado, necesitas datos: CPU, memoria, disco, red, procesos, logs y disponibilidad.

Monitorizar recursos del servidor no significa montar un centro de control enorme. Para una microempresa, un VPS, una web corporativa o una plataforma de formación online, muchas veces basta con una rutina sencilla: saber qué mirar, cuándo mirarlo y qué señales indican que algo empieza a ir mal.

Este artículo explica cómo monitorizar un servidor Linux desde una perspectiva práctica, evitando tanto la improvisación como el exceso de herramientas que luego nadie mantiene.

Índice

• Por qué monitorizar recursos del servidor
• Qué recursos conviene medir
• Uso de CPU
• Memoria RAM y swap
• Espacio en disco y uso de almacenamiento
• Tráfico de red y conexiones
• Procesos y servicios activos
• Logs del sistema y del servidor web
• Monitorización en servidores WordPress
• Alertas básicas y revisión periódica
• Errores frecuentes al monitorizar servidores
• Conclusión
• Preguntas frecuentes

Por qué monitorizar recursos del servidor

Monitorizar permite detectar problemas antes de que se conviertan en caídas visibles. Un servidor puede empezar a degradarse por falta de memoria, disco lleno, procesos descontrolados, ataques automáticos, copias de seguridad mal programadas o plugins pesados.

Sin monitorización, muchas incidencias se descubren tarde: cuando la web ya está caída, el panel de WordPress no carga o un cliente avisa de que algo falla.

Monitorizar ayuda a responder preguntas concretas:

• ¿El servidor se queda sin memoria?
• ¿Hay procesos consumiendo demasiada CPU?
• ¿El disco se está llenando por logs o backups?
• ¿La base de datos está saturada?
• ¿Hay demasiadas conexiones externas?
• ¿Los errores aparecen siempre a la misma hora?
• ¿La web cae durante backups, actualizaciones o picos de tráfico?

Este artículo se apoya en una base previa de infraestructura. Si estás empezando, conviene revisar qué es realmente un servidor web, cómo proteger un servidor Linux básico y cómo elegir hosting para proyectos serios.

Qué recursos conviene medir

Un servidor no se entiende mirando un único dato. La CPU puede parecer normal mientras la memoria está al límite. El disco puede estar lleno aunque la web responda. La red puede estar saturada por bots aunque el tráfico humano sea bajo.

Los recursos básicos a revisar son:

• CPU.
• Memoria RAM.
• Swap.
• Espacio en disco.
• Lectura y escritura de disco.
• Tráfico de red.
• Procesos activos.
• Servicios críticos.
• Logs de errores.
• Estado de backups.

Para una microempresa no hace falta empezar con una plataforma compleja. Lo importante es definir una rutina mínima y saber interpretar señales básicas.

Uso de CPU

La CPU indica cuánto trabajo está realizando el servidor. Un pico puntual no tiene por qué ser un problema. Lo preocupante es un consumo alto sostenido o repetido sin explicación.

Puede haber consumo elevado de CPU por:

• Plugins pesados.
• Consultas lentas de base de datos.
• Backups mal programados.
• Procesos PHP acumulados.
• Bots o ataques automáticos.
• Indexaciones internas.
• Errores que provocan bucles.

Herramientas simples como top o htop permiten ver procesos en tiempo real. Para una revisión más específica, este tema se desarrolla en cómo detectar consumo excesivo de CPU.

Memoria RAM y swap

La memoria RAM es crítica en servidores web. Si el sistema empieza a quedarse sin memoria, puede usar swap, ralentizarse o incluso matar procesos para sobrevivir.

En un servidor con WordPress, PHP-FPM y MariaDB, la memoria puede consumirse por:

• Demasiados procesos PHP simultáneos.
• Base de datos con consultas pesadas.
• Plugins exigentes.
• Cachés mal configuradas.
• Procesos de backup o compresión.
• Tráfico inesperado.

Comandos básicos como free -h ayudan a revisar memoria disponible y uso de swap.

free -h

La swap no es mala por existir, pero si el servidor depende constantemente de ella, probablemente hay un problema de recursos o configuración.

Espacio en disco y uso de almacenamiento

Un disco lleno puede romper una web aunque CPU y memoria estén bien. Si no queda espacio, pueden fallar subidas de archivos, sesiones, cachés, bases de datos, logs, actualizaciones y backups.

Conviene revisar:

• Espacio total y libre.
• Crecimiento de logs.
• Tamaño de bases de datos.
• Carpetas de uploads.
• Backups acumulados.
• Cachés antiguas.
• Archivos temporales.

Un comando básico para ver uso de discos es:

df -h

Para localizar carpetas grandes puede usarse:

du -h --max-depth=1 /var/www

En servidores WordPress, el crecimiento de wp-content/uploads y de copias locales puede ser muy relevante. Por eso conviene conectar esta revisión con cómo hacer backups automáticos del servidor.

Tráfico de red y conexiones

La red también puede revelar problemas. Un servidor puede recibir tráfico legítimo, bots, escaneos, intentos de fuerza bruta o conexiones internas mal cerradas.

Conviene observar:

• Picos de tráfico inesperados.
• Muchas conexiones desde pocas IPs.
• Tráfico repetitivo hacia rutas inexistentes.
• Intentos frecuentes contra SSH.
• Peticiones intensivas a WordPress.

Los logs de nginx o Apache suelen ser más útiles que mirar solo el consumo de red bruto. Permiten ver qué rutas se están pidiendo, desde dónde y con qué códigos de respuesta.

Si el tráfico sospechoso es constante, conviene revisar cómo evitar ataques automáticos a tu servidor y cómo configurar fail2ban correctamente.

Procesos y servicios activos

Monitorizar procesos permite saber qué está consumiendo recursos y qué servicios están funcionando. En un servidor web básico pueden ser críticos servicios como nginx, Apache, PHP-FPM, MariaDB, SSH, cron y herramientas de backup.

Comandos útiles:

systemctl status nginx
systemctl status php-fpm
systemctl status mariadb

Los nombres exactos pueden variar según versiones y paquetes instalados, pero la idea es comprobar si los servicios están activos, fallando o reiniciándose continuamente.

También conviene revisar tareas programadas, porque algunos picos aparecen siempre a la misma hora por cron jobs, backups, limpiezas o procesos automatizados.

Si necesitas actuar sobre servicios sin romper producción, este tema enlaza con cómo reiniciar servicios Linux correctamente.

Logs del sistema y del servidor web

Los logs explican lo que las métricas no cuentan. Una gráfica puede indicar consumo alto, pero los logs pueden mostrar errores de PHP, rutas atacadas, problemas de permisos o fallos de base de datos.

Logs habituales:

• /var/log/nginx/access.log
• /var/log/nginx/error.log
• Logs de Apache, si se usa Apache.
• Logs de autenticación del sistema.
• Logs de PHP-FPM.
• Logs de MariaDB o MySQL.

La clave no es leer cada línea, sino detectar patrones: errores repetidos, rutas extrañas, códigos 500, intentos de login, peticiones a archivos sensibles o fallos de permisos.

En servidores con nginx, revisar logs es especialmente útil después de cambios de configuración. Si nginx está en tu arquitectura, conviene tener presente cómo instalar nginx correctamente.

Monitorización en servidores WordPress

WordPress puede consumir recursos por muchas razones: plugins, temas, cron interno, consultas lentas, bots, formularios, actualizaciones, cachés o tráfico real.

En un servidor WordPress conviene revisar:

• Consumo de PHP-FPM.
• Uso de base de datos.
• Errores PHP.
• Tamaño de uploads.
• Actividad de plugins.
• Cron de WordPress.
• Accesos a wp-login.php.
• Peticiones a xmlrpc.php.

Muchas veces el problema no está en el VPS, sino en una instalación WordPress cargada de plugins o mal optimizada. Antes de contratar más recursos, conviene medir.

Si estás montando WordPress desde cero, puedes revisar cómo instalar WordPress manualmente. Si ya lo tienes con nginx, tiene sentido complementar con cómo proteger WordPress desde nginx.

Alertas básicas y revisión periódica

Monitorizar no sirve de mucho si nadie mira los datos. Para una microempresa, no hace falta empezar con alertas complejas, pero sí conviene definir mínimos.

Alertas o revisiones útiles:

• Servidor caído.
• Disco por encima de cierto porcentaje.
• Backups no generados.
• CPU alta sostenida.
• Memoria al límite.
• Certificado HTTPS próximo a caducar.
• Errores 500 frecuentes.

Algunas herramientas externas pueden comprobar disponibilidad desde fuera. Otras herramientas internas pueden vigilar recursos. Lo importante es no depender únicamente de que un usuario avise.

La monitorización debe adaptarse al tamaño del proyecto. Una web sencilla puede necesitar revisiones semanales. Una plataforma con usuarios o ventas necesita vigilancia más frecuente.

Errores frecuentes al monitorizar servidores

El primer error es no monitorizar nada. El segundo es instalar demasiadas herramientas sin entenderlas.

Errores habituales:

• Mirar solo CPU e ignorar memoria, disco y logs.
• No revisar backups.
• No comprobar certificados HTTPS.
• Confundir picos normales con problemas graves.
• No distinguir bots de tráfico real.
• Contratar más recursos sin diagnosticar.
• No documentar incidencias repetidas.
• No revisar tareas programadas.
• No mirar logs de errores.

Monitorizar bien no consiste en tener muchas gráficas, sino en poder responder con datos cuando algo falla.

Conclusión

Monitorizar recursos del servidor es una práctica básica para cualquier proyecto web serio. Permite detectar problemas de CPU, memoria, disco, red, procesos, logs, backups y disponibilidad antes de que afecten gravemente al negocio.

Para una microempresa, la clave está en empezar simple: revisar recursos críticos, entender patrones normales, configurar alertas mínimas y no administrar a ciegas.

Un servidor bien monitorizado no es el que tiene más paneles, sino el que permite tomar decisiones con datos.

Si la web sostiene SEO, captación comercial, cursos online o imagen profesional, la monitorización no es lujo técnico: es mantenimiento operativo.

Preguntas frecuentes