Ejemplos de uso: DNS y servicios compuestos

Componer un comportamiento

La configuración de Sentinelia define qué observas, cómo lo interpretas y qué cambia al producirse una transición. Un agente aporta una dirección; un monitor decide si un servicio está disponible; una regla lógica combina condiciones; una acción modifica lo que se anuncia por DNS.

Hay tres decisiones combinables: quién resuelve el nombre, quién mantiene su dirección y qué política decide su anuncio. Un sufijo local, DDNS y una acción pueden formar parte de la misma solución.

Estas recetas parten de una necesidad y combinan esas piezas. Los conceptos de DNS público, privado y sufijos explican la preparación de red; las guías enlazadas presentan los controles de cada operación.

También puedes incorporar presencia y reinicio del perfil servidor. Los ejemplos de agentes, continuidad y recuperación explican cómo usar esas señales y la telemetría como entradas sin alerta individual, y separar la decisión de anunciar un servicio de la decisión de atender una incidencia.

Los esquemas muestran qué aporta cada pieza. En las recetas lógicas, cada letra identifica el monitor de su tarjeta: AND exige todas las condiciones, OR necesita al menos una y NOT invierte una entrada. Puedes cambiar su disponibilidad para explorar la decisión.

Los nombres y direcciones son ejemplos: adapta la zona, la red y los umbrales a tu instalación.

El modo DDNS no determina si el DNS es público o privado. Un DDNS observado también sirve en una LAN si Sentinelia recibe la POL con la dirección local adecuada. El modo declarado permite elegir una conexión; la red de clientes determina si esa dirección les resulta alcanzable.

Diseña también tus propias políticas

Estas recetas son puntos de partida. Utiliza tu conocimiento del servicio y de su contexto para elegir las entradas, la decisión que debe representar cada monitor y las actuaciones que le corresponden. Puedes reutilizar las mismas piezas para resolver necesidades distintas.

La invitación a componer explica esta forma de trabajar, con ideas de continuidad para correo y frontales web basadas en las piezas disponibles.

Equipos internos por nombre corto

Necesidad: los equipos de una oficina deben encontrar equipo-01 sin que una persona cambie el DNS cada vez que cambia su dirección local.

Esquema conceptual

Del nombre corto a la dirección del equipo

1. 01
   Cliente de la oficina

   Solicita «equipo-01» con el sufijo oficina.empresa.example configurado.

2. 02
   Resolución DNS interna

   Consulta equipo-01.oficina.empresa.example mediante el DNS de la red.

3. 03
   Registro del equipo

   El A de categoría DDNS contiene la IPv4 local que mantiene Attacus.

Attacus actualiza el registro mediante su concesión DDNS. El sufijo y el DNS de los clientes se distribuyen desde DHCP, VPN o su configuración de red.

Preparación de la red

Prepara una zona interna oficina.empresa.example y un resolutor que pueda consultarla. Distribuye a los clientes el DNS y el sufijo de búsqueda desde DHCP, la VPN o la configuración de red. La receta utiliza esos servicios de tu infraestructura; no requiere dar de alta un servidor DHCP dentro de Sentinelia.

Configuración en Sentinelia y Attacus

1. En Sentinelia, crea la zona y prepara su publicación en el DNS interno.

2. Crea equipo-01.oficina.empresa.example, tipo A y categoría DDNS.

3. Concédelo al agente que funciona en ese equipo.

4. En Attacus, elige Usar una conexión de red de este equipo y la fuente que aporta su IPv4 local.

5. Revisa y guarda la configuración; comprueba la publicación en ambas aplicaciones.

Resultado: el nombre completo sigue la dirección que aporta Attacus. El cliente con el sufijo configurado puede utilizar el nombre corto de acuerdo con su búsqueda DNS. La continuidad de las POL y la política de envío de métricas son independientes de esa elección de nombre.

Sigue el ciclo DDNS completo para realizar el alta y la configuración.

Anunciar un servicio según su disponibilidad

Necesidad: los usuarios utilizan portal, pero su nombre de servicio debe seguir el estado del servicio real.

Separar los dos registros

El CNAME de portal apunta al nombre completo equipo-01.oficina.empresa.example.. El punto final identifica el destino absoluto en este ejemplo.

Esquema conceptual

Dos registros, dos responsabilidades

• 01
  Attacus → registro del equipo

  equipo-01 · DDNS: mantiene la dirección IP del equipo.

• 02
  Monitor → acción DNS

  portal · CNAME de categoría Acción: sigue el estado del servicio y apunta al nombre del equipo.

Son dos caminos complementarios. Un cambio de IP actualiza el DDNS; la disponibilidad del servicio gobierna el anuncio del CNAME.

Configuración

1. Prepara el registro DDNS del equipo siguiendo la receta anterior.

2. Crea el CNAME portal, categoría Acción, y asigna su rol lógico.

3. Crea un monitor TCP para el servicio que quieres comprobar, usando el nombre completo del equipo y su puerto.

4. Comprueba que la instalación que ejecuta el monitor resuelve la zona y alcanza ese destino.

5. Crea una acción DNS Seguir estado activo de monitor sobre el CNAME.

6. Enlázala al monitor con Apertura de alerta y Cierre de alerta.

7. Prepara el estado inicial y activa acción y enlace.

Resultado: el agente sigue manteniendo el nombre del equipo. El servicio se anuncia según la supervisión elegida y los clientes pueden seguir usando portal con el sufijo de su red.

El monitor comprueba el alcance de su tipo: un TCP comprueba la conexión configurada. Si la decisión necesita otros criterios, utiliza la receta de condiciones combinadas.

Consulta Acciones DNS para preparar la operación y los eventos del enlace.

Acceso público con una dirección variable

Necesidad: un nombre público debe seguir la dirección del punto de acceso de una sede o de un equipo.

Preparación fuera del portal

Utiliza un dominio que controles, prepara su delegación hacia los servidores autoritativos y haz accesibles tanto el DNS como el servicio que utilizarán los clientes. El nombre anunciado debe resolver a una dirección alcanzable desde ellos.

Publicar en BIND aplica la zona; la delegación y la entrada de red se preparan en la infraestructura. Consulta qué es un NS público.

Composición

1. Prepara un A de categoría DDNS, por ejemplo sede-a.acceso.empresa.example, y concédelo a Attacus.

2. Elige observado cuando la dirección que ve Sentinelia en la POL sea la adecuada para ese acceso. Elige declarado cuando deba aportarla una conexión del equipo.

3. Prepara el nombre de servicio, por ejemplo soporte.empresa.example, como CNAME de categoría Acción hacia el nombre DDNS.

4. Supervisa la condición que determina si ese acceso debe anunciarse.

5. Aplica una acción DNS sobre el nombre de servicio y configura sus eventos.

Resultado: DDNS mantiene el punto de destino; la supervisión gobierna su anuncio. Un cambio de IP y un fallo del servicio generan decisiones diferentes dentro de la misma composición.

La dirección observada depende del camino de comunicación entre Attacus y Sentinelia. Comprueba que corresponde al acceso que quieres anunciar: puede ser una dirección local o una de salida, según la topología. El DNS no configura por sí mismo el acceso al servicio a través de esa red.

Anunciar el servicio con varias condiciones

Necesidad: el portal debe anunciarse cuando el servicio responda y la operación esté autorizada, por ejemplo fuera de una ventana de mantenimiento.

Preparar las entradas

• A · Servicio TCP: disponible cuando la comprobación del servicio es correcta.

• B · Operación permitida: monitor de telemetría cuya condición normal significa que el servicio puede utilizarse. Si el agente publica una señal de mantenimiento, define como normal que el mantenimiento esté desactivado.

Las letras representan la disponibilidad de los monitores, no los valores brutos de las señales. Una señal mantenimiento = falso puede dar lugar a un monitor B disponible.

Esquema conceptual

¿Cuándo se permite anunciar el portal?

Lee de arriba abajo. Las tarjetas son entradas independientes; las flechas muestran cómo se combinan, no un orden de ejecución.

01 · Qué representa cada letra

• AServicio TCP disponible

  La comprobación del servicio es correcta.

• BOperación permitida

  La condición normal del monitor de telemetría permite utilizar el servicio; por ejemplo, mantenimiento desactivado.

↓

02 · Regla del monitor lógicoA AND B

El servicio tiene que responder y estar permitido usarlo.

↓

03 · Qué significa la salida

Objetivo: anunciar el nombre del servicio

Los eventos del lógico activan la acción DNS sobre el CNAME del servicio.

DDNS mantiene la dirección del equipo por separado. El cambio de publicación y su percepción por los clientes no son inmediatos.

Alcance de este ejemplo

Las letras tienen el significado de esta receta. Se muestran entradas locales habilitadas y ya evaluadas; el esquema no simula retardos, estados iniciales ni dependencias pendientes.

Composición

1. Configura los dos monitores y su estabilidad.

2. Crea un monitor lógico con entradas A y B y expresión A AND B.

3. Vincula al monitor lógico una acción Seguir estado activo de monitor sobre el nombre de servicio.

4. Selecciona apertura y cierre de alerta en el enlace.

5. Revisa el estado inicial del registro y habilita la composición.

Resultado: la configuración expresa una política: «anunciar el servicio cuando responde y está permitido usarlo». Puedes ampliar sus entradas con otras comprobaciones relevantes para el servicio.

Sigue Monitores lógicos y Telemetría y reglas para preparar las piezas.

Probar esta composición

Cambia las condiciones del ejemplo para ver qué estado de anuncio solicita la política. El nombre DDNS del equipo conserva su propia responsabilidad aunque el registro del servicio quede inactivo.

Simulación de una receta

¿Cuándo se anuncia el portal?

Cambia la disponibilidad y el permiso de operación. El ejemplo muestra el estado deseado; no modifica recursos de tu instalación.

1. 01
   Dirección del equipo · DDNS

   equipo-01.oficina.empresa.example

   192.168.10.40 · declarada desde una conexión local

   El agente mantiene este registro de equipo.
2. 02
   Política del servicio

   A AND B

   Disponible: el servicio responde y su operación está permitida.

   El monitor lógico reúne las dos condiciones.
3. 03
   Acción DNS · nombre del servicio

   portal.oficina.empresa.example

   CNAME → equipo-01.oficina.empresa.example.

   Estado deseado: activo

   La acción sigue las aperturas y cierres de alerta del monitor lógico.

El cliente con el sufijo de la oficina utiliza «portal» según su búsqueda DNS.

La publicación y la renovación de cachés ocurren después. El TTL y las respuestas negativas conservadas influyen en cuándo verá el cambio cada cliente.

Varias alternativas y elección de destino

Para dos nodos, A OR B expresa que al menos uno está disponible. La selección del destino del alias se configura mediante acciones Editar valor y los eventos de los monitores que gobiernan esa decisión.

Esquema conceptual

Disponibilidad de dos alternativas

Lee de arriba abajo. Las tarjetas son entradas independientes; las flechas muestran cómo se combinan, no un orden de ejecución.

01 · Qué representa cada letra

• ANodo primario preparado

  Monitor que reúne las condiciones de disponibilidad del nodo primario.

• BNodo secundario preparado

  Monitor que reúne las condiciones de disponibilidad del nodo secundario.

↓

02 · Regla del monitor lógicoA OR B

Hay disponibilidad mientras quede al menos una alternativa preparada.

↓

03 · Qué significa la salida

Existe al menos una alternativa

La elección del destino se configura aparte, con condiciones y acciones DNS explícitas.

A y B son nodos en esta receta. La tabla siguiente define la preferencia por A; esa preferencia no está incluida en OR.

Alcance de este ejemplo

Las letras tienen el significado de esta receta. Se muestran entradas locales habilitadas y ya evaluadas; el esquema no simula retardos, estados iniciales ni dependencias pendientes.

Define primero la política de destino:

Esta tabla ayuda a diseñar condiciones lógicas y acciones explícitas. La salida de OR decide disponibilidad; el destino configurado del alias decide a qué nombre se dirige el cliente. Una política de preferencia o de retorno al primario necesita expresar también esa segunda decisión.

Cuando combines varios enlaces, revisa su orden, sus eventos y qué atributo del registro modifica cada acción. El orden de un enlace organiza sus ejecuciones; no convierte distintos monitores en una única decisión indivisible.

Inicialización y tiempos del cambio

Prepara el valor y el estado inicial del registro antes de activar los enlaces. Guardar una acción o un vínculo no la ejecuta de inmediato: la ejecución depende de los eventos configurados.

Hay varios tiempos en la composición: obtención de la dirección, envío del agente, evaluación del monitor, espera o estabilidad, ejecución de la acción, aplicación DNS y renovación de cachés. Configura cada uno pensando en la rapidez y estabilidad que necesita tu servicio.

Desactivar el registro retira ese anuncio cuando se aplica la publicación. Los clientes pueden conservar respuestas anteriores, y también respuestas negativas, durante sus plazos de caché. Una conexión existente con la aplicación no termina por retirar el nombre del DNS. Consulta publicación y caché.

Llevar una receta a tu entorno

Elige quién resolverá el nombre, qué componente mantiene la dirección y qué condición decide su anuncio. Configura los nombres de equipo y servicio, prepara sus valores iniciales y recorre los estados de tu política antes de habilitarla para sus usuarios.

Las recetas se pueden aplicar en un DNS interno o en un dominio público. Cambian la preparación de red y los clientes; las piezas de observación, interpretación y acción mantienen su papel dentro de Sentinelia.