Conceptos clave
Esta página define los conceptos y términos que se usan de forma consistente en toda la documentación de NetMonitor. Se recomienda leerla antes de abordar cualquier módulo específico.
Disponibilidad y SLI / SLA
SLI — Service Level Indicator
El SLI (Service Level Indicator, o indicador de disponibilidad) es el valor calculado por NetMonitor para representar la disponibilidad real observada de un activo durante un período.
Se calcula como:
SLI (%) = (ciclos disponibles / total de ciclos) × 100
Donde un ciclo es un intervalo de recolección (polling time). Si NetMonitor detecta que el activo está disponible en ese ciclo, el ciclo cuenta como disponible.
El SLI es un dato descriptivo: mide lo que efectivamente ocurrió. No es un objetivo, es un registro.
SLA — Service Level Agreement
El SLA (Service Level Agreement, o acuerdo de nivel de servicio) es el porcentaje de disponibilidad esperado que se configura para cada activo en Asset Manager.
El SLA es una decisión operativa: define qué nivel de disponibilidad es aceptable para ese activo. Cuando el SLI cae por debajo del SLA configurado, NetMonitor puede generar una alarma.
| SLA configurado | Comportamiento |
|---|---|
0% | NetMonitor sigue recolectando datos pero no genera alarmas por indisponibilidad. Útil para activos en prueba o no críticos. |
1% – 99% | Monitoreo estándar. Genera alarma cuando el SLI cae por debajo del SLA. |
100% | Monitoreo de alta frecuencia mediante ICMP continuo. Usar con criterio: consume más recursos. |
SLA y SLI no son lo mismo. El SLA es la expectativa; el SLI es el resultado medido.
Tiempos operativos: MTTR y MTBF
MTTR — Mean Time To Recover
El MTTR (Mean Time To Recover, tiempo promedio de recuperación) mide cuánto tiempo transcurre en promedio desde que un activo o servicio falla hasta que se recupera.
MTTR = Suma de todos los tiempos de indisponibilidad / Número de incidentes
Un MTTR alto indica que los problemas tardan mucho en resolverse. NetMonitor contribuye a reducir el MTTR acelerando la detección y el diagnóstico, que son las etapas previas a la solución.
MTBF — Mean Time Between Failures
El MTBF (Mean Time Between Failures, tiempo promedio entre fallas) mide cuánto tiempo transcurre en promedio entre una falla y la siguiente.
MTBF = Suma de todos los tiempos de operación sin fallas / Número de fallas
Un MTBF alto indica mayor estabilidad. NetMonitor contribuye a aumentar el MTBF mediante el monitoreo de umbrales (detectar degradación antes de la falla) y el análisis de recurrencia (identificar problemas que se repiten).
Relación con disponibilidad
La disponibilidad de un activo está relacionada con ambas métricas:
Disponibilidad (%) ≈ MTBF / (MTBF + MTTR) × 100
Para aumentar la disponibilidad se puede reducir el MTTR (resolver más rápido) o aumentar el MTBF (fallar menos seguido). Ambas son estrategias complementarias.
Polling time (intervalo de recolección)
El polling time, o intervalo de recolección, es el tiempo entre dos ciclos de recolección de datos sobre un activo. El valor estándar en NetMonitor es 10 minutos.
En cada ciclo de polling, NetMonitor:
- Envía consultas SNMP (o usa el protocolo configurado) al activo.
- Recibe los datos de disponibilidad, interfaces, recursos y variables configuradas.
- Actualiza el estado del activo en la plataforma.
- Evalúa si corresponde generar alarmas o alertas.
El polling time define la resolución temporal del monitoreo: una caída de 3 minutos puede no ser detectada si ocurre dentro de un ciclo. La detección puede tardar hasta un ciclo completo (10 minutos en la configuración estándar).
NetMonitor no declara un activo como caído al primer timeout de polling. Realiza 3 intentos antes de generar la alarma. Este comportamiento reduce los falsos positivos por problemas transitorios de red.
Activos y emplazamientos
Activo monitoreado
Un activo es cualquier dispositivo, sistema o servicio que NetMonitor supervisa. Puede ser un switch, un firewall, un servidor, una cámara IP, un UPS, una aplicación web o un servicio de red.
Los activos se registran en Asset Manager y deben estar en estado "Habilitado" para ser monitoreados activamente.
Emplazamiento
Un emplazamiento es la ubicación física o lógica a la que pertenece un activo. Puede representar un datacenter, una sucursal, un piso, un rack o cualquier unidad geográfica o funcional relevante para la organización.
Los emplazamientos permiten agrupar activos, filtrar vistas y construir mapas topológicos por ubicación.
Eventos: alarmas, alertas y notificaciones
Estos tres términos tienen significados específicos en NetMonitor y no deben usarse de forma intercambiable.
Alarma
Una alarma es un evento generado por el motor de NetMonitor (Core) cuando se detecta un cambio en la disponibilidad de un activo o servicio. Ejemplos:
- Un activo deja de responder (caída).
- Un activo se recupera después de una caída.
- El SLI de un activo cae por debajo del SLA configurado.
Las alarmas se generan mediante firmas evaluadas sobre el estado de disponibilidad de los activos.
Alerta
Una alerta es un evento generado cuando el valor de una métrica supera un umbral configurado. Ejemplos:
- CPU de un servidor supera el 85%.
- Temperatura de un switch supera los 60°C.
- Utilización de un enlace supera el 90% del ancho de banda.
Las alertas se configuran mediante umbrales en Asset Manager o en la pestaña Notificaciones de cada activo.
Notificación
Una notificación es la comunicación enviada a un canal externo (email, Telegram, Teams, etc.) cuando se genera una alarma o alerta. La notificación es el mecanismo por el cual el equipo operativo es informado de los eventos.
Una alarma puede generar cero o más notificaciones, según las reglas configuradas.
Procesamiento de eventos: firmas, reglas y canales
Firma
Una firma es la definición de qué condición debe cumplirse para considerar que existe un evento de alarma. Define el patrón de detección: qué activo, qué estado, con qué frecuencia y qué severidad.
Ejemplo de firma: "El activo X no responde a ICMP durante 3 ciclos consecutivos → generar evento de caída con severidad crítica."
Regla
Una regla define qué hacer cuando se activa una firma: a qué canales enviar la notificación, con qué texto, con qué periodicidad de recordatorio.
Las reglas conectan las firmas (qué ocurrió) con los canales (a quién notificar y cómo).
Canal
Un canal es el medio por el cual se envían las notificaciones. NetMonitor soporta múltiples canales simultáneos:
- Email (SMTP)
- Telegram
- Microsoft Teams
- Webhook HTTP (integración con sistemas externos)
- Tickets en plataformas ITSM (ServiceNow, Jira, etc.)
Componentes de la plataforma
NetUI
NetUI es la interfaz web de NetMonitor. Es una aplicación 100% HTML5 que funciona en cualquier navegador moderno sin plugins adicionales. A través de NetUI el operador accede a todos los paneles, vistas de activos, mapas, informes y configuraciones.
NetCollector
El NetCollector es el agente de recolección de datos de NetMonitor. Se despliega en la red del cliente (o en la nube) y es el responsable de realizar el polling a los activos, recibir TRAPs SNMP y enviar los datos al motor Core.
Una instalación puede tener múltiples NetCollectors para cubrir distintos segmentos de red o sitios geográficos.
Asset Manager
El Asset Manager es el módulo de gestión de activos de NetMonitor. Es el equivalente a un CMDB (Configuration Management Database): allí se registran todos los activos monitoreados con su configuración, relaciones, criticidad y niveles de SLA.
Solo los activos dados de alta y habilitados en Asset Manager son monitoreados por NetMonitor.
Identificación de eventos SNMP: OID y MIB
Antes de que una firma pueda evaluar un TRAP, NetMonitor necesita identificar de qué evento se trata. Ese paso de identificación se resuelve mediante dos elementos: el OID y la MIB.
OID — Object Identifier
Un OID (Object Identifier, o identificador de objeto) es el código numérico jerárquico que identifica de forma única una variable o un evento dentro de una MIB. Cada TRAP SNMP, cada métrica y cada estado que un activo puede reportar tiene un OID asociado.
Los OID tienen forma de secuencia numérica separada por puntos, por ejemplo: 1.3.6.1.4.1.9.9.41.2
Cada nivel de la jerarquía representa una rama dentro del árbol de gestión definido por el estándar SNMP (organización, fabricante, producto, tipo de evento, etc.).
Cuando el NetCollector recibe un TRAP, lo primero que identifica es su OID. Ese OID por sí solo es solo un número: no tiene significado legible hasta que se lo compara contra una MIB.
MIB — Management Information Base
Una MIB (Management Information Base, o base de información de gestión) es el archivo que define y documenta el significado de los OID de un fabricante o dispositivo determinado. Funciona como un "diccionario": traduce cada OID numérico a una descripción legible (nombre de la variable, tipo de dato, severidad, texto del evento, etc.).
Las MIBs son provistas por los fabricantes de cada equipo (switches, firewalls, UPS, etc.) y deben cargarse en NetMonitor para que el sistema pueda interpretar correctamente los TRAPs que recibe de esos activos.
Relación entre OID y MIB
- El OID es el identificador que viaja dentro del TRAP.
- La MIB es la referencia que NetMonitor consulta para traducir ese OID a una descripción comprensible del evento.
- Sin la MIB correspondiente cargada, NetMonitor puede recibir el TRAP pero mostrarlo como un OID crudo, sin descripción legible.
Este paso de traducción (OID → MIB → descripción) es lo que permite que un evento técnico de bajo nivel se muestre en NetUI como un mensaje entendible para el operador.
iLO: Administración remota de hardware
iLO (Integrated Lights-Out) es una tecnología de administración remota integrada en los servidores HPE ProLiant, que permite supervisar y gestionar el servidor de forma independiente del sistema operativo.
A través de iLO es posible consultar el estado de componentes de hardware como CPU, memoria, discos, fuentes de alimentación, ventiladores y temperatura, además de realizar tareas de administración remota como el encendido, apagado, reinicio y acceso a la consola del servidor.
iLO funciona mediante un controlador de administración integrado en el servidor, permitiendo acceder a sus funciones incluso cuando el sistema operativo no se encuentra disponible.