Ejemplo de AlertMap para DX NetOps Spectrum
========================================

Introducción
------------

Este documento describe un **ejemplo de mapeo de eventos (AlertMap)** para integrar
las trampas SNMP emitidas por servidores DNS autoritativos de Planisys con
**DX NetOps Spectrum**.

El objetivo es facilitar una **Prueba de Concepto (PoC)** y servir como referencia
para equipos NOC y de operaciones.

----

Conceptos básicos
-----------------

En DX NetOps Spectrum, un *AlertMap* (o *Event-to-Alarm Mapping*) define:

* Qué **evento SNMP** se recibe (OID de la trampa)
* Qué **alarma** se genera en Spectrum
* Con qué **severidad**
* Qué **mensaje** se muestra al operador
* A qué **tipo de modelo** se asocia (Host, Application, etc.)

Las trampas de Planisys utilizan **SNMPv2 estándar** y son totalmente compatibles
con el sistema de eventos de Spectrum.

----

MIB utilizado
-------------

Las reglas descritas en este documento se basan en el siguiente MIB:

::

   PLANISYS-BIND-AUTH-MIB

OID raíz de la empresa:

::

   1.3.6.1.4.1.64835 

----

Resumen de traps soportados
---------------------------

+--------------+-------------------------------+----------------+
| Trampa       | Descripción                   | Severidad      |
+==============+===============================+================+
| dnsSvcDown   | Servicio BIND detenido o caído| Crítica        |
+--------------+-------------------------------+----------------+
| dnsSvcUp     | Servicio BIND operativo       | Informativa    |
+--------------+-------------------------------+----------------+

----

Ejemplo de reglas AlertMap
^^^^^^^^^^^^^^^^^^^^^^^^^^

Las siguientes secciones describen **cómo deberían configurarse las reglas**
en Spectrum. Los nombres exactos de menús pueden variar según la versión, pero
el concepto es el mismo.

----

Alarma: Servicio DNS autoritativo caído
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Evento de entrada
"""""""""""""""""

* **OID de la trampa**
  
  ::

     PLANISYS-BIND-AUTH-MIB::dnsSvcDown

* **Origen**
  
  Host (modelo de tipo Host o Application)

Condiciones
"""""""""""

* La trampa contiene el varbind ``pdnsHostFqdn``
* ``pdnsSeverity = 1`` (Crítica)

Acción en Spectrum
""""""""""""""""""

* Crear una nueva alarma

Severidad
^^^^^^^^^

* **Critical**

Mensaje recomendado
^^^^^^^^^^^^^^^^^^^

::

   Servicio DNS autoritativo caído en {pdnsHostFqdn}

Variables dinámicas
-------------------

Spectrum puede mostrar información adicional usando los varbinds recibidos:

* ``pdnsHostFqdn`` → Host afectado
* ``pdnsEventTimeUtc`` → Hora del evento
* ``pdnsMessage`` → Detalle textual del problema

----

Alarma: Servicio DNS autoritativo operativo
-------------------------------------------

Evento de entrada
^^^^^^^^^^^^^^^^^

* **OID de la trampa**
  
  ::

     PLANISYS-BIND-AUTH-MIB::dnsSvcUp

Condiciones
"""""""""""

* ``pdnsSeverity = 5`` (Informativa)

Acción en Spectrum
""""""""""""""""""

* Generar evento informativo
* (Opcional) Limpiar o cerrar la alarma asociada a ``dnsSvcDown``

Severidad
"""""""""

* **Information**

Mensaje recomendado
"""""""""""""""""""

::

   Servicio DNS autoritativo operativo en {pdnsHostFqdn}

----

Relación entre alarmas (opcional)
---------------------------------

Para una mejor experiencia operativa, se recomienda:

* Asociar ``dnsSvcUp`` como evento de **clear** de ``dnsSvcDown``
* De este modo, cuando el servicio se recupere, la alarma crítica se cerrará
  automáticamente

Este comportamiento es habitual en entornos ITIL/NOC.

----

Validación durante la Prueba de Concepto
----------------------------------------

Procedimiento de prueba
^^^^^^^^^^^^^^^^^^^^^^^

En un servidor DNS autoritativo de Planisys:

::

   systemctl stop named
   systemctl start named

Resultados esperados en Spectrum
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

* Al detener el servicio:
  
  * Se recibe la trampa ``dnsSvcDown``
  * Se genera una alarma **Crítica**

* Al iniciar el servicio:
  
  * Se recibe la trampa ``dnsSvcUp``
  * Se genera un evento informativo
  * (Opcional) Se limpia la alarma crítica previa

----

Buenas prácticas recomendadas
-----------------------------

* Asociar las alarmas al **modelo Host**
* Usar ``pdnsHostFqdn`` como identificador principal
* Mantener severidades consistentes con ITIL
* Documentar estas reglas en el runbook del NOC

----

Notas de seguridad
------------------

* El AlertMap **no define credenciales SNMP**
* Las comunidades SNMP o credenciales SNMPv3 se gestionan fuera de Spectrum
* Se recomienda restringir el acceso UDP/162 mediante firewall

----

Compatibilidad
--------------

Este ejemplo de AlertMap es compatible con:

* DX NetOps Spectrum
* Otras plataformas NMS con mapeo de eventos SNMP similar