Monitorización y mantenimiento de servidores

La monitorización y mantenimiento de servidores no consiste en abrir una herramienta, observar una gráfica y comprobar que el uso de CPU no ha alcanzado el 100 %. Administrar un servidor exige interpretar lo que sucede, compararlo con su comportamiento habitual, detectar desviaciones y actuar sin introducir nuevos problemas.

Un servidor puede seguir encendido y, sin embargo, no estar prestando correctamente sus servicios. Puede disponer de espacio libre, pero sufrir una latencia de almacenamiento que ralentiza todas las aplicaciones. También puede mostrar un uso elevado de memoria sin encontrarse realmente bajo presión, ya que parte de esa memoria puede estar utilizándose como caché.

Por eso, una revisión profesional debe combinar métricas, estados, registros, configuración y pruebas reales del servicio. Ninguno de estos elementos proporciona por sí solo una visión completa.

Mi trayectoria ha pasado por el desarrollo de software, la consultoría tecnológica y la docencia en Formación Profesional. Esa combinación me ha enseñado a abordar la tecnología desde dos perspectivas: construir soluciones y explicar con claridad cómo funcionan. También me ha llevado a trabajar los problemas con estructura, escuchar antes de proponer herramientas y convertir conceptos técnicos en decisiones aplicables.

En esta guía veremos qué debe incluir la monitorización y mantenimiento de servidores, qué recursos conviene vigilar, qué herramientas podemos utilizar en Windows Server y GNU/Linux y cómo responder ante una incidencia sin limitarnos a reiniciar el sistema.

El objetivo no es memorizar decenas de comandos. Lo verdaderamente importante es saber qué pregunta responde cada herramienta, cómo interpretar el resultado y qué comprobación debemos realizar después.

Qué significa monitorizar y mantener un servidor

La administración operativa reúne todas las tareas que se realizan después de instalar y configurar inicialmente un servidor. Su finalidad es asegurar que el equipo continúa prestando los servicios esperados con unos niveles adecuados de disponibilidad, rendimiento y seguridad.

Dentro de esta administración diaria podemos distinguir cinco funciones relacionadas:

• Monitorización.
• Mantenimiento.
• Automatización.
• Diagnóstico.
• Documentación.

La monitorización responde a una pregunta: ¿qué está ocurriendo en el sistema y cómo evoluciona?

Para contestarla podemos medir el consumo de CPU, la memoria disponible, la latencia de disco, el espacio libre, las conexiones de red o el estado de los servicios. También podemos consultar eventos y registros para conocer qué sucedió antes o durante una incidencia.

El mantenimiento responde a otra pregunta: ¿qué acciones debemos realizar para conservar el sistema en unas condiciones adecuadas?

Aquí se incluyen las actualizaciones, la rotación de registros, la revisión de discos, el control de capacidad, la limpieza segura de archivos temporales y la comprobación de las copias.

La automatización permite ejecutar algunas de estas tareas de manera programada y repetible. Podemos generar un informe diario, comprobar periódicamente un servicio o recopilar métricas sin depender de una intervención manual.

El diagnóstico utiliza la información disponible para buscar la causa probable de un problema. Por último, la documentación registra qué se hizo, por qué se hizo y cuál fue el resultado.

Estas funciones no deberían tratarse como actividades aisladas. Una buena estrategia de monitorización y mantenimiento de servidores las integra en un ciclo operativo:

Observar → comparar con la línea base → detectar una desviación → investigar → actuar → verificar → documentar.

Este ciclo evita dos errores frecuentes. El primero es actuar sin medir, lo que puede ocultar la causa original. El segundo es medir continuamente sin disponer de un procedimiento para responder a las desviaciones.

Monitorización, mantenimiento y automatización: diferencias

Aunque están relacionados, estos conceptos no significan lo mismo.

La monitorización recopila información. El mantenimiento aplica acciones para conservar el sistema. La automatización ejecuta tareas siguiendo unas condiciones o una programación.

Por ejemplo:

• Medir diariamente el espacio disponible es monitorización.
• Eliminar archivos temporales conforme a una política es mantenimiento.
• Programar un script que genere un informe de capacidad es automatización.

Una automatización también puede formar parte de la monitorización. Por ejemplo, una tarea programada puede revisar un servicio y registrar su estado. Sin embargo, automatizar una comprobación no garantiza por sí solo que el servidor esté bien administrado.

La información debe llegar a una persona responsable, interpretarse correctamente y asociarse a una acción.

Administración reactiva frente a mantenimiento preventivo

La administración reactiva comienza cuando el usuario ya percibe el problema. El servicio se ha detenido, una aplicación responde lentamente o un volumen se ha quedado sin espacio.

La administración preventiva intenta detectar las señales anteriores a la incidencia. Para ello utiliza históricos, alertas, revisiones periódicas y mantenimiento planificado.

No siempre es posible evitar un fallo. El objetivo realista es reducir su probabilidad, detectar antes sus efectos y limitar su impacto.

Una gráfica no previene una incidencia por sí sola. Para que la monitorización sea útil necesitamos:

• Umbrales adecuados.
• Responsables definidos.
• Prioridades.
• Procedimientos de respuesta.
• Validaciones posteriores.
• Un registro de las actuaciones.

Qué se debe monitorizar en un servidor

Una estrategia útil de monitorización y mantenimiento de servidores no debería empezar preguntando qué aplicación debemos instalar. Primero debemos decidir qué información necesitamos y qué decisiones queremos tomar con ella.

Las fuentes operativas más importantes son las métricas, los estados, los registros, las trazas, las alertas y el inventario.

Métricas, estados, registros, trazas y alertas

Una métrica es un valor numérico medido a lo largo del tiempo. Algunos ejemplos son el porcentaje de CPU, la memoria disponible, las operaciones de entrada y salida por segundo o la latencia de disco.

Un estado describe la condición actual de un componente. Un servicio puede estar activo, detenido o en proceso de inicio. Una interfaz de red puede encontrarse operativa o deshabilitada.

Un registro representa un evento producido en un momento concreto. Normalmente incluye una marca temporal, un origen, un nivel y un mensaje.

Una traza ofrece un detalle mayor sobre el recorrido de una operación. Puede ayudarnos a seguir una petición o comprender en qué punto se produjo un error.

Una alerta es una notificación generada cuando se cumple una condición. Por ejemplo, puede activarse cuando el espacio disponible baja de un determinado porcentaje.

El inventario describe el entorno que estamos observando: versión del sistema, componentes instalados, interfaces de red, servicios, discos y tareas programadas.

Estos elementos se complementan. Una alerta puede avisarnos de que un servicio se ha detenido. El estado confirma la situación actual, los registros explican qué sucedió y el inventario permite conocer sus dependencias y configuración.

Cómo crear una línea base de rendimiento

Una línea base es un conjunto de mediciones obtenidas durante un funcionamiento normal y representativo. Sirve como referencia para detectar desviaciones.

No debe obtenerse en un único momento. El comportamiento de un servidor puede cambiar según la hora, el número de usuarios, las copias programadas o las tareas de mantenimiento.

Una línea base útil debería recoger al menos:

• El inicio de la jornada.
• Periodos normales de actividad.
• Picos de uso conocidos.
• Horarios de mantenimiento.
• Periodos de baja actividad.
• Ejecuciones de copias o trabajos programados.

Un 80 % de CPU podría ser normal mientras se genera un informe complejo. El mismo porcentaje podría resultar anómalo de madrugada, sin usuarios ni tareas previstas.

Como profesor de Sistemas Operativos en Red, intento insistir en esta idea: una cifra no se interpreta por su aspecto, sino por su contexto. Mi objetivo no es que el alumnado recuerde que determinado porcentaje “es malo”, sino que sepa preguntar cuánto dura, qué proceso lo provoca y qué impacto tiene sobre el servicio. Mi trabajo docente está precisamente orientado a explicar conceptos técnicos desde la práctica y con objetivos claros.

Umbrales estáticos, temporales y relativos

Los umbrales permiten transformar una medición en una condición que requiere atención.

Un umbral estático compara la métrica con un valor fijo. Por ejemplo, puede generar una alerta cuando el espacio libre baja del 15 %.

Un umbral temporal exige que la situación se mantenga durante un periodo. Así evitamos alertas provocadas por picos breves que no tienen consecuencias.

Un umbral relativo compara el valor actual con el comportamiento habitual del mismo sistema. Puede resultar más adecuado cuando la carga varía mucho entre servidores.

Todo umbral debería estar asociado a:

• Una prioridad.
• Una acción.
• Un responsable.
• Un plazo de respuesta.
• Un criterio de cierre.

Un sistema demasiado sensible genera tantas notificaciones que las alertas importantes terminan perdiéndose entre el ruido. En el extremo contrario, un umbral demasiado alto avisa cuando ya queda poco margen de actuación.

Los cuatro recursos esenciales del servidor

La primera revisión del rendimiento suele organizarse alrededor de cuatro recursos:

1. CPU.
2. Memoria.
3. Almacenamiento.
4. Red.

La clave está en analizarlos de manera correlacionada. Un almacenamiento lento puede incrementar la espera de procesos, reducir la velocidad de las aplicaciones y modificar el uso de memoria. A simple vista, el usuario solo percibirá que “el servidor va lento”.

Cómo monitorizar la CPU y la carga del sistema

Un uso elevado de CPU no representa automáticamente una incidencia. El procesador está diseñado para ejecutar trabajo, por lo que un porcentaje alto puede ser completamente normal.

Debemos observar:

• El porcentaje de tiempo ocupado.
• La distribución entre usuario, sistema, espera e inactividad.
• La cola de ejecución.
• El uso por proceso o servicio.
• El uso por procesador lógico.
• Las interrupciones.
• Los cambios de contexto.
• La duración del consumo.

Ante una posible saturación, seguiría esta secuencia:

1. Confirmar si se trata de un pico o de una situación sostenida.
2. Identificar los procesos consumidores.
3. Relacionar el consumo con usuarios o tareas programadas.
4. Comprobar memoria, almacenamiento y red.
5. Revisar cambios recientes.
6. Evaluar la aplicación antes de ampliar recursos.

En GNU/Linux debemos prestar especial atención al load average. La carga media no equivale directamente al porcentaje de CPU. Representa la demanda de tareas ejecutables o en espera no interrumpible durante varios intervalos.

Por eso debe compararse con el número de procesadores lógicos y con la posible espera de entrada y salida. Una carga de 4 puede ser elevada en un sistema con dos procesadores lógicos y razonable en otro con dieciséis.

Cómo detectar presión de memoria, paginación y fugas

La memoria RAM se utiliza para procesos, el núcleo, cachés y buffers. Un sistema que utiliza gran parte de la RAM no se encuentra necesariamente agotado.

La caché puede aprovechar la memoria disponible para acelerar operaciones y liberarse cuando otros procesos la necesitan.

Para evaluar la memoria debemos revisar:

• Memoria disponible.
• Memoria comprometida.
• Actividad de paginación o swap.
• Consumo por proceso.
• Evolución histórica.
• Errores de asignación.
• Respuesta de las aplicaciones.

En Linux, la columna available de free suele ser más útil que observar únicamente la memoria marcada como free.

En Windows podemos revisar la memoria disponible, los bytes privados, el conjunto de trabajo y la actividad de páginas por segundo. Estos valores deben relacionarse con la latencia del almacenamiento y con el comportamiento de las aplicaciones.

Una fuga de memoria se sospecha cuando el consumo de un proceso crece de forma sostenida bajo una carga comparable y no vuelve a su nivel anterior.

Reiniciar el proceso puede aliviar temporalmente el síntoma, pero no elimina la causa. Antes de hacerlo conviene conservar las métricas, la versión de la aplicación y los registros necesarios para reproducir el problema.

Cómo analizar el rendimiento y la capacidad del almacenamiento

El almacenamiento debe vigilarse desde cuatro perspectivas:

• Capacidad.
• Rendimiento.
• Integridad.
• Disponibilidad.

Un volumen puede disponer de espacio suficiente y responder lentamente. También puede ofrecer un buen rendimiento y estar a punto de llenarse.

Las métricas principales son:

Métrica	Qué representa
Latencia	Tiempo necesario para completar una lectura o escritura
IOPS	Número de operaciones de entrada y salida por segundo
Rendimiento	Cantidad de datos transferidos por segundo
Cola	Operaciones pendientes de ejecución
Utilización	Tiempo durante el cual el dispositivo está ocupado
Errores	Fallos de hardware, controlador, ruta o sistema de archivos

Para investigar un almacenamiento lento conviene:

1. Identificar el volumen y la operación afectados.
2. Comprobar el espacio disponible.
3. Revisar los errores.
4. Medir latencia, cola, IOPS y rendimiento.
5. Localizar los procesos que generan actividad.
6. Revisar copias, antivirus, indexación y actualizaciones.
7. Comprobar el hardware y los controladores.
8. Aplicar un cambio y repetir una medición comparable.

La planificación de capacidad debe basarse en tendencias, no únicamente en el valor actual. También es recomendable evitar que los registros de monitorización llenen el mismo volumen que están vigilando.

Cómo comprobar la red y la disponibilidad de los servicios

Un servidor puede funcionar correctamente de forma local y resultar inaccesible desde los equipos cliente.

Las causas pueden encontrarse en:

• La interfaz de red.
• El direccionamiento.
• La puerta de enlace.
• Las rutas.
• El DNS.
• El firewall.
• El puerto.
• La propia aplicación.

Por eso resulta útil comprobar la comunicación por capas:

1. ¿La interfaz está activa?
2. ¿Tiene la configuración correcta?
3. ¿Se alcanza la red local?
4. ¿Existe una ruta hacia el destino?
5. ¿El nombre se resuelve correctamente?
6. ¿El puerto está abierto y el servicio escucha?
7. ¿La aplicación responde a una operación real?

No debemos confundir conectividad con disponibilidad. Que un servidor responda a una prueba de red no significa que la aplicación funcione. La validación final debe realizarse desde un cliente y utilizando una operación representativa.

Herramientas de monitorización en Windows Server

Windows Server incorpora herramientas para obtener una vista inmediata, recopilar históricos, analizar eventos y automatizar comprobaciones.

No existe una única herramienta que responda a todas las preguntas. La elección depende de si necesitamos observar el presente, reconstruir un problema anterior o generar un informe automático.

Administrador de tareas y Monitor de recursos

El Administrador de tareas proporciona una visión rápida de:

• Procesos.
• Rendimiento.
• Usuarios.
• Aplicaciones.
• Consumo de recursos.

Es un buen punto de partida para una revisión inmediata.

El Monitor de recursos permite relacionar los procesos con el uso de CPU, memoria, disco y red. Esto facilita la búsqueda de un proceso responsable de una actividad concreta.

Ambas herramientas son útiles para explorar el estado actual, pero no sustituyen la recopilación histórica. Si una incidencia ocurrió de madrugada, abrir el Administrador de tareas por la mañana no mostrará necesariamente lo sucedido.

Tampoco conviene finalizar un proceso únicamente porque presenta un consumo elevado. Primero hay que identificar su función, comprobar si pertenece a un servicio y revisar qué datos o usuarios podrían verse afectados.

Monitor de rendimiento y contadores principales

El Monitor de rendimiento utiliza contadores organizados por objetos e instancias. Permite observar información en tiempo real y almacenar datos para analizarlos posteriormente.

Algunos contadores orientativos son:

Recurso	Contadores útiles
Procesador	% Processor Time, Processor Queue Length
Memoria	Available MBytes, Committed Bytes, Pages/sec
Disco	Avg. Disk sec/Read, Avg. Disk sec/Write, % Free Space
Red	Bytes Total/sec, errores y cola de salida
Sistema	Context Switches/sec, cola global del procesador

Los nombres pueden variar según la edición, el idioma, el hardware y los roles instalados.

No siempre es conveniente añadir todos los contadores disponibles. Una selección pequeña y relacionada con la hipótesis produce registros más fáciles de interpretar.

También debemos definir el intervalo de muestreo. Un intervalo muy corto genera mayor detalle, pero incrementa el tamaño de los datos. Uno demasiado amplio puede ocultar picos importantes.

Conjuntos de recopiladores de datos

Los conjuntos de recopiladores permiten guardar contadores y datos de configuración durante un periodo sin mantener abierta la consola.

Son especialmente útiles cuando:

• El problema aparece a una hora concreta.
• Necesitamos comparar varios días.
• La incidencia es intermitente.
• Queremos crear una línea base.
• Debemos conservar evidencias.

Los archivos deberían almacenarse en un volumen con espacio suficiente y una política de retención. De lo contrario, la propia monitorización puede terminar provocando un problema de capacidad.

Visor de eventos

El Visor de eventos centraliza registros de Aplicación, Seguridad, Instalación, Sistema y otros canales específicos.

Cada evento debe interpretarse atendiendo a:

• Fecha y hora.
• Nivel.
• Origen.
• Identificador.
• Mensaje.
• Sistema afectado.
• Eventos anteriores y posteriores.

Un evento crítico requiere atención inmediata, mientras que una advertencia puede indicar una situación que todavía no ha causado una interrupción.

No debemos buscar únicamente errores. Los eventos informativos ayudan a reconstruir secuencias, ya que pueden mostrar el inicio de un servicio, una actualización, un reinicio o un cambio de estado.

Comandos de PowerShell para comprobar el servidor

PowerShell permite consultar, filtrar y exportar información de forma estructurada.

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10

Muestra los procesos ordenados por consumo acumulado de CPU.

Get-Service |
    Where-Object Status -ne 'Running'

Permite localizar servicios cuyo estado no es Running. La salida debe interpretarse con cuidado, ya que no todos los servicios están diseñados para permanecer iniciados.

Get-Counter '\Processor(_Total)\% Processor Time'

Consulta un contador de rendimiento del procesador.

Get-WinEvent -LogName System -MaxEvents 20

Obtiene eventos recientes del registro de sistema.

Get-Volume |
    Select-Object DriveLetter, FileSystemLabel, SizeRemaining, Size

Muestra información de capacidad de los volúmenes.

Durante mi etapa en desarrollo y consultoría aprendí a dividir los problemas en partes observables y a trabajar con información filtrada en lugar de acumular datos sin criterio. Mi experiencia profesional incluyó desarrollo, soporte, administración, integraciones, documentación y mejora de procesos.

Aplicado a PowerShell, esto significa que un buen comando no es necesariamente el que muestra más propiedades, sino el que responde de forma clara a la pregunta que estamos investigando.

Herramientas de monitorización en GNU/Linux

GNU/Linux ofrece numerosas utilidades para consultar información del núcleo, /proc, systemd y los registros.

La dificultad no suele estar en encontrar comandos, sino en interpretar correctamente su salida y relacionarla con el servicio afectado.

Primera revisión con uptime, free, df y systemctl

Una revisión inicial puede comenzar con:

uptime
free -h
df -hT
lsblk -f
systemctl --failed
ss -lntup

Estas órdenes proporcionan una primera fotografía del sistema:

• Tiempo desde el último arranque.
• Carga media.
• Estado de la memoria.
• Uso de los sistemas de archivos.
• Dispositivos y montajes.
• Unidades fallidas.
• Puertos en escucha.

No constituyen un diagnóstico completo. Su función es ayudarnos a decidir dónde debemos profundizar.

Procesos y carga con ps, top, htop y pidstat

ps ofrece una fotografía de los procesos y resulta adecuado para scripts y filtros.

ps -eo pid,user,%cpu,%mem,rss,vsz,cmd --sort=-%cpu | head

top muestra una vista dinámica de la carga, la CPU, la memoria y los procesos.

htop ofrece una interfaz más amigable, aunque puede requerir instalación.

pidstat permite obtener estadísticas por proceso durante un intervalo y resulta útil para observar CPU, memoria y entrada o salida por PID.

También podemos utilizar pstree para comprender la relación entre procesos padre e hijos.

Rendimiento con vmstat, iostat, sar y mpstat

vmstat reúne información sobre procesos, memoria, paginación, entrada y salida y CPU.

vmstat 1 10

Este ejemplo obtiene diez muestras separadas por un segundo.

iostat permite analizar la actividad de los dispositivos:

iostat -xz 1 10

sar resulta especialmente interesante porque permite consultar datos históricos de CPU, memoria, red y almacenamiento.

mpstat muestra el uso por procesador lógico y puede ayudar a detectar desequilibrios.

Una herramienta interactiva representa el presente. Para investigar una incidencia pasada necesitamos históricos, registros persistentes o una plataforma que haya recopilado los datos.

Registros del sistema con journalctl y dmesg

journalctl permite filtrar los eventos por arranque, servicio, prioridad o periodo temporal.

journalctl -b

Muestra los eventos del arranque actual.

journalctl -p warning..alert

Filtra por prioridades.

journalctl -u ssh.service --since "today"

Consulta los eventos de una unidad concreta.

journalctl --since "10:00" --until "10:15"

Limita la revisión a un intervalo.

Para investigar un problema ocurrido antes del último reinicio podemos utilizar:

journalctl -b -1

dmesg muestra mensajes del núcleo y resulta especialmente útil al analizar controladores, almacenamiento y dispositivos de red:

dmesg --level=err,warn

Conexiones y puertos con ss e ip

Para comprobar interfaces, contadores y conexiones podemos utilizar:

ip -s link
ip route
ss -s
ss -lntup

ip -s link muestra tráfico, errores y descartes de las interfaces.

ip route permite revisar la tabla de rutas.

ss -s ofrece un resumen de sockets.

ss -lntup muestra puertos en escucha y, cuando los permisos lo permiten, los procesos relacionados.

Podemos completar el análisis con herramientas como dig para DNS o curl para comprobar una respuesta de aplicación.

Cómo diagnosticar problemas de rendimiento

El diagnóstico profesional transforma síntomas en hipótesis comprobables.

El usuario puede decir que una carpeta tarda en abrir, que una aplicación “se queda pensando” o que el servidor “se cae”. Estas descripciones son útiles, pero todavía no identifican la causa.

Diferencia entre síntoma, causa e impacto

Conviene separar cuatro conceptos:

• Síntoma: lo que se observa.
• Causa: la condición que origina el problema.
• Impacto: la consecuencia para los usuarios o el servicio.
• Solución: la acción aplicada para recuperar o corregir el sistema.

Por ejemplo:

• Síntoma: una carpeta tarda en abrir.
• Causa posible: latencia de disco provocada por una tarea de copia.
• Impacto: los usuarios no pueden acceder a tiempo a sus documentos.
• Solución temporal: reprogramar o detener de forma controlada la tarea.
• Solución definitiva: ajustar su horario, configuración o capacidad.

Una solución temporal puede recuperar el servicio sin eliminar la causa. Por eso el análisis no debería finalizar cuando desaparece el síntoma.

Cómo delimitar el alcance de una incidencia

Antes de ejecutar comandos, debemos recoger:

• Mensaje exacto.
• Hora.
• Usuario.
• Equipo cliente.
• Operación realizada.
• Servicio afectado.
• Número de usuarios implicados.
• Cambios recientes.
• Tareas programadas.

Durante mi trabajo en consultoría aprendí que el primer mensaje rara vez describe el problema completo. “El servidor va lento” es un punto de partida, no un diagnóstico. La experiencia en consultoría me enseñó precisamente a escuchar y entender la necesidad antes de proponer herramientas.

Una pregunta bien formulada puede ahorrar más tiempo que abrir varias consolas sin una hipótesis.

Cómo formular y comprobar hipótesis

Una secuencia de diagnóstico ordenada podría ser:

1. Recoger el síntoma y la hora.
2. Definir el alcance y la prioridad.
3. Revisar cambios recientes.
4. Consultar métricas y registros.
5. Comparar con la línea base.
6. Formular hipótesis por capas.
7. Ordenarlas por probabilidad e impacto.
8. Diseñar una prueba que confirme o descarte cada una.
9. Aplicar la corrección de menor riesgo.
10. Verificar desde el servidor y desde el cliente.
11. Documentar la causa y las acciones.

Siempre que el impacto lo permita, es preferible cambiar una sola variable cada vez. Si modificamos simultáneamente la configuración, reiniciamos servicios y actualizamos componentes, será difícil saber qué acción produjo el resultado.

Diagnóstico de un servidor lento

Cuando la respuesta general es lenta, debemos observar conjuntamente:

• CPU.
• Memoria.
• Almacenamiento.
• Red.
• Procesos.
• Servicios.
• Tareas programadas.
• Eventos recientes.

Podemos empezar preguntando:

• ¿La lentitud afecta a todos los usuarios?
• ¿Aparece a una hora determinada?
• ¿Afecta a todas las aplicaciones?
• ¿Existe alguna copia o actualización programada?
• ¿Hay errores de disco o red?
• ¿Ha cambiado la carga habitual?
• ¿Se instaló o modificó algo recientemente?

La correlación temporal es fundamental. Necesitamos relacionar la hora exacta del síntoma con las métricas, los registros y los cambios.

Qué hacer cuando un servicio no arranca

Cuando un servicio falla, revisaremos:

• Estado actual.
• Tipo de inicio.
• Cuenta de ejecución.
• Dependencias.
• Puertos.
• Archivos de configuración.
• Credenciales.
• Registros específicos.
• Cambios recientes.

En Windows:

Get-Service -Name NombreServicio
Get-CimInstance Win32_Service |
    Select-Object Name, State, StartMode, StartName

En Linux:

systemctl status nombre.service
systemctl list-dependencies nombre.service
systemctl show nombre.service
journalctl -u nombre.service -n 50

Antes de reiniciar debemos comprobar si existen usuarios conectados, transacciones en curso o servicios dependientes.

Cómo construir una línea temporal

Los registros adquieren mucho más valor cuando se ordenan en una secuencia.

Para construirla:

1. Fijamos el intervalo del síntoma.
2. Comprobamos que los relojes sean comparables.
3. Recogemos eventos del sistema, servicio, red y seguridad.
4. Los ordenamos por hora.
5. Buscamos eventos anteriores al fallo.
6. Relacionamos procesos, usuarios e identificadores.
7. Separamos causas, efectos y mensajes secundarios.

Un error registrado después de la caída puede ser una consecuencia y no el origen. Por eso debemos investigar también los minutos anteriores.

Arranque del servidor y recuperación ante fallos

El arranque transforma el equipo apagado en un sistema operativo capaz de prestar servicios. Comprender sus fases permite determinar dónde se encuentra un fallo.

Fases generales del arranque

De manera simplificada, el proceso incluye:

1. Firmware UEFI o BIOS.
2. Cargador de arranque.
3. Núcleo.
4. Montaje de sistemas de archivos.
5. Inicialización de servicios.
6. Disponibilidad operativa.

Cada fase presenta síntomas diferentes.

Si el disco no aparece, el problema puede encontrarse en el hardware o el firmware. También, si aparece un mensaje de sistema no encontrado, debemos revisar el cargador. Además, si el sistema se inicia pero un servicio no lo hace, la investigación se traslada a sus dependencias y registros.

Arranque de Windows Server

En Windows intervienen, entre otros componentes:

• Firmware.
• Windows Boot Manager.
• Cargador del sistema.
• Núcleo.
• Controladores.
• Administrador de sesiones.
• Administrador de control de servicios.

La configuración de arranque se almacena en BCD.

El modo seguro y el entorno de recuperación permiten iniciar el sistema con un conjunto reducido de componentes. La modificación de BCD debe realizarse únicamente con una copia y un procedimiento documentado.

Arranque de GNU/Linux con systemd

En numerosos sistemas GNU/Linux, GRUB carga el núcleo y la imagen initramfs. Posteriormente, el núcleo monta el sistema raíz e inicia systemd como proceso con PID 1.

Systemd activa unidades según sus dependencias y el objetivo configurado.

Entre sus tipos de unidad encontramos:

• service.
• socket.
• mount.
• timer.
• target.
• path.

Para localizar fallos podemos empezar con:

systemctl --failed
journalctl -b -p err
journalctl -b -1
lsblk -f
findmnt --verify

Procedimiento seguro de recuperación

Ante un fallo de arranque no conviene aplicar reparaciones al azar.

Un procedimiento prudente sería:

1. Registrar el síntoma, la hora y los mensajes.
2. Revisar los cambios recientes.
3. Confirmar el alcance.
4. Proteger los datos.
5. Comprobar las copias disponibles.
6. Elegir el método menos invasivo.
7. Aplicar un cambio cada vez.
8. Validar el arranque, la red y los servicios.
9. Consultar los registros.
10. Documentar la causa y la solución.

No deberían ejecutarse operaciones destructivas sobre el único soporte que contiene los datos.

Mantenimiento preventivo del servidor

El mantenimiento preventivo utiliza la información obtenida mediante la monitorización para reducir el riesgo de una incidencia.

No se limita a instalar actualizaciones. También incluye inventario, capacidad, registros, copias, revisión de servicios y documentación.

Inventario de hardware, software y configuración

Un inventario útil debería recoger:

• Nombre y función del servidor.
• Propietario o responsable.
• Criticidad.
• Sistema operativo.
• Versión y arquitectura.
• CPU y memoria.
• Discos y volúmenes.
• Interfaces y direcciones.
• DNS y rutas.
• Servicios.
• Puertos.
• Paquetes y aplicaciones.
• Tareas programadas.
• Ubicación y retención de registros.
• Copias disponibles.

Un listado sin explicación queda incompleto. También debemos saber por qué existe cada servicio, qué dependencias tiene y qué estado debería mantener.

Actualizaciones, compatibilidad y reinicios pendientes

Una actualización controlada sigue un ciclo:

Inventariar → evaluar → comprobar compatibilidad → preparar copia y reversión → probar → programar → instalar → validar → documentar.

Antes de actualizar debemos revisar:

• Espacio disponible.
• Compatibilidad.
• Servicios críticos.
• Reinicios pendientes.
• Dependencias.
• Copias.
• Plan de vuelta atrás.
• Ventana disponible.

Después de la instalación debemos comprobar el servicio desde el servidor y desde un cliente. También conviene revisar eventos y rendimiento.

Actualizar sin planificación puede causar indisponibilidad. No actualizar mantiene errores y problemas conocidos. El objetivo es gestionar el cambio, no evitarlo indefinidamente.

Gestión de registros, cachés y archivos temporales

Los registros deben conservarse durante el tiempo suficiente para el diagnóstico y la auditoría, pero no pueden crecer sin límite.

Una política de rotación puede:

• Crear archivos nuevos.
• Comprimir registros antiguos.
• Eliminar datos por edad.
• Limitar el tamaño.
• Transferir eventos a otro sistema.

Antes de reducir la retención debemos considerar las necesidades operativas y de seguridad.

La limpieza de temporales y cachés también debe diseñarse con cuidado. Un script no debería borrar rutas construidas a partir de variables no validadas. Además, no debemos confundir limpieza con eliminación de evidencias necesarias.

Cuotas y planificación de capacidad

Las cuotas controlan el consumo de almacenamiento por usuario, grupo o volumen.

Un límite blando permite superar temporalmente un valor durante un periodo de gracia. Un límite duro impide sobrepasarlo.

Las cuotas evitan que una única identidad consuma todo el espacio, pero no sustituyen la planificación de capacidad.

Debemos observar:

• Espacio actual.
• Velocidad de crecimiento.
• Tamaño del volumen.
• Criticidad.
• Archivos recientes.
• Registros.
• Copias antiguas.
• Temporales.
• Volcados.

No tendría sentido aplicar el mismo umbral absoluto a un volumen de 100 GB y a otro de 10 TB.

Cómo organizar una ventana de mantenimiento

Una ventana de mantenimiento define cuándo se permiten cambios que podrían afectar al servicio.

Debería incluir:

• Duración.
• Sistemas afectados.
• Responsables.
• Comunicación.
• Copia.
• Plan de reversión.
• Pruebas.
• Criterio de cancelación.
• Validación final.

En mis proyectos propios también he comprobado que ningún sistema queda terminado para siempre. El software cambia, los contenidos crecen, aparecen nuevas necesidades y las tareas manuales terminan necesitando revisión o automatización. Mi actividad actual combina desarrollo y mantenimiento de webs, contenido, recursos docentes y mejora continua.

Automatización de tareas administrativas

La automatización reduce trabajo repetitivo y facilita que las comprobaciones se realicen con una frecuencia constante.

Sin embargo, un script incorrecto puede repetir un error mucho más rápido que una persona. Por eso la automatización debe incluir controles, registros y límites.

Qué tareas conviene automatizar

Son buenas candidatas las tareas:

• Repetitivas.
• Predecibles.
• Verificables.
• Con entradas controladas.
• Con un resultado claramente medible.

Por ejemplo:

• Generar informes de capacidad.
• Comprobar servicios.
• Recopilar métricas.
• Rotar archivos.
• Validar copias.
• Revisar certificados o fechas.
• Detectar desviaciones de configuración.

No conviene automatizar una operación destructiva sin validaciones, registro y un mecanismo de recuperación.

Automatización en Windows con PowerShell

Un script sencillo puede generar un informe de los volúmenes:

$fecha = Get-Date -Format 'yyyy-MM-dd_HHmm'
$salida = 'C:\Admin\Informes\estado_' + $fecha + '.csv'

Get-CimInstance Win32_LogicalDisk -Filter "DriveType=3" |
    Select-Object DeviceID, VolumeName, Size, FreeSpace |
    Export-Csv -Path $salida -NoTypeInformation -Encoding UTF8

En un entorno real deberíamos:

• Comprobar que la carpeta existe.
• Capturar errores.
• Registrar el inicio y el final.
• Definir una política de retención.
• Utilizar una cuenta con los permisos mínimos.

Un manejo básico de errores podría utilizar try y catch:

$ErrorActionPreference = 'Stop'

try {
    # Operación administrativa
    "OK $(Get-Date)" |
        Out-File 'C:\Admin\tarea.log' -Append
}
catch {
    "ERROR $(Get-Date) $($_.Exception.Message)" |
        Out-File 'C:\Admin\tarea.log' -Append

    exit 1
}

El Programador de tareas permite definir el desencadenador, la acción, las condiciones, la cuenta y el comportamiento ante fallos.

Una tarea que funciona manualmente puede fallar al ejecutarse de forma programada por diferencias en permisos, rutas, entorno o directorio de trabajo.

Automatización en Linux con Bash y cron

Un script Bash orientativo podría generar un informe básico:

#!/usr/bin/env bash
set -euo pipefail

FECHA=$(date +%F_%H%M)
SALIDA="/var/log/estado-$FECHA.txt"

{
  echo "=== $(hostname) $(date --iso-8601=seconds) ==="
  uptime
  free -h
  df -hT
  systemctl --failed --no-pager
} > "$SALIDA"

set -euo pipefail ayuda a detectar determinados errores, aunque no sustituye un diseño seguro.

Podemos programarlo mediante cron:

30 6 * * * /usr/local/sbin/informe-estado.sh >> /var/log/informe-estado.log 2>&1

En cron conviene utilizar rutas absolutas, ya que el entorno y el PATH pueden ser distintos a los de una sesión interactiva.

Cuándo utilizar temporizadores de systemd

Los temporizadores de systemd se integran con las unidades, los estados y los registros.

Una unidad de servicio podría ser:

[Unit]
Description=Genera un informe de estado

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/informe-estado.sh

Y el temporizador:

[Unit]
Description=Ejecuta el informe diariamente

[Timer]
OnCalendar=*-*-* 06:30:00
Persistent=true

[Install]
WantedBy=timers.target

Después:

systemctl daemon-reload
systemctl enable --now informe-estado.timer
systemctl list-timers
journalctl -u informe-estado.service

Persistent=true permite recuperar determinadas ejecuciones perdidas mientras el sistema estaba apagado.

Mínimo privilegio, registro e idempotencia

Toda automatización debería:

• Utilizar el mínimo privilegio.
• Evitar credenciales en texto plano.
• Validar rutas y variables.
• Registrar inicio, fin y resultado.
• Impedir ejecuciones simultáneas cuando sean peligrosas.
• Aplicar tiempos máximos.
• Limitar los reintentos.
• Versionar el código.
• Identificar un responsable.

La idempotencia significa que una tarea puede ejecutarse varias veces sin duplicar o corromper recursos.

Si un script crea una carpeta, debe comprobar primero si existe. Si añade una línea de configuración, debe evitar insertarla repetidamente.

La automatización debe reducir errores, no ocultarlos. Un servicio que se reinicia automáticamente de manera ilimitada puede parecer disponible mientras su fallo se repite continuamente.

Procesos, servicios y dependencias

Un proceso es una instancia de un programa en ejecución. Un servicio es un proceso o conjunto de procesos administrado para ofrecer una función al sistema o a la red.

Antes de reiniciar un servicio debemos conocer:

• Su estado.
• Tipo de inicio.
• Cuenta.
• Dependencias.
• Puertos.
• Usuarios conectados.
• Trabajos pendientes.
• Registros.
• Acciones de recuperación.

Gestión de servicios en Windows Server

Podemos consultar un servicio con:

Get-Service -Name DNS

Para revisar más propiedades:

Get-CimInstance Win32_Service |
    Select-Object Name, State, StartMode, StartName

Y para consultar servicios dependientes:

Get-Service -Name NombreServicio |
    Select-Object -ExpandProperty DependentServices

Antes de ejecutar una acción podemos utilizar -WhatIf cuando esté disponible:

Restart-Service -Name NombreServicio -WhatIf

Las acciones automáticas de recuperación deben acompañarse de alertas y registros. De lo contrario, un problema repetitivo puede permanecer oculto.

Gestión de servicios con systemd

En Linux:

systemctl status ssh.service
systemctl is-enabled ssh.service
systemctl list-dependencies ssh.service
systemctl show ssh.service
journalctl -u ssh.service -n 50

Cuando necesitemos modificar una unidad, es preferible utilizar un override:

systemctl edit nombre.service

Después:

systemctl daemon-reload
systemctl restart nombre.service

Editar directamente los archivos distribuidos por un paquete puede provocar que una actualización reemplace los cambios.

Cómo reiniciar sin perder información relevante

Antes de reiniciar:

1. Confirmamos que el servicio es el componente afectado.
2. Revisamos usuarios y operaciones.
3. Conservamos las métricas.
4. Exportamos los registros necesarios.
5. Comprobamos las dependencias.
6. Definimos la validación posterior.
7. Registramos la acción.

Un reinicio puede recuperar temporalmente el servicio, pero también borrar el estado necesario para diagnosticar la causa.

Documentación y control de cambios

La monitorización y mantenimiento de servidores pierde gran parte de su valor cuando las intervenciones no quedan documentadas.

Un registro de cambios debería indicar:

• Fecha y hora.
• Responsable.
• Motivo.
• Sistemas afectados.
• Configuración modificada.
• Copia disponible.
• Plan de reversión.
• Pruebas realizadas.
• Resultado.
• Incidencias observadas.

Durante mi experiencia profesional he trabajado con documentación, gestión de peticiones y mejora de procesos. Ese recorrido me ha confirmado que resolver el síntoma no es suficiente si la siguiente persona debe empezar la investigación desde cero.

Documentar no es una tarea administrativa separada de la solución. Permite:

• Repetir una intervención correcta.
• Revertir un cambio.
• Comparar futuras incidencias.
• Conocer la configuración esperada.
• Reducir el tiempo de diagnóstico.
• Transferir conocimiento.

Estado deseado y desviaciones

El estado deseado describe cómo debería estar configurado el sistema.

Una desviación aparece cuando la configuración real cambia debido a:

• Una intervención manual.
• Una actualización.
• Un error.
• Una instalación no autorizada.
• Una automatización defectuosa.

El inventario, las revisiones periódicas y los scripts de comprobación ayudan a detectar estas diferencias.

La documentación debe mantenerse actualizada. Un documento muy detallado pero desfasado puede resultar más peligroso que uno sencillo y correcto.

Lista de comprobación para monitorizar y mantener un servidor

La frecuencia exacta dependerá de la criticidad, la carga y las características del entorno. Esta lista sirve como punto de partida.

Comprobaciones diarias

• Verificar la disponibilidad de los servicios críticos.
• Revisar alertas y errores recientes.
• Comprobar el espacio disponible.
• Confirmar el resultado de las copias.
• Revisar tareas programadas.
• Detectar servicios fallidos.
• Observar cambios anómalos de CPU, memoria, disco y red.
• Comprobar el acceso desde un cliente cuando sea necesario.

Comprobaciones semanales

• Analizar tendencias de capacidad.
• Revisar el crecimiento de registros.
• Comprobar actualizaciones disponibles.
• Verificar errores repetitivos.
• Revisar las cuentas y tareas utilizadas por automatizaciones.
• Comparar métricas con la línea base.
• Examinar servicios reiniciados automáticamente.
• Confirmar que los informes se generan correctamente.

Durante una ventana de mantenimiento

• Comunicar el cambio.
• Confirmar las copias.
• Revisar espacio y dependencias.
• Preparar la reversión.
• Registrar el estado inicial.
• Aplicar un cambio cada vez.
• Conservar la salida de los comandos.
• Respetar el criterio de cancelación.
• Revisar errores y advertencias.

Después de aplicar un cambio

• Confirmar el arranque.
• Comprobar la red.
• Revisar los servicios.
• Validar puertos.
• Probar desde un cliente.
• Consultar los registros.
• Comparar el rendimiento.
• Confirmar las tareas programadas.
• Documentar el resultado.
• Mantener abierta la investigación si solo se corrigió el síntoma.

Conclusión: convertir métricas en decisiones

La monitorización y mantenimiento de servidores no puede reducirse a observar porcentajes o ejecutar comandos de memoria.

Una administración eficaz necesita contexto, históricos, registros, procedimientos y documentación. También exige distinguir entre una cifra llamativa y una incidencia real.

CPU, memoria, almacenamiento y red deben analizarse conjuntamente. Las herramientas de Windows Server y GNU/Linux nos permiten observar el sistema desde perspectivas diferentes, pero ninguna sustituye el razonamiento.

Mi forma de abordar estos problemas parte de tres ideas que he desarrollado entre el software, la consultoría y la docencia: analizar con estructura, escuchar antes de proponer y explicar sin complicar.

En la práctica, una estrategia sólida de monitorización y mantenimiento de servidores sigue siempre un ciclo similar:

Observar, comparar, detectar, investigar, actuar, verificar y documentar.

Cuando este ciclo está respaldado por una línea base, alertas útiles, procedimientos seguros y automatizaciones controladas, el servidor deja de administrarse únicamente a golpe de incidencia.

El objetivo final no es que nunca ocurra un fallo. Es detectar antes las desviaciones, limitar el impacto, diagnosticar con evidencias y conseguir que cada incidencia mejore la forma en que mantenemos el sistema.

Preguntas frecuentes sobre monitorización y mantenimiento de servidores

¿Qué se debe monitorizar en un servidor?

Como mínimo, debemos vigilar CPU, memoria, almacenamiento, red, procesos, servicios, registros, espacio disponible y disponibilidad de las aplicaciones críticas. También conviene revisar las tareas programadas, las copias y los cambios de configuración.

¿Qué diferencia existe entre monitorización y mantenimiento?

La monitorización recoge y analiza información sobre el estado y la evolución del sistema. El mantenimiento utiliza esa información para conservar el servidor en condiciones adecuadas mediante actualizaciones, revisiones, limpieza controlada y otras actuaciones.

¿Qué herramientas se utilizan en Windows Server?

Entre las herramientas principales se encuentran el Administrador de tareas, el Monitor de recursos, el Monitor de rendimiento, los conjuntos de recopiladores de datos, el Visor de eventos y PowerShell.

¿Qué comandos sirven para monitorizar Linux?

Algunos comandos útiles son uptime, free, df, ps, top, vmstat, iostat, sar, systemctl, journalctl, dmesg, ss e ip. Cada uno responde a preguntas diferentes y debe interpretarse dentro del contexto del servicio.

¿Un uso elevado de CPU siempre representa un problema?

No. Puede indicar que el servidor está realizando trabajo útil. Hay que comprobar la duración del consumo, los procesos implicados, la cola de ejecución y el impacto sobre los usuarios.

¿Cómo se detecta una falta real de memoria?

Debemos revisar la memoria disponible, el compromiso, la paginación o swap sostenida, el consumo por proceso y la respuesta de las aplicaciones. Una gran cantidad de memoria utilizada puede corresponder a caché liberable.

¿Cómo se diagnostica un almacenamiento lento?

Se revisan la latencia, la cola, las IOPS, el rendimiento, el espacio disponible, los errores y los procesos que generan actividad. También conviene comprobar copias, antivirus, indexación, controladores y estado físico.

¿Por qué no conviene reiniciar el servidor inmediatamente?

Porque el reinicio puede eliminar información necesaria para descubrir la causa, afectar a otros servicios o limitarse a ocultar temporalmente el problema. Antes de reiniciar deben conservarse métricas, registros y estado.

¿Qué diferencia existe entre cron y un temporizador de systemd?

Cron es apropiado para programaciones sencillas. Los temporizadores de systemd se integran con las unidades, las dependencias, el estado y los registros del sistema.

¿Qué significa que una automatización sea idempotente?

Significa que puede ejecutarse varias veces y mantener el mismo estado final deseado sin duplicar elementos ni corromper recursos.