Monitorización y Gestión de Incidencias de los Sistemas Físicos I

Unidad Didáctica 1 · Introducción a la evaluación y a las métricas de rendimiento

01Conceptos Básicos de la Evaluación del Rendimiento

Un sistema de procesamiento de información recibe una carga de trabajo (peticiones, transacciones, trabajos por lotes), la procesa con sus recursos (CPU, memoria, discos, red) y entrega unos resultados. Evaluar su rendimiento es medir cómo de bien lo hace y compararlo con lo que se espera de él.

🎯

Prestaciones

Capacidades que ofrece un sistema según su diseño: lo que «puede» hacer (por ejemplo, un disco que admite 500 MB/s).

📈

Rendimiento

Lo que realmente consigue con una carga concreta y en unas condiciones concretas (ese disco da 180 MB/s con la carga actual).

⚖️

Eficiencia

Relación entre el rendimiento obtenido y los recursos consumidos para obtenerlo.

🧱

Capacidad

Carga máxima que el sistema puede soportar sin que su rendimiento baje de un nivel aceptable.

Para qué se evalúa el rendimiento

Comprobar que el sistema cumple los acuerdos de nivel de servicio (ANS o SLA).
Detectar cuellos de botella y degradaciones antes de que lo noten los usuarios.
Planificar la capacidad: cuándo habrá que ampliar o sustituir.
Comparar alternativas de compra o de configuración.
Comprobar el efecto de un cambio (antes y después de una actualización).

Línea basePara saber si algo va «lento» hace falta saber cómo va cuando va bien. La línea base (baseline) es el conjunto de medidas tomadas en funcionamiento normal, en distintas horas y días, con la que se comparan todas las mediciones posteriores.

02Recursos y Componentes Críticos de los Sistemas Informáticos

Un recurso es crítico cuando su saturación o su fallo afecta directamente al servicio. El rendimiento global de un sistema lo marca su recurso más lento: el cuello de botella.

Recurso	Indicadores de saturación	Efecto típico
CPU	Uso sostenido > 80-90 %, cola de procesos (load average) mayor que el número de núcleos	Respuesta lenta de todas las aplicaciones
Memoria	Poca memoria disponible, uso intensivo del fichero de paginación (swap)	El disco trabaja sin parar y el equipo se «arrastra»
Disco	Cola de disco alta, latencias > 20 ms en HDD o > 1-2 ms en SSD, uso al 100 %	Aplicaciones y bases de datos bloqueadas esperando E/S
Red	Uso del enlace > 70 %, errores, descartes, retransmisiones	Lentitud en accesos remotos y cortes
Alimentación y refrigeración	Fuente sin redundancia, temperaturas altas, ventiladores al máximo	Apagados, reducción de frecuencia (throttling)

Además de estos recursos, en un servidor son críticos la controladora de disco, las fuentes, los ventiladores, las tarjetas de red y, fuera del equipo, el switch, el SAI y la climatización de la sala.

03Técnicas de Evaluación del Rendimiento

Técnica	En qué consiste	Cuándo se usa	Limitaciones
Medición (monitorización)	Medir el sistema real con herramientas que recogen índices	Sistemas ya en producción	Solo mide lo que existe; la propia medición consume recursos
Simulación	Reproducir el sistema con un programa y someterlo a una carga de trabajo sintética	Antes de comprar o desplegar	Tan fiable como lo sea el modelo y la carga simulada
Modelado analítico	Representar el sistema con fórmulas matemáticas (teoría de colas, ley de Little)	Estimaciones rápidas y planificación de capacidad	Simplifica mucho la realidad
Sistemas de referencia (benchmarks)	Ejecutar programas estándar y comparar el resultado con el de otros sistemas	Comparar equipos o configuraciones	La carga del benchmark puede no parecerse a la real

Índices de rendimiento

Productividad o rendimiento (throughput): trabajo realizado por unidad de tiempo (transacciones por segundo, MB/s, páginas por minuto).
Tiempo de respuesta: tiempo desde que se hace una petición hasta que llega la respuesta.
Utilización: porcentaje del tiempo en que un recurso está ocupado.
Disponibilidad: porcentaje del tiempo en que el servicio está operativo.
Fiabilidad: probabilidad de que funcione sin fallar durante un periodo (MTBF, tiempo medio entre fallos).
Mantenibilidad: rapidez con que se recupera tras un fallo (MTTR, tiempo medio de reparación).

La carga de trabajo

Para simular o hacer un benchmark hay que definir una carga representativa: qué operaciones, en qué proporción, con qué tamaño de datos y con cuántos usuarios simultáneos. Ejemplos de benchmarks reconocidos: SPEC CPU (procesador), TPC-C y TPC-E (bases de datos), fio e IOmeter (disco), iperf3 (red), Geekbench, PassMark o Cinebench (equipos de escritorio).

# Ejemplos de medición sintética
fio --name=prueba --rw=randread --bs=4k --size=1G --numjobs=4 --runtime=30 --group_reporting
iperf3 -s                       # en el servidor
iperf3 -c IP_SERVIDOR -t 30     # en el cliente: ancho de banda real
sysbench cpu --threads=4 run

Ley de LittleEl número medio de peticiones en un sistema (N) es igual a la tasa de llegada (λ) por el tiempo medio que pasa cada una dentro (R): N = λ · R. Si llegan 50 peticiones por segundo y cada una tarda 0,2 s, habrá de media 10 peticiones dentro del sistema.

04Leyes Operacionales: Utilización, Colas y Tiempo de Respuesta

Para razonar sobre el rendimiento no hacen falta matemáticas complejas. Unas pocas leyes, llamadas leyes operacionales porque se basan en magnitudes que se pueden medir directamente, permiten explicar por qué un sistema que va bien al 60 % se hunde al 95 %.

Magnitud	Símbolo	Cómo se mide
Tiempo de observación	T	Duración de la medida (por ejemplo, 60 s)
Peticiones completadas	C	Contador de operaciones terminadas en T
Tiempo ocupado del recurso	B	Tiempo en que el recurso ha estado trabajando
Productividad (throughput)	X = C / T	Peticiones por segundo
Tiempo de servicio	S = B / C	Tiempo que dedica el recurso a cada petición
Utilización	U = B / T = X · S	Fracción del tiempo ocupado (0 a 1)

Ley de la utilización

U = X · S. Si un disco atiende 120 operaciones por segundo y cada una le ocupa 5 ms (0,005 s), su utilización es 120 × 0,005 = 0,6, es decir, un 60 %. Si la carga sube a 190 operaciones por segundo, la utilización llega al 95 %: el disco casi no descansa.

Por qué el tiempo de respuesta se dispara cerca del 100 %

En un recurso con cola, el tiempo de respuesta aproximado es R = S / (1 − U). No crece de forma lineal: se dispara cuando la utilización se acerca a 1, porque cada petición tiene que esperar a que terminen las que tiene delante.

Utilización U	R = S / (1 − U) con S = 5 ms	Multiplicador respecto a S
10 %	5,6 ms	× 1,1
50 %	10 ms	× 2
70 %	16,7 ms	× 3,3
80 %	25 ms	× 5
90 %	50 ms	× 10
95 %	100 ms	× 20
99 %	500 ms	× 100

Consecuencia prácticaPor eso los umbrales de aviso se ponen en el 70-80 % y no en el 99 %: a partir de ahí, un pequeño aumento de carga multiplica la espera. Es también la razón de que un servidor «vaya bien» toda la mañana y se colapse en el cierre de mes, aunque la carga solo haya subido un 20 %.

Cuello de botella y ley del flujo forzado

Si cada transacción visita varias veces un recurso (por ejemplo, 4 accesos a disco por cada consulta), la productividad del recurso es Xk = Vk · X, siendo Vk el número de visitas. El recurso con mayor demanda Dk = Vk · Sk es el cuello de botella y fija el máximo del sistema: Xmáx = 1 / Dmáx. Mejorar cualquier otro recurso no sirve de nada hasta que se alivie ese.

Recurso	Visitas por transacción (V)	Tiempo de servicio (S)	Demanda D = V · S
CPU	1	8 ms	8 ms
Disco de datos	4	4 ms	16 ms ← cuello de botella
Red	2	1 ms	2 ms

En el ejemplo, el sistema no puede pasar de 1 / 0,016 = 62,5 transacciones por segundo, por mucha CPU que se añada. La solución está en el disco: un SSD, más caché en memoria o menos accesos por transacción (índices).

05Métricas de Rendimiento de Red, de Sistema y de Servicios

Ámbito	Métrica	Unidad	Qué indica
Red	Ancho de banda y uso del enlace	Mb/s, % de uso	Capacidad disponible y consumida
Red	Latencia (RTT)	ms	Tiempo de ida y vuelta de un paquete
Red	Variación de la latencia (jitter)	ms	Estabilidad; crítico en voz y vídeo
Red	Pérdida de paquetes	%	Congestión o errores físicos
Red	Errores y descartes en interfaz	Contadores	Cables, dúplex mal negociado, saturación
Sistema	Uso de CPU y carga media	%, load average	Ocupación del procesador
Sistema	Memoria disponible y paginación	MB, páginas/s	Presión sobre la memoria
Sistema	Latencia, IOPS y cola de disco	ms, op/s, n.º	Rendimiento del almacenamiento
Sistema	Espacio libre en sistemas de archivos	%, GB	Riesgo de llenado
Sistema	Temperatura y velocidad de ventiladores	°C, rpm	Salud física
Servicios	Disponibilidad	%	Tiempo en servicio respecto al total
Servicios	Tiempo de respuesta de la aplicación	ms	Experiencia del usuario
Servicios	Peticiones por segundo y tasa de errores	req/s, %	Carga y calidad del servicio

Disponibilidad: los «nueves»

Disponibilidad	Parada máxima al año	Parada máxima al mes
99 %	3,65 días	7,3 horas
99,9 %	8,76 horas	43,8 minutos
99,99 %	52,6 minutos	4,4 minutos
99,999 %	5,26 minutos	26 segundos

La disponibilidad se calcula como MTBF / (MTBF + MTTR). Se puede mejorar reduciendo la frecuencia de fallos (componentes fiables y redundantes) o reduciendo el tiempo de reparación (repuestos a mano, monitorización que avisa enseguida, procedimientos claros).

06Caso Práctico Resuelto: Línea Base de un Servidor de Ficheros

La gestoría Martínez y Asociados tiene un servidor de ficheros con Windows Server, 8 núcleos, 32 GB de RAM y un RAID 5 de cuatro discos de 7.200 rpm. Los usuarios se quejan de lentitud «a primera hora». Se registran contadores cada 30 segundos durante dos semanas.

Contador	Media 10:00-13:00	p95 de 8:30 a 9:30	Umbral orientativo
% de CPU	18 %	41 %	> 85 %
Memoria disponible	14 GB	11 GB	< 3 GB
Latencia de disco (Avg. Disk sec/Transfer)	9 ms	68 ms	> 20 ms
Cola de disco	0,8	14	> 2 por eje
Uso de la red (1 Gb/s)	12 %	35 %	> 70 %

Análisis: CPU, memoria y red están holgadas incluso en el pico. El disco, en cambio, pasa de 9 ms a 68 ms de latencia y la cola de disco llega a 14.
Correlación: el pico coincide con la sincronización de 40 perfiles de usuario y con el análisis completo programado del antivirus a las 8:30.
Hipótesis: el RAID 5 de discos mecánicos no soporta la escritura aleatoria concentrada a esa hora (en RAID 5 cada escritura pequeña cuesta cuatro operaciones físicas).
Acciones propuestas: mover el análisis del antivirus a las 2:00, excluir las carpetas de perfiles del análisis en tiempo real según la guía del fabricante y planificar el paso a SSD o a RAID 10 en el próximo presupuesto.
Verificación: tras mover el antivirus, el p95 de latencia baja a 24 ms y las quejas desaparecen. Se actualiza la línea base.

LecciónLas medias del día escondían el problema. Solo el percentil 95 de la franja conflictiva y la correlación con otros sucesos lo hicieron visible.

Unidad Didáctica 2 · Técnicas de monitorización y medida de los dispositivos físicos

07Representación y Análisis de los Resultados de las Mediciones

Una medición sin análisis no sirve de nada. El operador debe saber resumir y representar los datos para ver tendencias y anomalías.

Estadísticos básicos

Media: valor promedio. Engaña si hay picos: una media de CPU del 40 % puede esconder picos del 100 %.
Mediana y percentiles (p95, p99): el p95 del tiempo de respuesta es el valor por debajo del cual quedan el 95 % de las peticiones. Es la métrica habitual en los SLA.
Máximo y mínimo: detectan picos y caídas.
Desviación típica: indica cuánto varían los valores; una desviación alta indica inestabilidad.

Representaciones gráficas

Gráfico	Para qué sirve
Serie temporal (línea)	Evolución de una métrica en el tiempo; detectar picos, tendencias y patrones diarios o semanales
Área apilada	Reparto de un recurso entre consumidores (CPU por proceso, tráfico por protocolo)
Histograma	Distribución de valores (cuántas peticiones tardaron 0-10 ms, 10-20 ms…)
Mapa de calor	Muchos equipos y horas a la vez (latencia de cada servidor por hora)
Indicador (gauge) o semáforo	Estado actual frente a umbrales: verde, ámbar, rojo
Top N	Los equipos o procesos que más consumen

Pasos del análisis

1. Comparar con la línea base: ¿el valor está fuera de lo normal para este día y hora?
2. Correlacionar: ¿coincide con otra métrica (disco al 100 % a la vez que sube el tiempo de respuesta)?
3. Buscar la tendencia: ¿es un pico aislado o un crecimiento sostenido?
4. Proyectar: con la tendencia de llenado de un disco, ¿cuándo llegará al 90 %?
5. Concluir y actuar: proponer un ajuste, una ampliación o una incidencia.

08Rendimiento y Parámetros de Configuración de los Dispositivos Físicos

Dispositivo	Parámetros que influyen en el rendimiento
CPU	Plan de energía (rendimiento o ahorro), estados C y P, turbo, hiperhilo (SMT), afinidad NUMA, temperatura
Memoria	Capacidad, canales ocupados de forma equilibrada, velocidad, perfil XMP/EXPO, ECC
Disco HDD	Velocidad de giro, caché, modo AHCI, alineación de particiones, fragmentación
SSD	Interfaz (SATA o NVMe y generación PCIe), TRIM activo, espacio libre (sobreaprovisionamiento), firmware
Controladora RAID	Nivel de RAID, tamaño de franja (stripe), caché de escritura (write-back con batería o write-through), lectura anticipada
Tarjeta de red	Velocidad y dúplex negociados, MTU (jumbo frames), descargas (offload), agregación de enlaces
Impresoras	Memoria de la controladora, lenguaje (PCL/PostScript), resolución, modo borrador

# Linux: medidas rápidas de dispositivos
mpstat -P ALL 2 5          # CPU por núcleo (paquete sysstat)
vmstat 2 5                 # memoria, paginación, cola de procesos
iostat -x 2 5              # discos: %util, await, r/s, w/s
sar -n DEV 2 5             # red por interfaz
sensors                    # temperaturas (paquete lm-sensors)
ethtool eth0               # velocidad y dúplex negociados

REM Windows
Get-Counter '\Processor(_Total)\% Processor Time','\Memory\Available MBytes','\PhysicalDisk(_Total)\Avg. Disk sec/Transfer' -SampleInterval 2 -MaxSamples 5

CuidadoCambiar un parámetro sin medir antes y después es adivinar. Cambia un solo parámetro cada vez, mide, documenta el resultado y deshaz el cambio si no mejora.

Unidad Didáctica 3 · Herramientas de monitorización

09Instalación de una Plataforma de Monitorización: Requisitos

Una plataforma de monitorización vigila de forma continua y automática los equipos y servicios, guarda el histórico de métricas y avisa cuando algo se sale de lo normal. Ejemplos libres muy usados: Zabbix, Nagios Core e Icinga, Prometheus con Grafana, Checkmk, LibreNMS y Centreon. Comerciales: PRTG, SolarWinds, Datadog, Microsoft System Center Operations Manager.

Requisitos técnicos

Requisito	Consideraciones
Servidor	Físico o virtual; CPU y RAM según el número de elementos y la frecuencia de muestreo (por ejemplo, 2 vCPU y 4 GB para unos cientos de equipos en Zabbix)
Base de datos	MySQL o MariaDB, PostgreSQL o TimescaleDB; necesita disco rápido porque escribe continuamente
Almacenamiento	Calcular el histórico: n.º de métricas × frecuencia × días de retención
Red	Acceso a los equipos vigilados por los puertos necesarios (ICMP, SNMP UDP 161, traps UDP 162, agente TCP 10050/10051 en Zabbix)
Seguridad	Cuentas de solo lectura, SNMPv3 o comunidades no por defecto, cifrado agente-servidor, acceso a la consola con HTTPS
Alta disponibilidad	La monitorización no puede caer a la vez que lo que vigila: idealmente en otra máquina, otra sala o con un vigilante externo
Notificaciones	Servidor de correo, mensajería (Telegram, Teams, Slack) o SMS

Procedimiento general de instalación

1. Planificar: qué se va a vigilar, con qué frecuencia, quién recibe cada alerta.
2. Instalar el servidor y la base de datos: por paquetes oficiales o contenedores (Docker).
3. Configurar la interfaz web y los usuarios.
4. Desplegar agentes: en los equipos que lo admitan, y configurar SNMP en los demás.
5. Dar de alta los equipos (hosts) y aplicarles plantillas: conjuntos de métricas, umbrales y gráficos predefinidos por tipo de equipo.
6. Definir umbrales, notificaciones y escalados.
7. Validar: provocar fallos controlados y comprobar que llega el aviso.

10Protocolos de Gestión de Red: ICMP y SNMP

ICMP

ICMP (Internet Control Message Protocol) es el protocolo de mensajes de control de IP. La monitorización lo usa para la comprobación más básica: si un equipo responde (ping, mensajes echo request y echo reply) y con qué latencia y pérdida. También aporta mensajes de error como «destino inalcanzable» o «tiempo excedido» (que usa traceroute).

LimitaciónQue un equipo responda al ping solo dice que su pila de red funciona. El servidor puede tener el servicio web caído o el disco lleno y seguir respondiendo al ping.

SNMP

SNMP (Simple Network Management Protocol) permite consultar y modificar variables de gestión de equipos de red, servidores, impresoras y SAI. Funciona con un gestor (la plataforma de monitorización) y agentes (en cada equipo).

Operación	Dirección	Uso
GET / GETNEXT / GETBULK	Gestor → agente (UDP 161)	Leer una o varias variables
SET	Gestor → agente	Modificar una variable (poco usado por seguridad)
TRAP / INFORM	Agente → gestor (UDP 162)	El equipo avisa por su cuenta de un evento (enlace caído, fallo de fuente)

Versión	Seguridad	Recomendación
SNMPv1	Comunidad en texto claro	No usar
SNMPv2c	Comunidad en texto claro; añade GETBULK e INFORM	Solo en redes de gestión aisladas, con comunidad distinta de «public» y solo lectura
SNMPv3	Usuarios con autenticación (SHA) y cifrado (AES)	Es la versión recomendada

# Consultas SNMP desde Linux (paquete snmp)
snmpget  -v2c -c COMUNIDAD 192.168.1.10 1.3.6.1.2.1.1.3.0     # sysUpTime
snmpwalk -v2c -c COMUNIDAD 192.168.1.10 1.3.6.1.2.1.2.2.1.2   # ifDescr: interfaces
snmpwalk -v3 -l authPriv -u monitor -a SHA -A 'claveAuth' -x AES -X 'clavePriv' 192.168.1.10 system

11SNMP en Detalle: PDU, Traps, SNMPv3 y Buenas Prácticas

Estructura de un mensaje SNMP

Campo	Contenido
Versión	0 = v1, 1 = v2c, 3 = v3
Comunidad (v1/v2c) o cabecera de seguridad (v3)	La «contraseña» en texto claro, o el usuario, nivel de seguridad y parámetros de autenticación y cifrado
Tipo de PDU	GetRequest, GetNextRequest, GetBulkRequest, SetRequest, Response, SNMPv2-Trap, InformRequest
Request ID	Identificador para emparejar petición y respuesta
Estado y error	Código de error (noSuchName, tooBig, authorizationError…)
Variable bindings	Lista de pares OID = valor

Tipos de datos SNMP

Tipo	Uso	Ejemplo
INTEGER	Estados y valores enteros	ifOperStatus: 1 = up, 2 = down
Counter32 / Counter64	Contadores que solo crecen y dan la vuelta al llegar al máximo	ifInOctets, ifHCInOctets
Gauge32	Valor que sube y baja	Temperatura, nivel de tóner
TimeTicks	Centésimas de segundo	sysUpTime
OCTET STRING	Texto o bytes	sysDescr, sysLocation

ContadoresUn contador no es una medida en sí: la plataforma debe calcular la diferencia entre dos lecturas y dividir por el tiempo para obtener una velocidad (bytes por segundo). En enlaces de 1 Gb/s o más hay que usar los contadores de 64 bits (ifHCInOctets), porque los de 32 bits dan la vuelta en pocos segundos.

Traps frente a informs

Trap: el agente envía el aviso y se olvida; si el paquete UDP se pierde, el gestor nunca se entera.
Inform (v2c y v3): el gestor confirma la recepción y, si no lo hace, el agente reintenta.
Los traps se reciben en UDP 162 con snmptrapd u otro receptor de la plataforma, que los traduce con las MIB.

SNMPv3: USM y VACM

Componente	Función	Opciones
USM (User-based Security Model)	Autenticación y cifrado por usuario	noAuthNoPriv · authNoPriv · authPriv (recomendado: SHA-256/512 + AES-128/256)
VACM (View-based Access Control Model)	Qué parte del árbol de la MIB puede ver o modificar cada usuario o grupo	Vistas de solo lectura limitadas a lo necesario
Engine ID	Identificador único de cada agente	Se usa en la derivación de claves

# Recibir traps en Linux para pruebas
sudo apt install -y snmptrapd
echo 'authCommunity log,execute,net COMUNIDAD_LAB' | sudo tee -a /etc/snmp/snmptrapd.conf
sudo snmptrapd -f -Lo           # muestra los traps en pantalla

# Enviar un trap de prueba desde otra máquina
snmptrap -v2c -c COMUNIDAD_LAB IP_GESTOR '' 1.3.6.1.6.3.1.1.5.3 ifIndex i 2

Buenas prácticas

Usar SNMPv3 authPriv siempre que el equipo lo admita.
Si hay que usar v2c: comunidad larga y distinta de «public»/«private», solo lectura y listas de acceso con la IP del gestor.
Desactivar SET salvo necesidad justificada.
Red de gestión separada de la de usuarios.
Cambiar las comunidades y claves cuando sale alguien del equipo técnico.

12Repositorios de Información: MIB y CMDB

MIB (Base de Información de Gestión)

La MIB (Management Information Base) define qué variables ofrece un agente SNMP y cómo se llaman. Está organizada en un árbol jerárquico en el que cada variable tiene un identificador de objeto u OID (Object Identifier), una secuencia de números separados por puntos.

OID	Nombre	Contenido
1.3.6.1.2.1.1	system (MIB-II)	Descripción, tiempo encendido, contacto, nombre y ubicación del equipo
1.3.6.1.2.1.2	interfaces	Interfaces de red, estado, octetos y errores
1.3.6.1.2.1.25	host (HOST-RESOURCES-MIB)	CPU, memoria, almacenamiento y procesos de un servidor
1.3.6.1.2.1.43	printmib (Printer MIB)	Estado de impresoras y niveles de consumibles
1.3.6.1.2.1.33	upsMIB	Estado del SAI, batería y carga
1.3.6.1.4.1.x	enterprises	MIB privadas de cada fabricante (Cisco, Dell, HP…)

Para que la plataforma muestre nombres legibles en lugar de números, se cargan los ficheros MIB del fabricante (texto en lenguaje SMI).

CMDB (Base de Datos de Gestión de la Configuración)

La CMDB, que vimos en el inventario (UF1349), aporta a la monitorización el contexto: qué es cada equipo, quién es su responsable, qué servicio presta y de qué depende. Con ella, una alerta deja de ser «no responde 10.0.3.14» y pasa a ser «cae el switch de la planta 2: afecta a 40 usuarios de Contabilidad y al servicio de nóminas».

	MIB	CMDB
Qué guarda	Variables técnicas en tiempo real de un equipo	Elementos de configuración, atributos y relaciones
Dónde está	En el agente de cada equipo	En una base de datos central
Quién la usa	La plataforma de monitorización (vía SNMP)	Gestión de servicios: incidencias, cambios, problemas

13Elementos a Monitorizar, Eventos, Servicios y Perfiles

Tipos de instancias (elementos monitorizables)

🖥️

Equipos (hosts)

Servidores, PC, máquinas virtuales e hipervisores.

🔌

Electrónica de red

Switches, routers, cortafuegos, puntos de acceso.

🔋

Infraestructura

SAI, PDU, climatización, sensores de temperatura, humedad e inundación.

🖨️

Periféricos

Impresoras, librerías de cintas, cabinas de almacenamiento.

⚙️

Componentes

Discos, interfaces, procesos, sistemas de archivos, sensores del BMC.

🌐

Servicios

Web, correo, DNS, bases de datos, comprobados desde fuera como lo haría un usuario.

Tipos de eventos

Tipo	Descripción	Ejemplo
Informativo	Funcionamiento normal que conviene registrar	Copia de seguridad terminada
Aviso (warning)	Algo se acerca a un límite	Disco al 85 %
Crítico (error)	El servicio está afectado o lo estará enseguida	Disco al 98 %, fuente averiada
Recuperación (OK)	Vuelve a la normalidad	El servidor vuelve a responder
Excepción o desconocido	No se puede obtener el dato	El agente no responde

Los servicios y la supervisión

Además de vigilar componentes sueltos, la plataforma puede modelar servicios de negocio como agregación de componentes (el servicio «Facturación» depende de dos servidores web, una base de datos y el switch del núcleo). Así se calcula la disponibilidad del servicio y se distingue si la caída de un componente lo afecta o no gracias a la redundancia.

Perfiles de usuario y responsabilidades

Perfil	Responsabilidades
Operador	Vigila la consola, reconoce (acknowledge) las alertas, aplica procedimientos de primer nivel y escala
Técnico o especialista	Resuelve las incidencias escaladas de su área (sistemas, red, almacenamiento)
Administrador de la plataforma	Da de alta equipos, plantillas, umbrales, usuarios y notificaciones
Responsable o usuario de consulta	Ve paneles e informes de disponibilidad sin modificar nada

14Arquitectura y Componentes de una Plataforma de Monitorización

🧠

Servidor central

Recoge los datos, evalúa los umbrales (triggers), genera eventos y lanza las acciones.

🗄️

Repositorio de componentes

Base de datos con la configuración, el histórico de métricas y los eventos, más las plantillas reutilizables.

🛰️

Agentes de monitorización

Programas ligeros en los equipos que miden recursos locales; pueden ser pasivos (el servidor les pregunta) o activos (envían los datos).

🔀

Proxies

Recogen datos en sedes remotas o redes aisladas y los envían agrupados al servidor central; reducen tráfico y puertos abiertos.

🖥️

Consola de gestión (frontend)

Interfaz web para consultar, configurar y operar.

📣

Sistema de notificaciones

Envía avisos por correo, mensajería, SMS o webhooks, y abre tiques en la herramienta de incidencias.

Monitorización con agente y sin agente

	Con agente	Sin agente
Cómo obtiene los datos	Programa instalado en el equipo	SNMP, ICMP, WMI, SSH, IPMI o APIs
Detalle	Muy alto (procesos, logs, servicios)	Depende de lo que exponga el protocolo
Despliegue	Hay que instalarlo y actualizarlo	Solo configurar el acceso
Uso típico	Servidores y PC	Switches, impresoras, SAI, equipos cerrados

Gestión remota y proxies

En organizaciones con varias sedes, un proxy en cada sede recoge localmente y reenvía al central. Si se corta el enlace, el proxy guarda los datos y los entrega al recuperarse. Las consolas remotas (iDRAC, iLO, KVM sobre IP) completan la gestión: permiten actuar en el equipo aunque el sistema operativo no responda.

15Comparativa de Plataformas de Monitorización

Plataforma	Modelo de recogida	Almacenamiento	Puntos fuertes	A tener en cuenta
Zabbix	Agente activo o pasivo, SNMP, IPMI, HTTP, scripts	Base de datos relacional (MySQL, PostgreSQL, TimescaleDB)	Todo en uno: plantillas, descubrimiento, mapas, SLA, notificaciones	Base de datos exigente con muchas métricas
Nagios Core / Icinga 2	Comprobaciones con plugins (devuelven OK, WARNING, CRITICAL, UNKNOWN)	Estado actual; histórico con complementos	Enorme catálogo de plugins; muy flexible	Configuración por ficheros; gráficos con añadidos
Prometheus + Grafana	Pull: el servidor recoge cada X segundos de exportadores HTTP (node_exporter, snmp_exporter)	Base de series temporales propia	Ideal para contenedores y nubes; lenguaje PromQL; Grafana para paneles	No está pensado para inventario ni para guardar datos años
Checkmk	Agente con descubrimiento automático de servicios	Ficheros RRD	Despliegue rápido, buenas reglas por defecto	Edición libre con funciones limitadas
LibreNMS	SNMP con autodescubrimiento	MySQL + RRD	Electrónica de red y mapas	Menos orientado a servidores

Pull frente a push

	Pull (el servidor pregunta)	Push (el agente envía)
Ejemplos	Prometheus, agente pasivo de Zabbix, SNMP GET	Agente activo de Zabbix, traps, syslog
Ventaja	El servidor controla la frecuencia y detecta enseguida un objetivo que no responde	Funciona tras NAT o cortafuegos; menos conexiones entrantes en los equipos
Inconveniente	Hay que abrir puertos hacia los equipos	Hay que detectar el silencio (ausencia de datos) como una alarma

# Prometheus: regla de alerta de disco (fichero rules.yml)
groups:
- name: discos
  rules:
  - alert: DiscoCasiLleno
    expr: node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes < 0.10
    for: 10m
    labels: {severity: critical}
    annotations: {summary: "Menos del 10 % libre en {{ $labels.instance }} {{ $labels.mountpoint }}"}

16La Consola de Monitorización, Gestión de Eventos y Notificaciones

Descripción de la consola

Panel (dashboard) general con el estado de todos los equipos y servicios por colores.
Lista de problemas activos ordenados por gravedad y antigüedad.
Mapas de red con el estado de cada nodo y enlace.
Gráficos históricos de cada métrica.
Inventario de los equipos vigilados y de sus plantillas.
Informes de disponibilidad (SLA) y de tendencia.

Gestión de eventos: tipos de acciones

Acción	Descripción
Reconocer (acknowledge)	El operador indica que ha visto la alerta y se ocupa de ella; evita que otros dupliquen el trabajo
Comentar	Anotar lo que se ha comprobado o hecho
Escalar	Pasar la alerta al siguiente nivel si no se resuelve en un tiempo
Acción automática	Ejecutar un script: reiniciar un servicio, borrar temporales, abrir un tique
Suprimir o mantenimiento	Silenciar las alertas de un equipo durante una intervención planificada
Cerrar	Al recuperarse la métrica, o manualmente con la causa documentada

Otros tipos de gestión desde la plataforma

Gestión de la configuración: detectar cambios en el hardware o el software de los equipos.
Gestión de capacidad: previsiones de llenado y de crecimiento.
Gestión de inventario: descubrimiento automático de equipos nuevos en la red.
Integración con la gestión de incidencias (GLPI, osTicket, Jira Service Management).

Sistema de notificaciones

Destinatarios: por grupo y por tipo de equipo (los avisos de red, al equipo de red).
Medios: correo, mensajería, SMS, llamada; para lo crítico fuera de horario, el de la guardia.
Horarios: laborables o 24 × 7 según la criticidad.
Escalado: si nadie reconoce la alerta en 15 minutos, avisar al responsable.
Contenido: equipo, servicio afectado, métrica, valor, umbral, hora y enlace a la consola.

Fatiga de alertasSi la plataforma envía cientos de avisos irrelevantes, el operador deja de leerlos y se le escapa el importante. Ajusta umbrales, agrupa alertas dependientes (si cae el switch, no avises de los 40 equipos que cuelgan de él) y revisa cada mes qué avisos no han servido para nada.

17Glosario de la Parte I

Línea base: Conjunto de medidas del funcionamiento normal que sirve de referencia para detectar anomalías.
Productividad (throughput): Trabajo completado por unidad de tiempo.
Tiempo de respuesta: Tiempo desde la petición hasta la respuesta, incluida la espera en colas.
Utilización: Fracción del tiempo en que un recurso está ocupado.
Cuello de botella: Recurso con mayor demanda, que limita el rendimiento máximo del sistema.
Percentil 95 (p95): Valor por debajo del cual queda el 95 % de las medidas.
MTBF / MTTR: Tiempo medio entre fallos / tiempo medio de reparación.
Benchmark: Prueba estándar de rendimiento para comparar sistemas.
ICMP: Protocolo de control de IP; base de ping y traceroute.
SNMP: Protocolo de gestión de red para consultar y modificar variables de los equipos.
MIB / OID: Base de información de gestión / identificador numérico de cada variable.
Trap / Inform: Aviso enviado por el agente sin confirmación / con confirmación del gestor.
CMDB: Base de datos de gestión de la configuración con los elementos y sus relaciones.
Agente: Programa en el equipo vigilado que mide y envía datos.
Proxy de monitorización: Intermediario que recoge datos en una sede o red remota.
Fatiga de alertas: Pérdida de atención por exceso de avisos irrelevantes.

18Autoevaluación de la Parte I

Intenta responder antes de desplegar la solución.

¿Qué diferencia hay entre prestaciones y rendimiento?

Las prestaciones son lo que el sistema puede hacer según su diseño o su ficha; el rendimiento es lo que realmente consigue con una carga y unas condiciones concretas.

Un disco atiende 150 operaciones/s con un tiempo de servicio de 6 ms. ¿Cuál es su utilización?

U = X · S = 150 × 0,006 = 0,9, es decir, un 90 %. El tiempo de respuesta será unas 10 veces el tiempo de servicio.

¿Por qué no basta con mirar la media de la CPU de un día?

Porque la media esconde los picos. Un 30 % de media puede incluir media hora al 100 %, justo cuando los usuarios se quejan. Hay que mirar máximos, percentiles y la franja del problema.

Calcula la disponibilidad de un servicio con un MTBF de 2.000 h y un MTTR de 4 h.

2.000 / (2.000 + 4) = 0,998, es decir, un 99,8 %.

¿Por qué SNMPv2c no es seguro?

Porque la comunidad viaja en texto claro y cualquiera que capture el tráfico puede leerla y usarla. SNMPv3 añade autenticación y cifrado por usuario.

¿Qué contador SNMP usarías para medir el tráfico de un enlace de 10 Gb/s y por qué?

ifHCInOctets / ifHCOutOctets (64 bits). Los contadores de 32 bits dan la vuelta en pocos segundos a esa velocidad y producirían medidas falsas.

¿Qué aporta la CMDB a una alerta?

El contexto: qué es el equipo, de qué depende, qué servicios y usuarios se ven afectados y quién es su responsable. Así se puede priorizar y avisar a quien corresponde.

¿Qué técnica usarías para decidir qué servidor comprar antes de tenerlo?

Simulación o benchmarks con una carga representativa, y modelado analítico para una estimación rápida. La medición solo es posible con el sistema ya funcionando.

¿Qué riesgo tiene una monitorización instalada en el mismo servidor que vigila?

Si ese servidor cae, la monitorización cae con él y nadie recibe el aviso. Debe estar en otra máquina o tener un vigilante externo.

Monitorización y Gestión de Incidencias de los Sistemas Físicos I

📋 Índice de contenidos

01Conceptos Básicos de la Evaluación del Rendimiento

Prestaciones

Rendimiento

Eficiencia

Capacidad

Para qué se evalúa el rendimiento

02Recursos y Componentes Críticos de los Sistemas Informáticos

03Técnicas de Evaluación del Rendimiento

Índices de rendimiento

La carga de trabajo

04Leyes Operacionales: Utilización, Colas y Tiempo de Respuesta

Ley de la utilización

Por qué el tiempo de respuesta se dispara cerca del 100 %

Cuello de botella y ley del flujo forzado

05Métricas de Rendimiento de Red, de Sistema y de Servicios

Disponibilidad: los «nueves»

06Caso Práctico Resuelto: Línea Base de un Servidor de Ficheros

07Representación y Análisis de los Resultados de las Mediciones

Estadísticos básicos

Representaciones gráficas

Pasos del análisis

08Rendimiento y Parámetros de Configuración de los Dispositivos Físicos

09Instalación de una Plataforma de Monitorización: Requisitos

Requisitos técnicos

Procedimiento general de instalación

10Protocolos de Gestión de Red: ICMP y SNMP

ICMP

SNMP

11SNMP en Detalle: PDU, Traps, SNMPv3 y Buenas Prácticas

Estructura de un mensaje SNMP

Tipos de datos SNMP

Traps frente a informs

SNMPv3: USM y VACM

Buenas prácticas

12Repositorios de Información: MIB y CMDB

MIB (Base de Información de Gestión)

CMDB (Base de Datos de Gestión de la Configuración)

13Elementos a Monitorizar, Eventos, Servicios y Perfiles

Tipos de instancias (elementos monitorizables)

Equipos (hosts)

Electrónica de red

Infraestructura

Periféricos

Componentes

Servicios

Tipos de eventos

Los servicios y la supervisión

Perfiles de usuario y responsabilidades

14Arquitectura y Componentes de una Plataforma de Monitorización

Servidor central

Repositorio de componentes

Agentes de monitorización

Proxies

Consola de gestión (frontend)

Sistema de notificaciones

Monitorización con agente y sin agente

Gestión remota y proxies

15Comparativa de Plataformas de Monitorización

Pull frente a push

16La Consola de Monitorización, Gestión de Eventos y Notificaciones

Descripción de la consola

Gestión de eventos: tipos de acciones

Otros tipos de gestión desde la plataforma

Sistema de notificaciones

17Glosario de la Parte I

18Autoevaluación de la Parte I