SolarWinds: añadir un nodo, afinar una alerta que salta demasiado y leer qué pasó antes de la caída

Qué vas a conseguir

Que un servidor nuevo esté monitorizado el mismo día que entra en producción, que las alertas que llegan al equipo sean las que hay que atender (y no las 40 de cada noche que todos ignoran), y poder reconstruir en cinco minutos qué pasó en un servidor antes de que cayera.

Antes de empezar

• Acceso a la consola web de SolarWinds Platform (Orion) con un rol que pueda añadir nodos y editar alertas.
• En el servidor nuevo: SNMP v3 configurado (usuario, autenticación y cifrado; nunca v2c con public) o permiso para instalar el agente de SolarWinds. Para Windows, WMI con una cuenta de servicio de solo lectura también vale.
• El firewall entre el servidor de sondeo y el nodo: UDP 161 (SNMP) o TCP 17778 (agente).
• El runbook de a quién llama cada alerta (Confluence, Nivel 2).

1. Añadir el nodo

Las propiedades personalizadas son lo que luego usas para todo: a quién va la alerta (Owner_Team), si despierta a alguien (Environment), en qué informe sale (Service). Un nodo sin propiedades es un nodo que avisa a nadie. Deja fuera lo y los volúmenes temporales: cada recurso sondeado es ruido potencial.

Consejo: con el agente en lugar de SNMP (Settings → Agents → Download Agent), el nodo sigue reportando aunque cambie de IP o esté detrás de un NAT, y SAM puede leer logs y procesos. Para servidores en la nube o en sedes remotas, es la opción.

2. Umbrales por nodo

Un servidor de base de datos con el 90 % de memoria usada está bien: es la caché. Un servidor web al 90 % está a punto de caer. Los umbrales globales (Settings → Thresholds) sirven para el 80 % de los nodos; el 20 % restante (bases de datos, hipervisores, el volumen de copias que siempre está lleno) necesita el suyo. Esto solo ya quita la mitad de las alertas de la noche.

3. La alerta con condición sostenida

Tres decisiones hacen la diferencia entre una alerta y una molestia: ámbito por propiedades (no "todos los nodos"), condición sostenida cinco minutos (un reinicio planificado dura tres) y runbook en el mensaje. Para Test, la misma alerta en horario laboral y a un buzón, no al teléfono de guardia. Y la de "interfaz caída" solo para interfaces marcadas como Critical = Yes en sus propiedades: no para el ens192 que alguien desconectó en el laboratorio.

4. La alerta que salta demasiado

El informe de alertas por nombre de la última semana es la lista de tareas: 312 disparos de CPU que nadie reconoce es una alerta que hay que cambiar (umbral sostenido 15 minutos y solo Production), no un servidor que arreglar; 88 del mismo volumen es un umbral por nodo del paso 2 o, mejor, el ticket de limpiar /backup. La métrica que llevas a la reunión: alertas reconocidas / disparadas. Si está por debajo del 50 %, la plataforma avisa pero nadie escucha.

5. ¿Qué pasó a las 03:12? PerfStack

PerfStack pone en una sola línea de tiempo lo que estaba disperso: la memoria del proceso Java se dispara, llena el disco de logs y el nodo cae. Esa pantalla, con Share, es el enlace que va al post-mortem en lugar de cuatro capturas. Junto con los logs centralizados de la guía de ELK (la hora de las 02:58 en Kibana dice qué petición disparó el consumo), tienes la causa en diez minutos.

6. Lo que revisas cada mes

• Nodos en estado Unknown o Unmanaged desde hace más de una semana: Manage Nodes → filtro por estado. Unmanaged es para mantenimientos; con un mes, se olvidó.
• Nodos sin propiedades (Owner_Team vacío): la consulta SWQL SELECT Caption FROM Orion.Nodes WHERE CustomProperties.Owner_Team IS NULL.
• Alertas disparadas frente a reconocidas; las tres alertas más ruidosas y qué se hizo con ellas.
• Capacidad del propio servidor de sondeo (Settings → Polling Engines): porcentaje de elementos sondeados frente al límite de la licencia.

Siguientes pasos

• Dependencias (Settings → Manage Dependencies): si el switch de la sede cae, una alerta, no cuarenta de los servidores detrás.
• NetFlow (NTA) en el router de la sede para la pregunta "¿quién está saturando el enlace?", y NCM para guardar la configuración de los Cisco (Nivel 4) y avisar de cambios.
• Exporta las alertas a Teams con el runbook y, si el equipo tiene herramienta de guardia, por su webhook: el teléfono suena solo para Critical en Production.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.