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_Teamvacío): la consulta SWQLSELECT 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
CriticalenProduction.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
What you'll get
A new server is monitored the same day it goes into production, the alerts that reach the team are the ones that need attention (not the 40 a night that everyone ignores), and you can reconstruct in five minutes what happened on a server before it went down.
Before you start
- Access to the SolarWinds Platform (Orion) web console with a role that can add nodes and edit alerts.
- On the new server: SNMP v3 configured (user, authentication and encryption; never v2c with
public) or permission to install the SolarWinds agent. For Windows, WMI with a read-only service account also works. - The firewall between the polling engine and the node: UDP 161 (SNMP) or TCP 17778 (agent).
- The runbook of whom each alert calls (Confluence, Level 2).
1. Add the node
Custom properties are what you later use for everything: whom the alert goes to (Owner_Team), whether it wakes someone (Environment), which report it appears in (Service). A node without properties is a node that notifies nobody. Leave out lo and temporary volumes: every polled resource is potential noise.
Tip: with the agent instead of SNMP (Settings → Agents → Download Agent), the node keeps reporting even if it changes IP or sits behind NAT, and SAM can read logs and processes. For servers in the cloud or at remote sites, it is the option.
2. Per-node thresholds
A database server at 90% memory used is fine: that is the cache. A web server at 90% is about to fall over. Global thresholds (Settings → Thresholds) work for 80% of nodes; the remaining 20% (databases, hypervisors, the backup volume that is always full) need their own. This alone removes half of the night-time alerts.
3. The alert with a sustained condition
Three decisions make the difference between an alert and a nuisance: scope by properties (not "all nodes"), a sustained condition of five minutes (a planned reboot takes three) and the runbook in the message. For Test, the same alert in working hours to a mailbox, not the on-call phone. And the "interface down" alert only for interfaces marked Critical = Yes in their properties: not for the ens192 someone unplugged in the lab.
4. The alert that fires too much
The alerts by name report for the last week is the to-do list: 312 CPU triggers nobody acknowledges is an alert to change (sustained 15 minutes and Production only), not a server to fix; 88 from the same volume is a per-node threshold from step 2 or, better, the ticket to clean up /backup. The metric you take to the meeting: acknowledged / triggered alerts. Below 50%, the platform is warning but nobody is listening.
5. What happened at 03:12? PerfStack
PerfStack puts on one timeline what was scattered: the Java process memory spikes, fills the disk with logs and the node goes down. That screen, with Share, is the link that goes into the post-mortem instead of four screenshots. Together with the centralised logs from the ELK guide (the 02:58 timestamp in Kibana says which request triggered the consumption), you have the cause in ten minutes.
6. What you review each month
- Nodes in Unknown or Unmanaged state for more than a week:
Manage Nodes → filter by status. Unmanaged is for maintenance; after a month, it was forgotten. - Nodes without properties (
Owner_Teamempty): the SWQL querySELECT Caption FROM Orion.Nodes WHERE CustomProperties.Owner_Team IS NULL. - Alerts triggered versus acknowledged; the three noisiest alerts and what was done about them.
- Capacity of the polling engine itself (
Settings → Polling Engines): percentage of polled elements against the licence limit.
Next steps
- Dependencies (
Settings → Manage Dependencies): if the site switch goes down, one alert, not forty from the servers behind it. - NetFlow (NTA) on the site router for the question "who is saturating the link?", and NCM to store the Cisco configurations (Level 4) and warn about changes.
- Export alerts to Teams with the runbook and, if the team has an on-call tool, through its webhook: the phone rings only for
CriticalinProduction.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →