Unidad Didáctica 2 · La plataforma de gestión de operaciones
01Qué es una Plataforma de Gestión de Operaciones
Una plataforma de gestión de operaciones supervisa de forma centralizada el estado del software (sistemas operativos, servicios, aplicaciones y bases de datos) de muchos servidores, detecta problemas, genera alertas y permite actuar sobre ellos desde una consola única. Es la evolución de la monitorización de hardware de la UF1350 hacia la salud de los servicios.
| Producto | Tipo | Terminología propia |
|---|---|---|
| Microsoft System Center Operations Manager (SCOM) | Comercial, local | Management packs, monitores, reglas, alertas, tareas, consola de operaciones |
| Azure Monitor / Log Analytics | Comercial, en la nube | Reglas de alerta, workbooks, grupos de acciones |
| Zabbix | Libre | Plantillas, elementos (items), desencadenadores (triggers), acciones, scripts |
| Checkmk | Libre / comercial | Servicios, reglas, paquetes de extensiones |
| Nagios / Icinga | Libre | Comprobaciones (checks), servicios, plugins, manejadores de eventos |
| Prometheus + Alertmanager + Grafana | Libre | Exportadores, reglas de alerta, receptores, paneles |
El programa oficial sigue la terminología de SCOM; en cada apartado se indica el equivalente en las herramientas libres, que son las que se usan en los ejercicios.
02Monitorización y Observabilidad: Métricas, Registros y Trazas
La monitorización clásica responde a preguntas conocidas de antemano («¿está el disco por encima del 90 %?»). La observabilidad busca poder responder también a preguntas nuevas sobre por qué un sistema se comporta como lo hace, combinando tres tipos de datos.
| Señal | Qué es | Ejemplo | Herramientas |
|---|---|---|---|
| Métricas | Valores numéricos en el tiempo, baratos de guardar | Peticiones por segundo, % de CPU, p95 del tiempo de respuesta | Zabbix, Prometheus, perfmon |
| Registros (logs) | Sucesos con texto y contexto | «Error 1205: deadlock en pedidos, usuario 1042» | Visor de eventos, journald, Elastic, Graylog, Loki |
| Trazas | Recorrido de una petición a través de varios servicios, con el tiempo de cada tramo | Web 40 ms → API 120 ms → base de datos 1.800 ms | OpenTelemetry, Jaeger, APM comerciales |
Las señales de oro
Latencia
Tiempo de respuesta, separando las peticiones correctas de las fallidas.
Tráfico
Demanda sobre el servicio (peticiones por segundo, sesiones).
Errores
Porcentaje de peticiones que fallan.
Saturación
Lo cerca que está el recurso más limitado de su máximo (colas, uso).
Vigilar estas cuatro señales en cada servicio de cara al usuario detecta la mayoría de los problemas antes que mirar cientos de contadores de bajo nivel.
03Conceptos de Seguridad: Terminología, Perfiles y Ámbito
| Término | Significado |
|---|---|
| Rol de usuario | Conjunto de permisos sobre la plataforma asignado a un grupo de usuarios |
| Perfil | Plantilla de permisos predefinida (administrador, operador, operador avanzado, autor, solo lectura) |
| Ámbito (scope) | Conjunto de objetos sobre los que actúa un rol: grupos de equipos, vistas y tareas permitidas |
| Cuenta de ejecución (Run As) | Credenciales que usa la plataforma para obtener datos o ejecutar tareas en los equipos vigilados |
| Cuenta de acción del agente | Cuenta con la que el agente se ejecuta en cada equipo (normalmente LocalSystem o una cuenta de bajo privilegio) |
| Autenticación mutua | Agente y servidor verifican su identidad (Kerberos en dominio, certificados fuera de él) |
Perfiles, descripción y ámbito
| Perfil | Puede… | No puede… |
|---|---|---|
| Administrador | Todo: configuración, seguridad, importación de módulos | - |
| Autor | Crear y modificar monitores, reglas, tareas y vistas | Cambiar la seguridad |
| Operador avanzado | Ajustar (override) monitores y reglas existentes, además de operar | Crear módulos nuevos |
| Operador | Ver el estado, gestionar alertas (reconocer, cerrar), ejecutar tareas permitidas | Cambiar la configuración |
| Operador de solo lectura | Ver el estado y las alertas | Modificar nada |
| Operador de informes | Ver y ejecutar informes | Operar alertas |
Mínimo privilegioEl operador del turno de noche de la sede de Elche debe ver solo los servidores de Elche y ejecutar solo las tareas aprobadas (reiniciar un servicio), no todas. El ámbito se define por grupos de equipos.
04Componentes Básicos de una Plataforma de Gestión de Operaciones
Servidor de administración
Recibe los datos de los agentes, aplica la configuración, genera alertas y ejecuta flujos. Puede haber varios en un grupo para repartir carga y tolerar fallos.
Base de datos operacional
Guarda la configuración y los datos recientes (unos días): estado, alertas, eventos y rendimiento.
Almacén de datos (data warehouse)
Guarda el histórico a largo plazo (meses o años), agregado, para los informes.
Agentes
En cada equipo vigilado: recogen datos, evalúan monitores y reglas localmente y ejecutan tareas.
Servidor de puerta de enlace (gateway)
Intermediario para equipos de otro dominio, de una DMZ o de una sede remota.
Consola de operaciones y consola web
Interfaz de los operadores y administradores.
Servidor de informes
Genera los informes a partir del almacén de datos (SQL Server Reporting Services en SCOM).
Módulos de administración
Definen qué y cómo se supervisa cada tecnología.
| SCOM | Zabbix | Nagios / Icinga |
|---|---|---|
| Servidor de administración | Zabbix server | Núcleo de Nagios / Icinga 2 |
| Base de datos operacional y almacén | Base de datos con tablas de histórico y de tendencias (trends) | Ficheros de estado / IDO y bases de datos |
| Agente | Zabbix agent 2 | NRPE / agente de Icinga |
| Gateway | Zabbix proxy | Satélite de Icinga |
| Módulo de administración | Plantilla | Plugins y configuraciones |
05La Consola de Operaciones: Descripción, Características y Acceso
Áreas de la consola
| Área (espacio de trabajo) | Para qué sirve | Quién la usa |
|---|---|---|
| Supervisión (Monitoring) | Estado de los objetos, alertas activas, vistas de rendimiento y de eventos, paneles, diagramas | Operadores |
| Creación (Authoring) | Crear y ajustar monitores, reglas, tareas, grupos y vistas | Autores y operadores avanzados |
| Informes (Reporting) | Ejecutar y programar informes | Responsables y operadores de informes |
| Administración (Administration) | Agentes, servidores, seguridad, notificaciones, importación de módulos | Administradores |
| Mi área de trabajo (My Workspace) | Vistas y búsquedas personales | Todos |
Características y funciones
- Vista de estado: cada objeto (equipo, servicio, base de datos) aparece en verde (correcto), amarillo (advertencia), rojo (crítico) o gris (sin datos, agente sin comunicación o en mantenimiento).
- Vista de alertas: lista filtrable por gravedad, prioridad, antigüedad y estado de resolución.
- Explorador de estado (Health Explorer): árbol de monitores de un objeto que muestra qué monitor concreto está en rojo y por qué.
- Vistas de rendimiento: gráficos de los contadores recogidos por las reglas.
- Panel de tareas: acciones disponibles para el objeto seleccionado.
- Modo de mantenimiento: silenciar un equipo durante una intervención.
Acceso a la consola
- Consola de escritorio instalada en el equipo del operador o consola web desde el navegador.
- Autenticación con la cuenta de dominio del operador, que debe pertenecer a un rol de usuario.
- En las herramientas libres, acceso web por HTTPS con usuario propio o integrado con LDAP o SSO, y autenticación multifactor si es posible.
06Los Módulos de Administración (Management Packs)
Un módulo de administración es un paquete que contiene todo el conocimiento necesario para supervisar una tecnología: cómo descubrir sus componentes, qué monitores y reglas aplicar, qué tareas ofrecer, qué vistas y qué informes. Los publican los fabricantes (Microsoft para Windows Server, SQL Server, IIS, Active Directory; terceros para Linux, VMware o cabinas) y la comunidad.
| Contenido de un módulo | Función |
|---|---|
| Clases y descubrimientos (discoveries) | Detectar automáticamente qué hay en cada equipo (si tiene IIS, qué sitios web, qué bases de datos) |
| Monitores | Evaluar el estado de cada componente |
| Reglas | Recoger datos y generar alertas por eventos |
| Tareas | Acciones que el operador puede ejecutar |
| Vistas y paneles | Cómo se muestra la información |
| Informes | Plantillas de informes específicos |
| Base de conocimiento | Explicación de cada alerta, causas y resolución |
Módulos sellados y no sellados; ajustes (overrides)
- Los módulos de los fabricantes vienen sellados: no se pueden modificar directamente.
- Para cambiar un umbral o desactivar una regla se crea un ajuste (override) que se guarda en un módulo propio no sellado (por ejemplo, «Ajustes - SQL Server»). Nunca se guardan en el módulo predeterminado.
- Equivalente en Zabbix: no modificar la plantilla oficial, sino usar macros de usuario a nivel de host o de plantilla propia ({$VFS.FS.PUSED.MAX.WARN}).
07Ejemplo Comentado de Plantilla de Servicio
Una plantilla (el equivalente libre de un módulo de administración) reúne todo lo necesario para vigilar un tipo de servicio. Este es el esquema de una plantilla propia para una aplicación web interna, tal como se definiría en Zabbix.
| Elemento | Definición | Equivale en SCOM a… |
|---|---|---|
| Macros | {$WEB.URL} = https://intranet.local · {$WEB.TIEMPO.MAX} = 2 · {$PROC.NOMBRE} = apache2 | Parámetros ajustables (overrides) |
| Elemento 1 | proc.num[{$PROC.NOMBRE}] cada 1 min | Monitor unitario de servicio |
| Elemento 2 | Escenario web: GET {$WEB.URL}, código 200 y texto «Intranet» en la página | Monitor sintético |
| Elemento 3 | log[/var/log/apache2/error.log,"(error|crit)"] (agente activo) | Regla de alerta por evento de registro |
| Elemento 4 | Conexiones establecidas al puerto 443, cada 5 min, solo para gráficos | Regla de recopilación de rendimiento |
| Desencadenador A | proc.num = 0 → Alta; se recupera solo | Estado crítico del monitor |
| Desencadenador B | Tiempo de respuesta > {$WEB.TIEMPO.MAX} s durante 5 min → Media | Monitor con umbral |
| Dependencia | B depende de A (si el proceso no existe, no avisar también de la lentitud) | Monitor de dependencia |
| Gráfico y panel | Tiempo de respuesta y conexiones | Vistas de rendimiento |
# Fragmento de la plantilla exportada en YAML (simplificado)
zabbix_export:
templates:
- template: Intranet - Ajustes
macros:
- {macro: '{$PROC.NOMBRE}', value: apache2}
- {macro: '{$WEB.TIEMPO.MAX}', value: '2'}
items:
- name: Procesos de Apache
key: 'proc.num[{$PROC.NOMBRE}]'
delay: 1m
triggers:
- expression: 'last(/Intranet - Ajustes/proc.num[{$PROC.NOMBRE}])=0'
name: Apache no se está ejecutando
priority: HIGH
Versionar las plantillasExporta las plantillas propias en YAML y guárdalas en Git. Así se puede revisar qué cambió, recuperar una versión anterior y desplegar la misma plantilla en otra instalación.
08Los Monitores: Tipos y Estados de Mantenimiento
Un monitor evalúa continuamente una condición y mantiene un estado de salud (correcto, advertencia o crítico). Cuando cambia de estado puede generar una alerta y, al volver a correcto, cerrarla automáticamente.
| Tipo de monitor | Funcionamiento | Ejemplo |
|---|---|---|
| Monitor unitario | Evalúa una condición concreta | Servicio Spooler en ejecución; espacio libre de C: > 10 % |
| Monitor de agregado | Resume el estado de varios monitores hijos (el peor de ellos) | Disponibilidad del servidor = peor de sus servicios críticos |
| Monitor de dependencia | Hace que el estado de un objeto dependa del de otro | La aplicación web está en rojo si su base de datos lo está |
| Monitor unitario según la fuente | Ejemplo |
|---|---|
| De servicio de Windows o demonio | Estado de un servicio |
| De contador de rendimiento con umbral (estático, doble umbral o dinámico) | CPU > 90 % durante 3 muestras |
| De registro de eventos | Pasa a crítico con el evento 1000 y vuelve a correcto con el 1001 |
| De script | Script que comprueba algo y devuelve un estado |
| Sintético o de transacción | Petición web que debe devolver 200 en menos de 2 s |
Categorías de salud
DisponibilidadRendimientoConfiguraciónSeguridad
Los monitores se agrupan en estas cuatro categorías, de modo que la consola puede mostrar, por ejemplo, que un servidor está disponible pero con problemas de rendimiento.
09Las Reglas para la Obtención de Datos y sus Tipos
Las reglas no tienen estado: recogen datos o reaccionan a un suceso. Sirven para alimentar las vistas de rendimiento y los informes, y para alertar de sucesos puntuales.
| Tipo de regla | Qué hace | Ejemplo |
|---|---|---|
| De recopilación de rendimiento | Guarda periódicamente el valor de un contador | % de CPU cada 5 minutos, para gráficos e informes |
| De recopilación de eventos | Guarda eventos de un registro | Todos los eventos de error de la aplicación ERP |
| De alerta por evento | Genera una alerta cuando aparece un evento concreto | Evento 7034: un servicio se ha detenido inesperadamente |
| De recopilación por script o WMI/CIM | Obtiene datos que no son contadores | Número de usuarios conectados a la aplicación |
| De traps SNMP o syslog | Recoge mensajes enviados por equipos de red o Linux | Trap del SAI |
| Monitor | Regla | |
|---|---|---|
| ¿Tiene estado? | Sí (verde, amarillo, rojo) | No |
| ¿Cierra sola su alerta? | Sí, al volver a correcto | No: se cierra a mano |
| Uso principal | Salud de un componente | Recoger datos y avisar de sucesos puntuales |
| Equivalente en Zabbix | Elemento + desencadenador con expresión de recuperación | Elemento (item) que solo guarda datos, o desencadenador sin recuperación automática |
10Descubrimiento Automático y Servicios de Negocio
Descubrimiento automático
| Tipo | Qué descubre | Ejemplo |
|---|---|---|
| Descubrimiento de red | Equipos nuevos en un rango IP | Alta automática de cualquier equipo que responda al agente o a SNMP en 10.0.5.0/24, con su plantilla según el tipo |
| Descubrimiento de bajo nivel (LLD) | Componentes dentro de un equipo | Un elemento y un desencadenador por cada disco, interfaz de red, servicio de Windows o base de datos que tenga el equipo |
| Registro automático de agentes | Agentes activos que se presentan solos | Los portátiles con el agente se dan de alta al conectarse por primera vez, según sus metadatos |
Gracias al descubrimiento, si se añade un disco a un servidor, empieza a vigilarse sin que nadie tenga que acordarse; y si se retira, el elemento desaparece tras un periodo configurable.
Servicios de negocio
La dirección no pregunta por discos ni procesos, sino por servicios: «¿ha funcionado la tienda en línea este mes?». La plataforma modela cada servicio como un árbol de componentes con reglas de cálculo del estado.
| Servicio «Tienda en línea» | Componentes | Regla de estado |
|---|---|---|
| Capa web | WEB1, WEB2 detrás de un balanceador | Caído solo si caen los dos (redundancia) |
| Capa de datos | BD principal con réplica | Degradado si cae la réplica; caído si cae la principal |
| Pagos | Pasarela externa (comprobación sintética) | Caído si la comprobación falla 3 veces seguidas |
| Servicio completo | Las tres capas | Caído si cualquier capa está caída |
Con este modelo se calcula el SLA real del servicio y se evita alarmar a la dirección por la caída de un solo servidor web que la redundancia ya cubre.
11Incidencias y Alarmas: Identificación y Clasificación de la Gravedad
Identificación
Cada alerta indica: objeto origen (equipo y componente), nombre, descripción, gravedad, prioridad, número de repeticiones, fecha de la primera y la última aparición, el monitor o la regla que la generó y un enlace al conocimiento (causas y resolución).
| Gravedad | Significado | Respuesta esperada |
|---|---|---|
| Crítica (error) | El servicio está caído o a punto de caer | Inmediata; incidencia de prioridad alta |
| Advertencia | Degradación o riesgo | En el turno; vigilar la tendencia |
| Información | Algo relevante pero sin problema | Registrar; no requiere acción |
Además de la gravedad, la prioridad (alta, media, baja) ordena alertas de la misma gravedad. En Zabbix hay seis niveles: no clasificada, información, advertencia, media, alta y desastre.
Estados de resolución de una alerta
| Estado | Significado |
|---|---|
| Nueva | Acaba de generarse |
| Reconocida | Un operador la está atendiendo |
| Asignada a nivel 2 o a otro grupo / tique abierto | Escalada; vinculada a la herramienta de incidencias |
| Resuelta / cerrada | El monitor ha vuelto a correcto o el operador la cierra con la causa |
Integración con la gestión de incidenciasLas alertas críticas deben abrir automáticamente un tique en la herramienta de incidencias (GLPI, ServiceNow…) con los datos de la alerta, y cerrarlo o actualizarlo cuando la alerta se resuelve. Así queda registro del tiempo de respuesta y de resolución para el SLA.
12Gestión de Eventos a Escala
| Técnica | Qué hace | Ejemplo |
|---|---|---|
| Deduplicación | Une las repeticiones del mismo evento en una sola alerta con un contador | «Servicio X detenido» × 37 en una sola alerta |
| Correlación por dependencia | Muestra solo la causa cuando cae algo de lo que dependen otros | Cae el router de la sede: una alerta, no cuarenta |
| Correlación por etiquetas | Agrupa eventos del mismo servicio o sede en un problema | Todos los eventos con servicio=ERP en los últimos 10 minutos |
| Supresión por mantenimiento | No notifica durante una intervención planificada (los datos se siguen recogiendo) | Ventana del domingo de 2:00 a 5:00 para parches |
| Retardo y persistencia | Solo alerta si la condición dura un tiempo | CPU > 90 % durante 10 minutos, no un pico de 30 segundos |
| Escalado temporal | Sube de nivel si nadie reconoce la alerta | 15 min → responsable; 30 min → guardia |
| Detección de anomalías (AIOps) | Compara con el comportamiento aprendido para cada hora y día | Tráfico del martes a las 11:00 un 60 % por debajo de lo habitual |
Mantenimiento sin silencio totalEn una ventana de mantenimiento conviene seguir recogiendo datos (para ver el antes y el después) y suprimir solo las notificaciones. Y la ventana debe terminar sola: una supresión olvidada «hasta nuevo aviso» es una de las causas clásicas de que nadie se entere de una caída real.
13Resolución de Incidencias y Alarmas mediante la Ejecución de Tareas
Las tareas son acciones predefinidas que el operador ejecuta desde la consola sobre el objeto que tiene la alerta, sin conectarse al equipo. También pueden ejecutarse solas como recuperación automática (recovery) cuando un monitor pasa a crítico.
| Tipo de tarea | Ejemplo |
|---|---|
| De diagnóstico | Ver los procesos que más CPU consumen, hacer ping, mostrar el uso de disco |
| De recuperación | Reiniciar el servicio detenido, vaciar la cola de impresión, borrar ficheros temporales |
| De consola | Abrir escritorio remoto, el Visor de eventos o una sesión de PowerShell contra el equipo |
| Script personalizado | Rotar un log que ha crecido demasiado |
# Zabbix: script global (Alertas → Scripts) que el operador lanza desde un problema
# Nombre: Reiniciar servicio web Ejecutar en: agente Zabbix
sudo systemctl restart apache2
# En el agente (zabbix_agent2.conf) hay que permitirlo expresamente:
# AllowKey=system.run[*] (mejor limitarlo a órdenes concretas)
# y en sudoers: zabbix ALL=(root) NOPASSWD: /bin/systemctl restart apache2
ControlLas tareas de recuperación automática ahorran tiempo, pero pueden ocultar problemas: un servicio que se reinicia solo cada hora tiene un fallo que hay que investigar. Registra cada ejecución y vigila las repeticiones.
14Runbooks: el Procedimiento Asociado a Cada Alerta
Un runbook (procedimiento operativo) explica, para una alerta concreta, qué significa y qué debe hacer el operador. Se enlaza desde la propia alerta, de modo que quien está de guardia a las 3:00 no tiene que improvisar.
| Apartado del runbook | Ejemplo para «Disco /var del servidor de correo > 90 %» |
|---|---|
| Significado e impacto | Si /var se llena, el servidor deja de recibir y enviar correo |
| Comprobaciones | df -h /var · du -xh /var --max-depth=2 | sort -h | tail · tamaño de la cola (mailq | tail -1) |
| Causas conocidas | Registros sin rotar · cola de correo atascada · copias locales temporales |
| Acciones permitidas al nivel 1 | Comprimir o borrar registros rotados de más de 30 días; ejecutar la tarea de limpieza aprobada |
| Acciones que NO debe hacer | Borrar la cola de correo, reiniciar el servidor en horario laboral |
| Escalado | Si no baja del 85 % en 30 min, a Sistemas (nivel 2) |
| Verificación y cierre | Espacio < 80 %, cola de correo vacía, prueba de envío correcta |
- Cada alerta que puede despertar a alguien debe tener su runbook; si no hay nada que hacer con una alerta, probablemente sobra.
- Se revisan tras cada incidencia: si el procedimiento no sirvió, se corrige.
- Las acciones repetitivas y seguras del runbook son candidatas a convertirse en tareas de recuperación automática.
15Configuración de Notificaciones
| Elemento (SCOM) | Equivalente (Zabbix) | Función |
|---|---|---|
| Canal | Tipo de medio | Cómo se envía: correo SMTP, SMS, mensajería, comando, webhook |
| Suscriptor | Usuario con sus medios | A quién: dirección de correo o teléfono, y horario en que se le puede avisar |
| Suscripción | Acción | Qué alertas se envían (gravedad, grupo de equipos, tipo), a quién y por qué canal, con retardo y escalado |
- 1. Configurar el canal: servidor SMTP, remitente y formato del mensaje (equipo, alerta, gravedad, descripción, hora, enlace).
- 2. Crear los suscriptores: con sus horarios (laboral o guardia).
- 3. Crear las suscripciones: por ejemplo, alertas críticas de los servidores de producción → equipo de sistemas por correo y mensajería, 24 × 7.
- 4. Definir el escalado: si no se reconoce en 15 minutos, avisar al responsable.
- 5. Probar: provocar una alerta y comprobar que llega a quien debe.
# Zabbix: macros típicas en el mensaje de una acción
Problema: {EVENT.NAME}
Equipo: {HOST.NAME} ({HOST.IP}) Gravedad: {EVENT.SEVERITY}
Inicio: {EVENT.DATE} {EVENT.TIME} Valor: {ITEM.LASTVALUE}
Ver: {$ZABBIX.URL}/tr_events.php?triggerid={TRIGGER.ID}&eventid={EVENT.ID}
16Creación de Informes
| Informe | Contenido | Destinatario |
|---|---|---|
| Disponibilidad | % de tiempo en estado correcto de cada servidor o servicio en el periodo, frente al SLA | Responsable de servicio, dirección |
| Alertas más frecuentes (top N) | Qué alertas se repiten más y en qué equipos | Equipo técnico: candidatos a problema y a ajuste de umbrales |
| Rendimiento | Gráficos de CPU, memoria, disco y red con mínimos, máximos y medias | Planificación de capacidad |
| Tendencia de capacidad | Previsión de llenado de discos y de crecimiento de carga | Compras y planificación |
| Configuración o inventario | Versiones de SO y de aplicaciones de los equipos vigilados | Gestión de cambios, auditoría |
| Eventos de seguridad o de cumplimiento | Sucesos relevantes del periodo | Seguridad |
- Elegir el informe y los parámetros: periodo, objetos (grupo de equipos), agregación (por hora, por día).
- Ejecutarlo y revisarlo: comprobar que los datos son coherentes.
- Programarlo: envío automático por correo cada semana o cada mes en PDF o Excel.
- Publicarlo: en un panel (Grafana, consola web) para consulta continua.
Del dato a la decisiónUn informe de disponibilidad del 99,2 % con un SLA del 99,5 % debe ir acompañado de la explicación (qué caídas hubo y por qué) y de las acciones para el mes siguiente. Si no, solo es un número.
17Caso Práctico Resuelto: Puesta en Marcha de la Plataforma en 30 Días
Una empresa de transporte con 2 sedes, 14 servidores (10 virtuales), 6 switches, 2 SAI y 90 puestos no tiene ninguna monitorización. Se elige Zabbix y se planifica la implantación por fases para no generar ruido desde el primer día.
| Semana | Objetivo | Tareas | Resultado |
|---|---|---|---|
| 1 | Base | Instalar servidor y base de datos en una VM propia; HTTPS; usuarios y roles; proxy en la segunda sede | Plataforma accesible y segura |
| 2 | Infraestructura | Agentes en los 14 servidores con plantillas oficiales; SNMPv3 en switches y SAI; IPMI de los físicos | Inventario de lo vigilado; muchas alertas iniciales |
| 3 | Ajuste | Revisar cada alerta: ajustar umbrales con macros, dependencias, desactivar lo que no aporta; ventanas de mantenimiento | De 140 alertas diarias a 6 relevantes |
| 4 | Servicio | Servicios de negocio (ERP, correo, seguimiento de flota), notificaciones con escalado, integración con GLPI, runbooks de las 10 alertas principales, primer informe de disponibilidad | Puesta en producción y traspaso al CSU |
Indicadores tras tres mesesEl 80 % de las incidencias se detectan por la plataforma antes de que llame un usuario; el tiempo medio de detección baja de 47 a 4 minutos; dos discos y una batería de SAI se sustituyeron antes de fallar gracias a las alertas predictivas.
18Glosario de la Parte II
- Plataforma de gestión de operaciones
- Sistema que supervisa de forma centralizada la salud del software y permite actuar desde una consola.
- Servidor de administración
- Componente central que recibe datos, evalúa y genera alertas.
- Almacén de datos (data warehouse)
- Base de datos con el histórico agregado para informes.
- Módulo de administración / plantilla
- Paquete con el conocimiento para vigilar una tecnología.
- Ajuste (override)
- Cambio de un umbral o parámetro sin modificar el módulo original.
- Monitor
- Elemento con estado de salud (correcto, advertencia, crítico).
- Regla
- Elemento sin estado que recoge datos o genera alertas por sucesos.
- Explorador de estado
- Vista del árbol de monitores de un objeto.
- Tarea
- Acción predefinida que se ejecuta sobre un objeto desde la consola.
- Canal / suscriptor / suscripción
- Medio de envío / destinatario / qué se envía a quién.
- Descubrimiento (LLD)
- Detección automática de componentes que hay que vigilar.
- Servicio de negocio
- Modelo de un servicio como árbol de componentes con reglas de estado.
- Deduplicación
- Agrupar repeticiones del mismo evento en una sola alerta.
- Runbook
- Procedimiento operativo asociado a una alerta.
- Señales de oro
- Latencia, tráfico, errores y saturación de un servicio.
19Autoevaluación de la Parte II
¿Qué diferencia hay entre la base de datos operacional y el almacén de datos?
La operacional guarda la configuración y los datos recientes para trabajar en tiempo real; el almacén guarda el histórico agregado durante meses o años para los informes.
¿Por qué no se modifican directamente los módulos sellados del fabricante?
Porque una actualización del módulo borraría los cambios. Los ajustes se guardan en un módulo propio no sellado (o en macros de una plantilla propia en Zabbix).
Pon un ejemplo de monitor de dependencia.
La aplicación web está en estado crítico si la base de datos de la que depende está en estado crítico.
Un monitor genera una alerta y una regla genera otra. ¿Cuál se cierra sola al resolverse el problema?
La del monitor, porque al volver a estado correcto cierra su alerta. La de la regla no tiene estado y hay que cerrarla manualmente.
¿Qué perfil darías al operador del turno de noche?
Operador con ámbito limitado a sus grupos de equipos: puede ver, reconocer y cerrar alertas y ejecutar las tareas aprobadas, pero no cambiar la configuración.
¿Qué riesgo tiene una tarea de recuperación automática que reinicia un servicio?
Que oculte un problema de fondo: el servicio se cae y se levanta una y otra vez sin que nadie investigue la causa. Hay que registrar y vigilar las repeticiones.
¿Qué datos mínimos debe llevar una notificación?
Equipo y servicio afectado, nombre de la alerta, gravedad, valor y umbral, hora de inicio y enlace a la consola o al runbook.
¿Qué son las cuatro señales de oro?
Latencia, tráfico, errores y saturación de un servicio.
¿Por qué una ventana de mantenimiento debe tener fecha de fin?
Para que las notificaciones se reactiven solas; una supresión olvidada impide enterarse de caídas reales.