Cómo monitorizar infraestructura NAS con señales útiles y sin ruido operativo

Introducción

Monitorizar un NAS no consiste en observar todos los datos que el equipo es capaz de generar, sino en seleccionar unas pocas señales capaces de cambiar una decisión operativa.

En una microempresa, un NAS puede concentrar documentos, carpetas compartidas, copias de seguridad, históricos, sincronizaciones, servicios internos, contenedores o accesos remotos. Ese papel lo convierte en una pieza importante de la infraestructura, pero no justifica desplegar un sistema de monitorización propio de un centro de datos.

El problema aparece cuando se confunden tres cosas diferentes: tener métricas, tener alertas y tener control. Un panel con veinte gráficos puede mostrar mucha información y, aun así, no advertir de que la última copia válida tiene cuatro días, que un volumen está degradado o que el almacenamiento crecerá hasta agotarse dentro de tres semanas. Del mismo modo, recibir decenas de correos diarios puede dar sensación de vigilancia mientras las alertas realmente importantes terminan ignoradas.

El objetivo práctico debe ser otro: construir una supervisión pequeña, comprensible y accionable. Cada señal importante debería responder a una pregunta concreta, tener un responsable y conducir a una actuación razonable cuando cambia de estado.

Este artículo desarrolla ese enfoque: cómo decidir qué monitorizar, cómo separar indicadores de alertas, qué señales aportan más valor, cómo fijar umbrales útiles y cómo reducir el ruido operativo sin dejar que los problemas importantes pasen inadvertidos.

Índice

• El objetivo real de la monitorización de un NAS
• Empezar por un mapa de dependencias, no por las métricas
• Crear una línea base antes de definir alertas
• Señales que sí merecen atención operativa
• Métricas útiles como contexto, pero malas como alarma aislada
• Cómo definir umbrales sin inventar números arbitrarios
• Separar aviso, incidencia y emergencia
• Cómo reducir ruido operativo
• Por qué el NAS no debería vigilarse solo a sí mismo
• Cuadro mínimo de monitorización para una microempresa
• Rutina diaria, semanal, mensual y trimestral
• Ejemplo práctico de una infraestructura NAS pequeña
• Cómo implantar la monitorización por fases
• Errores frecuentes
• Preguntas frecuentes
• Conclusión

El objetivo real de la monitorización de un NAS

Una infraestructura no se monitoriza para acumular datos. Se monitoriza para reducir el tiempo entre la aparición de un problema relevante y la decisión de actuar.

Esta idea permite descartar buena parte del ruido desde el principio. Si una métrica cambia y nadie haría nada diferente al verla, probablemente no necesita convertirse en una alerta. Puede conservarse como información histórica o como dato de diagnóstico, pero no debería interrumpir a una persona.

Una señal operativa de calidad suele cumplir varias condiciones:

• está vinculada a una función concreta del NAS;
• permite detectar un fallo o una degradación antes de que el impacto sea grave;
• tiene una interpretación razonablemente clara;
• puede asociarse a una acción o procedimiento;
• su frecuencia de aparición es suficientemente baja como para que no se ignore;
• puede verificarse cuando vuelve a la normalidad.

Por ejemplo, conocer que la CPU alcanzó el 92 % durante veinte segundos puede ser interesante para diagnosticar un proceso, pero rara vez exige una actuación por sí solo. En cambio, saber que el último backup nocturno terminó con error, que el volumen ha pasado a estado degradado o que el espacio libre caerá por debajo del margen operativo previsto sí puede cambiar lo que se hace esa mañana.

La diferencia entre telemetría y monitorización operativa está en la capacidad de decidir.

Empezar por un mapa de dependencias, no por las métricas

Antes de configurar avisos conviene responder una pregunta más básica: ¿qué funciones empresariales dependen realmente del NAS?

No es lo mismo un NAS utilizado como archivo secundario que otro que contiene las carpetas de trabajo activas, recibe los backups de todos los ordenadores, ejecuta aplicaciones internas y proporciona acceso remoto. Dos equipos físicamente parecidos pueden requerir niveles de supervisión muy distintos.

Identificar funciones críticas

El inventario puede ser sencillo. Para cada función basta con anotar qué servicio presta, qué datos utiliza, quién depende de ella y qué ocurriría si estuviera indisponible durante una hora, un día o varios días.

Las funciones habituales pueden incluir:

• carpetas compartidas de trabajo;
• repositorio de documentos e históricos;
• destino de copias de ordenadores y servidores;
• replicación hacia otro NAS o hacia almacenamiento externo;
• sincronización con portátiles o dispositivos móviles;
• VPN y acceso remoto;
• servicios web internos;
• contenedores o máquinas virtuales;
• multimedia o materiales de producción;
• repositorios técnicos y documentación.

Si el NAS se ha convertido en una pieza central del negocio, conviene relacionar esta supervisión con un plan más amplio de continuidad operativa con NAS en una microempresa. La monitorización detecta; la continuidad define cómo seguir trabajando cuando la detección confirma que algo importante ha fallado.

Separar dominios de fallo

Después conviene agrupar las dependencias en dominios. Un modelo práctico puede utilizar seis:

• almacenamiento: discos, RAID, pools, volúmenes y capacidad;
• protección del dato: backups, snapshots y replicaciones;
• servicios: SMB, NFS, aplicaciones, contenedores, VPN u otros procesos;
• red: enlace, errores, resolución, acceso local y remoto;
• seguridad: autenticaciones, cambios administrativos y actividad anómala;
• entorno físico: temperatura, ventilación, alimentación y SAI si existe.

Este mapa evita que la monitorización nazca condicionada por lo que ofrece un panel concreto. Primero se decide qué puede fallar; después se elige qué dato permite detectarlo.

Crear una línea base antes de definir alertas

Un umbral carece de contexto si no se conoce el comportamiento normal del sistema. La misma utilización de CPU, tráfico de red o latencia de disco puede ser completamente razonable durante una copia nocturna y extraña a media mañana.

Antes de activar demasiados avisos conviene observar el NAS durante un periodo representativo y registrar patrones básicos:

• ocupación habitual y crecimiento semanal del almacenamiento;
• duración normal de los backups;
• ventanas de mayor actividad;
• temperaturas habituales;
• tráfico de red durante sincronizaciones y copias;
• uso de memoria y CPU en reposo y durante tareas programadas;
• tiempos normales de respuesta de los servicios principales.

La línea base no necesita una precisión científica. Su función es distinguir lo esperado de lo anómalo. Una copia que normalmente tarda cuarenta minutos y un día tarda cuatro horas merece atención aunque haya terminado correctamente. Del mismo modo, un volumen que crece un 1 % mensual requiere una planificación diferente de otro que aumenta un 8 %.

La idea coincide con un principio más general: medir solo aquello que ayuda a decidir. El artículo sobre cómo crear métricas empresariales útiles sin medir por medir aplica el mismo criterio al ámbito del negocio.

Señales que sí merecen atención operativa

No existe una lista universal, pero una microempresa puede obtener mucha cobertura con un conjunto pequeño de señales bien escogidas.

Disponibilidad real del NAS

La pregunta más básica es si el equipo puede alcanzarse desde el lugar desde el que debe prestar servicio. No basta con que el sistema operativo crea que está funcionando.

Una comprobación externa puede verificar, por ejemplo, que el NAS responde en red y que el servicio de archivos o la aplicación interna realmente acepta conexiones. Esta diferencia es importante: un equipo puede responder a ping mientras el servicio que utiliza la empresa está detenido.

Cuando el NAS presta varias funciones, conviene vigilar por separado las realmente críticas. No hace falta comprobar veinte puertos; sí aquellos cuya caída impediría trabajar.

Estado del pool, RAID o grupo de almacenamiento

El estado degradado de un conjunto redundante es una de las señales que menos margen dejan para la indiferencia. Mientras el sistema sigue funcionando, puede parecer que no ocurre nada, pero la tolerancia frente a un segundo fallo se ha reducido.

Por eso el cambio de estado del pool o RAID debe producir una alerta clara, con información suficiente para saber qué unidad está afectada y qué procedimiento corresponde ejecutar.

La redundancia no sustituye a las copias. Si el NAS forma parte de la estrategia de protección, conviene separar claramente disponibilidad y backup, como se explica al centralizar backups corporativos en un NAS con criterio práctico.

Salud resumida de los discos

Los atributos SMART, las pruebas internas y los contadores de errores ofrecen mucha información, pero no todos deben convertirse en una notificación individual.

Para la monitorización general interesa una señal resumida capaz de indicar que una unidad está empeorando o que una prueba programada ha fallado. El análisis detallado —temperatura, sectores reasignados, sectores pendientes, errores de lectura o pruebas extendidas— merece su propio procedimiento y se desarrolla en cómo monitorizar la salud de los discos duros en un NAS antes de que fallen.

En este nivel, el objetivo es que un problema físico no permanezca oculto hasta que el RAID se degrade.

Capacidad libre y velocidad de crecimiento

El porcentaje de espacio libre es útil, pero todavía lo es más cuando se combina con la velocidad de crecimiento.

Un 20 % libre puede ser cómodo si la ocupación apenas cambia y peligroso si se están generando cientos de gigabytes cada semana. Por eso conviene vigilar dos variables:

• margen libre actual;
• tendencia de consumo.

La alerta debería llegar con tiempo para decidir: limpiar, archivar, ampliar discos, mover datos o cambiar políticas de retención. Una alarma que aparece cuando quedan unas pocas horas de capacidad no es prevención; es una cuenta atrás.

Integridad y estado de los volúmenes

No todos los problemas de almacenamiento se reducen a un disco roto. También pueden aparecer sistemas de archivos en modo de solo lectura, errores del volumen, tareas de comprobación fallidas o recursos compartidos que dejan de montarse correctamente.

Estas señales deben tener prioridad porque pueden afectar directamente a la escritura de datos aunque la interfaz general del NAS continúe accesible.

Último backup válido, no solo último backup ejecutado

Una de las señales más valiosas es la antigüedad de la última copia terminada correctamente.

La diferencia semántica importa. Una tarea puede haberse ejecutado a las 02:00 y haber terminado con error. Por tanto, la monitorización debe preguntar:

• ¿cuándo terminó la última copia correcta?;
• ¿qué origen debía copiar?;
• ¿qué destino utilizó?;
• ¿hay errores o exclusiones relevantes?;
• ¿la duración se aleja mucho de lo habitual?

Para copias importantes, la señal ideal no es simplemente “job ejecutado”, sino “punto de recuperación disponible dentro del margen definido”.

Freshness de snapshots y replicaciones

Si se utilizan snapshots o replicaciones, conviene controlar su freshness: cuánto tiempo ha pasado desde el último punto válido.

No es necesario convertir cada snapshot creado en un correo. Interesa detectar que dejó de crearse cuando debía, que una replicación acumula retraso o que la retención está siendo eliminada antes de lo previsto.

Los snapshots cumplen una función distinta de los backups. Para no mezclar ambos mecanismos, conviene revisar cómo usar snapshots empresariales en un NAS sin confundirlos con backups.

Estado de servicios críticos

Si el NAS ejecuta aplicaciones, el estado global del equipo no basta. Hay que comprobar aquello que los usuarios necesitan.

Un servicio puede considerarse saludable cuando:

• el proceso está activo;
• el puerto correspondiente responde;
• la aplicación devuelve una respuesta válida;
• puede acceder a sus datos si depende de un volumen;
• no está reiniciándose continuamente.

En un NAS con Docker, por ejemplo, la monitorización debe distinguir entre “contenedor en ejecución” y “servicio realmente funcional”. El diseño general de este tipo de despliegues se trata en cómo desplegar Docker en un NAS con orden, seguridad y mantenimiento.

Red: enlace, errores y accesibilidad

El tráfico alto no es necesariamente un problema. Puede ser exactamente lo esperado durante una copia. En cambio, sí interesa detectar:

• pérdida de enlace;
• cambio inesperado de velocidad negociada;
• aumento persistente de errores o descartes;
• pérdida de conectividad hacia recursos necesarios;
• latencia anormal sostenida cuando afecta a un servicio;
• fallo de acceso remoto cuando ese acceso forma parte de la operativa.

Si el NAS actúa como punto de acceso remoto seguro, la disponibilidad debe relacionarse con el servicio concreto. En ese contexto puede ser útil el artículo sobre cómo usar un NAS como servidor VPN para acceso seguro a la empresa.

Temperatura, ventilación y alimentación

Los problemas físicos suelen ser silenciosos hasta que dejan de serlo. Por eso conviene observar:

• temperatura anormal y sostenida;
• ventiladores detenidos o fuera de rango;
• cambios repetidos entre alimentación normal y batería;
• estado del SAI si el NAS está conectado a uno;
• apagados inesperados o reinicios no planificados.

La alerta debe centrarse en condiciones persistentes o estados claramente anómalos. Una variación térmica breve durante una tarea intensiva puede ser normal; un aumento sostenido respecto a la línea base merece investigación.

Eventos administrativos y actividad anómala

La monitorización operativa no debe transformarse en un sistema SIEM improvisado, pero algunos eventos merecen visibilidad:

• múltiples fallos de autenticación;
• inicio de sesión administrativo no esperado;
• creación de una cuenta con privilegios elevados;
• cambio importante de permisos;
• borrado o modificación masiva de archivos fuera del patrón habitual;
• activación inesperada de un servicio de acceso remoto.

El detalle de auditoría de personas y accesos pertenece a otro problema. Para profundizar en él sin mezclar objetivos, puede consultarse cómo monitorizar usuarios de un NAS para mejorar seguridad y control operativo.

Métricas útiles como contexto, pero malas como alarma aislada

Una de las principales fuentes de ruido es convertir cualquier valor elevado en una alerta. Hay métricas que son excelentes para investigar una incidencia y malas para decidir que existe una incidencia.

CPU alta

La CPU puede alcanzar valores elevados durante compresión, indexación, antivirus, generación de miniaturas, backups o mantenimiento. Un pico corto no demuestra un problema.

Se vuelve más interesante cuando coincide con latencia de servicio, colas persistentes, reinicios o una tarea desconocida. En ese caso actúa como evidencia, no necesariamente como causa.

Memoria ocupada

Muchos sistemas utilizan memoria libre como caché. Por eso “90 % de RAM utilizada” puede ser completamente normal. Resulta más útil observar presión real de memoria, intercambio persistente, procesos terminados por falta de memoria o degradación visible del servicio.

Tráfico de red elevado

Una interfaz a alta utilización durante una copia grande puede indicar que está haciendo exactamente lo que se espera. El dato cobra sentido cuando aparece pérdida, errores, colas o impacto sostenido sobre servicios interactivos.

Número de procesos o contenedores

El número absoluto aporta poco sin una referencia. Lo relevante es que desaparezca un servicio necesario, que aparezca uno inesperado o que un proceso entre en un ciclo de reinicios.

Volumen de logs

Más registros no equivalen automáticamente a más problemas. Alertar por cada línea con la palabra “warning” produce rápidamente fatiga. Los logs son especialmente valiosos para correlacionar y diagnosticar después de que una señal operativa indique que algo se ha desviado.

Una buena regla es reservar las interrupciones humanas para estados y consecuencias, y utilizar las métricas de recursos como contexto.

Cómo definir umbrales sin inventar números arbitrarios

Copiar umbrales de Internet suele ser tentador, pero una cifra que funciona en un NAS doméstico puede ser absurda en un entorno de trabajo. Los umbrales deberían derivarse de la capacidad de reacción necesaria.

Trabajar hacia atrás desde la consecuencia

Para el espacio en disco, por ejemplo, la pregunta no debería ser solo “¿a qué porcentaje aviso?”, sino:

1. ¿cuánto espacio se consume normalmente por día o semana?;
2. ¿cuánto tarda la empresa en ampliar o liberar capacidad?;
3. ¿qué margen de seguridad necesita?;
4. ¿qué ocurre cuando el volumen se acerca al límite?

Si ampliar almacenamiento requiere comprar discos y planificar una intervención, el aviso debe aparecer con suficiente antelación para completar ese proceso sin urgencia.

Usar duración además de valor

Para métricas variables conviene combinar valor y tiempo. No es igual una temperatura alta durante treinta segundos que durante veinte minutos, ni una latencia elevada durante una tarea programada que una degradación sostenida en horario de trabajo.

La lógica puede expresarse conceptualmente así:

alertar si:
  condición_anómala = verdadera
  durante >= tiempo_mínimo
  y no existe mantenimiento_programado

Usar histéresis para evitar alertas que oscilan

Cuando una métrica se mueve alrededor del límite, puede entrar y salir continuamente del estado de alarma. La histéresis evita ese efecto.

Por ejemplo, una alerta puede activarse al superar un nivel y no considerarse recuperada hasta descender claramente por debajo de otro. Así se evitan mensajes de apertura y cierre cada pocos minutos.

Alertar por tendencia cuando el problema es gradual

Algunas incidencias no necesitan un umbral instantáneo. El crecimiento de almacenamiento, la duración de backups o ciertos contadores de errores se interpretan mejor como tendencia.

Una señal que diga “al ritmo actual quedan aproximadamente seis semanas de margen” puede ser mucho más útil que “ocupación: 82 %”.

Separar aviso, incidencia y emergencia

No todo lo que merece atención merece la misma atención. Una clasificación sencilla ayuda a que el canal de comunicación transmita prioridad.

La clasificación debe ser corta. Si se crean diez niveles, nadie recuerda qué significan. En una microempresa suele importar más que cada nivel tenga una expectativa clara que alcanzar una taxonomía sofisticada.

También conviene enviar una notificación de recuperación cuando el estado vuelve a ser correcto. Sin ella, una persona puede seguir creyendo que la incidencia permanece abierta o, peor aún, acostumbrarse a comprobar manualmente si cada alerta “se arregló sola”.

Cómo reducir ruido operativo

El ruido no se resuelve simplemente desactivando notificaciones. Se reduce diseñando mejor la lógica de alerta.

Agrupar eventos relacionados

Si cae el NAS, también pueden aparecer como caídos SMB, VPN, contenedores, sincronización y varios servicios internos. Enviar seis avisos independientes describe seis síntomas de una sola causa.

Siempre que sea posible, la monitorización debe reconocer dependencias y presentar el problema raíz o, al menos, agrupar los eventos relacionados.

Evitar avisos de éxito repetitivos

Un correo diario que dice “backup correcto” puede parecer tranquilizador durante la primera semana y convertirse en decoración digital después. Es preferible conservar los éxitos en un registro o resumen y reservar la interrupción para el fallo o el retraso.

Aplicar ventanas de mantenimiento

Durante actualizaciones, reinicios o pruebas programadas es normal que ciertos servicios desaparezcan temporalmente. Si el sistema conoce esa ventana, puede registrar el evento sin generar una falsa incidencia.

Establecer persistencia mínima

Una pérdida de conectividad de pocos segundos puede ser irrelevante. Si el objetivo es detectar indisponibilidad real, una alerta puede exigir varios fallos consecutivos antes de notificarse.

Deduplicar

Mientras una incidencia permanece abierta, repetir el mismo correo cada cinco minutos rara vez mejora la respuesta. Conviene emitir la apertura, quizá un recordatorio espaciado si persiste y después el cierre.

Asignar propietario y acción

Cada alerta importante debería indicar al menos:

• qué ha cambiado;
• qué elemento está afectado;
• desde cuándo;
• qué impacto puede tener;
• dónde comprobarlo;
• qué procedimiento inicial seguir.

Si una alerta necesita diez minutos de investigación solo para descubrir qué quiere decir, está trasladando al receptor un trabajo que debería haberse resuelto al diseñarla.

Por qué el NAS no debería vigilarse solo a sí mismo

Las herramientas integradas del NAS son muy útiles: conocen los discos, el volumen, los servicios, los sensores y los trabajos programados. Sin embargo, tienen una limitación inevitable: si el propio NAS queda apagado, bloqueado o desconectado, puede perder también la capacidad de avisar.

Por eso conviene mantener al menos una comprobación independiente desde fuera del equipo.

Qué puede comprobar un observador externo

Sin desplegar una plataforma compleja, otro dispositivo o servicio puede verificar:

• que el NAS responde en la red;
• que un servicio crítico acepta conexiones;
• que una página interna o endpoint de salud responde;
• que la VPN sigue accesible cuando forma parte de la operativa;
• que la última señal periódica esperada sigue llegando.

La señal de vida

Un patrón especialmente sencillo es el heartbeat: el NAS o una tarea periódica envían una señal de vida a un sistema independiente. La ausencia de esa señal dentro del intervalo previsto genera el aviso.

La ventaja es que permite detectar el silencio total. No depende de que el NAS pueda enviar un correo después de haber sufrido el fallo.

No duplicar toda la monitorización

Independencia no significa montar dos plataformas completas. La herramienta interna puede seguir vigilando sensores, almacenamiento y tareas; la externa solo necesita comprobar que el conjunto continúa vivo y accesible.

Esta pequeña separación mejora mucho la cobertura sin disparar la complejidad.

Cuadro mínimo de monitorización para una microempresa

Una configuración inicial razonable puede resumirse en pocas señales. La siguiente tabla no pretende imponer cifras universales, sino mostrar qué debe observarse y qué decisión debería provocar.

Con estas señales se cubren buena parte de los fallos que pueden afectar a una infraestructura NAS pequeña. Todo lo demás puede incorporarse cuando exista un problema concreto que lo justifique.

Rutina diaria, semanal, mensual y trimestral

La monitorización funciona mejor cuando la revisión humana también tiene una cadencia proporcionada. No todo requiere atención diaria.

Durante el día: trabajar por excepción

La regla normal debería ser no entrar al panel del NAS simplemente para comprobar que “todo sigue verde”. Las alertas críticas y de incidencia deben llegar al canal adecuado. Si no hay excepciones, la persona responsable puede continuar con su trabajo.

Revisión semanal

Una revisión corta puede comprobar:

• alertas abiertas durante la semana;
• último backup válido;
• estado de discos y almacenamiento;
• espacio libre y crecimiento;
• servicios que hayan sufrido reinicios;
• eventos de acceso llamativos.

No debería convertirse en una auditoría completa. Su función es detectar tendencias que todavía no justifican interrumpir a nadie.

Revisión mensual

Mensualmente tiene más sentido observar tendencias:

• crecimiento de capacidad;
• duración de las copias;
• errores recurrentes;
• temperaturas y ventilación;
• servicios poco utilizados que quizá puedan retirarse;
• cambios de usuarios o privilegios;
• alertas demasiado frecuentes que necesiten reajuste.

Revisión trimestral

La revisión trimestral puede incluir una prueba pequeña de recuperación. No basta con saber que el backup termina correctamente: la empresa necesita comprobar de vez en cuando que puede extraer datos útiles de él.

También es un buen momento para revisar procedimientos, destinatarios de alertas, cuentas técnicas y el propio diseño de monitorización. Si una alerta lleva tres meses disparándose sin provocar ninguna acción, probablemente está mal definida.

Ejemplo práctico de una infraestructura NAS pequeña

Supongamos una microempresa con cinco puestos de trabajo. El NAS centraliza documentos, recibe copias nocturnas de los equipos y ejecuta una pequeña aplicación interna. Existe además una copia externa diaria de los datos críticos.

Una monitorización proporcionada podría funcionar así:

1. el propio NAS vigila discos, pool, temperatura, ventiladores, trabajos de backup y espacio disponible;
2. la aplicación interna tiene una comprobación de salud sencilla;
3. otro dispositivo de la red comprueba cada pocos minutos que el NAS y la aplicación responden;
4. la copia externa registra cuándo terminó el último trabajo correcto;
5. los avisos críticos llegan inmediatamente al responsable;
6. los avisos de tendencia se agrupan en una revisión semanal;
7. los resultados normales quedan registrados, pero no generan correos individuales.

Ahora imaginemos tres incidentes distintos.

Caso 1: pico de CPU durante un backup

La CPU alcanza un valor alto durante veinte minutos, pero el servicio de archivos mantiene tiempos normales y la copia termina correctamente. Se conserva la métrica, pero no se genera una incidencia.

Caso 2: backup que no se completa

La tarea nocturna falla. A primera hora, la antigüedad del último backup válido supera el margen previsto. Se genera una incidencia con el nombre de la tarea, el último éxito y el error resumido. Hay una acción clara: comprobar origen, destino y espacio.

Caso 3: NAS apagado por un problema de alimentación

El equipo ya no puede enviar correos. Sin embargo, la comprobación externa detecta la pérdida de disponibilidad y avisa. Si existe SAI gestionado, su estado puede aportar además contexto sobre la causa.

Este ejemplo muestra por qué una arquitectura pequeña puede ofrecer más control que un panel enorme: cada señal está vinculada a una decisión concreta.

Cómo implantar la monitorización por fases

Intentar configurar todas las métricas posibles desde el primer día suele terminar en una montaña de avisos. Es más sostenible avanzar por capas.

Fase 1: detectar fallos que no pueden permanecer ocultos

Empieza con:

• disponibilidad externa;
• estado del pool o RAID;
• fallos graves de discos;
• backup vencido;
• capacidad próxima a un límite operativo;
• temperatura o ventilación anómalas.

Con esto ya se cubren varios riesgos de alto impacto.

Fase 2: añadir servicios y dependencias

Después incorpora comprobaciones de los servicios que realmente utiliza la empresa: carpetas, VPN, aplicaciones internas, contenedores o replicaciones.

Fase 3: incorporar tendencias

Cuando haya datos suficientes, añade crecimiento de almacenamiento, duración de backups, errores de red persistentes o degradaciones de rendimiento.

Fase 4: eliminar lo que no aporta

La cuarta fase no consiste en añadir más, sino en retirar. Revisa cada alerta y pregunta:

• ¿alguna vez ha provocado una acción útil?;
• ¿se dispara durante situaciones normales?;
• ¿duplica otra señal mejor?;
• ¿puede pasar a un resumen en lugar de interrumpir?;
• ¿sigue existiendo el servicio que pretendía proteger?

La monitorización es también un sistema que necesita mantenimiento. Si solo crece y nunca se poda, termina convirtiéndose en otra fuente de deuda técnica.

Errores frecuentes

Alertar por todo lo que supere un porcentaje

Los recursos informáticos tienen patrones variables. CPU, RAM o tráfico no deben juzgarse solo por un porcentaje aislado. Hay que observar duración, contexto e impacto.

Confiar únicamente en correos enviados por el propio NAS

Funcionan bien mientras el NAS conserve red, alimentación y capacidad de ejecutar el servicio de notificación. Para detectar silencio total hace falta al menos una comprobación externa.

Confundir backup ejecutado con backup recuperable

Un trabajo terminado no garantiza por sí solo que exista un punto de recuperación útil. Hay que vigilar el último éxito válido y probar restauraciones periódicamente.

Convertir cada log en una alerta

Los registros sirven para investigar. Un sistema que notifica cada warning obliga a leer demasiado y termina ocultando lo importante.

No distinguir mantenimiento de incidencia

Reiniciar deliberadamente un servicio no debería generar el mismo flujo de avisos que una caída inesperada. Las ventanas de mantenimiento reducen falsas alarmas.

No tener responsable

Una alerta enviada a una dirección genérica que nadie revisa no es monitorización. Es archivo automático de problemas.

No revisar el sistema de alertas

Los servicios cambian, los volúmenes crecen y las prioridades empresariales evolucionan. Una configuración correcta hoy puede generar ruido dentro de un año.

Intentar convertir un NAS pequeño en un centro de operaciones

Prometheus, Grafana, agentes, exporters, bases de series temporales y sistemas de alertas avanzados pueden ser excelentes herramientas cuando existe una necesidad real. Pero una microempresa no obtiene valor por desplegarlos simplemente porque sean técnicamente interesantes.

La arquitectura correcta es la más pequeña que detecta de forma fiable los fallos que importan.

Preguntas frecuentes

Conclusión

Monitorizar bien una infraestructura NAS no exige observarlo todo. Exige conocer qué funciones sostienen la operativa y elegir las señales que permiten detectar a tiempo su degradación.

En una microempresa, unas pocas comprobaciones bien diseñadas suelen aportar más valor que decenas de gráficos: disponibilidad externa, estado del almacenamiento, salud de discos, margen de capacidad, último backup válido, protección mediante snapshots o replicaciones, servicios críticos, temperatura, alimentación y algunos eventos administrativos sensibles.

El resto de métricas siguen siendo útiles, pero principalmente como contexto para diagnosticar. Convertirlas todas en alarmas genera exactamente el efecto contrario al buscado: demasiados avisos, poca atención y problemas importantes perdidos entre mensajes irrelevantes.

La monitorización útil es silenciosa cuando todo funciona, específica cuando algo se desvía y suficientemente clara como para indicar qué decisión toca tomar.

Ese equilibrio permite mantener un NAS bajo control sin convertir su mantenimiento en otra carga permanente. Y esa es precisamente la medida de una infraestructura bien diseñada para una empresa pequeña: proteger la operativa sin exigir una infraestructura adicional desproporcionada para vigilarla.