Configurar una notificación

Traducción automática del original francés.

Todo lo que necesita para notificar a alguien, se envía como un único JSON al enrutador. Este lo dirige a dos destinos: la mensajería del equipo y la mensajería móvil. Un emisor no conoce ninguno de los dos — el enrutador es quien tiene la información, y es así como se puede añadir o eliminar un destino sin modificar ningún emisor.

flowchart LR
    e["Émetteur<br/>script · cron · service · workflow"]
    h["Répartiteur<br/>service systemd, 24/7"]
    z["Messagerie d'équipe"]
    t["Messagerie mobile"]

    e -->|"POST JSON"| h
    h -->|"synchrone<br/>décide le code de retour"| z
    h -.->|"file asynchrone<br/>reprise sur limitation de débit"| t
    e -.->|"repli, seulement si le répartiteur ne répond pas"| z

El mecanismo

curl -s -X POST http://<répartiteur>:8099/alerts-notify \
  -H 'Content-Type: application/json' \
  -d '{"channel":"general","title":"mon titre","message":"mon message"}'

Eso es todo. Tres campos, de los cuales solo uno es obligatorio en la práctica: message.

Campo	Función
channel	Selecciona el destino. Si está vacío o desconocido, se recurre a general, se registra y se informa en la respuesta
title	Se convierte en el asunto del mensaje en la mensajería del equipo — ver la trampa nº2
message	El cuerpo
format: "raw"	Fuerza un bloque de código para una salida de comando

Lo que no se debe hacer

• No la URL pública del motor de flujos de trabajo. Funciona — es una fachada que retransmite — pero añade dos componentes al camino de una notificación. Un nuevo emisor apunta directamente al enrutador.
• No la mensajería del equipo en directo, excepto para el mecanismo descrito más abajo. Un emisor que la apunta directamente nunca llega a la mensajería móvil, por lo que nunca llega a un teléfono, y por lo tanto, nunca llega a nadie fuera de la oficina.
• No un webhook escrito a mano. El mecanismo compartido resuelve cuatro trampas que no se pueden predecir, y todas son silenciosas.

El mecanismo

El enrutador devuelve 200 cuando la mensajería del equipo ha recibido el mensaje, y 502 si no. Este 502 es la señal: es lo que desencadena el mecanismo del emisor, enviando directamente a la mensajería del equipo.

El mecanismo existe para un único caso: el enrutador no responde. No llega a la mensajería móvil — esta solo es accesible a través del enrutador.

Dos mecanismos, y la elección no es negociable:

El emisor…	Mecanismo
gira desde el punto de entrega de notas	import del módulo compartido
está fuera del punto de entrega o se encuentra en un contenedor	copia del bloque compartido

La razón del segundo caso no es por comodidad: un import desde una red compartida pondría este compartimento en la ruta de alerta. Servidor de archivos ausente ⇒ el script muere antes de intentar, y también se pierde la ruta que habría funcionado.

Un repliegue no probado es uno en el que se supone que funciona

Solo funciona cuando el distribuidor falla — es decir, cuando nadie lo está mirando. Probarlo significa cortar la ruta principal, en el host correspondiente, y comprobar que el mensaje llega de todos modos.

Y también probar que falla: vaciar todas las fuentes de clave, no solo una. Una prueba negativa que pasa por una mala razón es peor que una prueba ausente.

Registrar el emisor — no negociable

Un emisor que no está en el manifiesto nunca se actualiza cuando el bloque compartido evoluciona. Continuará funcionando, con la versión del día en que se instaló, hasta que una corrección que no ha recibido realmente entre en juego.

Dos archivos, en la misma sesión que la instalación:

• el manifiesto de las copias que deben mantenerse actualizadas;
• el inventario de los emisores, regenerado mediante el escaneo de todos los hosts.

El inventario es la única vista que encuentra lo que nadie ha declarado. Así se descubrieron cuatro copias divergentes de un mismo watchdog, de las cuales solo una figuraba en el manifiesto.

El inventario dice qué menciona una dirección, no qué emite

Clasifica por búsqueda de patrones. No sabe si el archivo se ejecuta. Una medida del 2026-09 identificó cinco "emisor" de una categoría, de las cuales dos eran código muerto — su ruta de destino no existía en ninguna máquina. Este falso positivo lleva a la acción: "¡Estos emisores están fuera del enrutador, colócalos!". Colocar código inerte produce una tarjeta que parece completa y que describe un script que no se ejecuta.

Antes de actuar sobre una línea de la lista, buscar el remitente: cron, temporizador, servicio, o cualquier otro script.

Los cuatro peligros

1. Un código HTTP 200 no establece una respuesta

Varias API encapsulan sus errores en un cuerpo success: false bajo un 200. Una comprobación de la forma curl -o /dev/null -w '%{http_code}' responde entonces a "el servidor web está activo", pero nunca a "la llamada ha tenido éxito". El bloque compartido lee el cuerpo y rechaza un 200 que no sea JSON.

Esto permitió, en 2026-09, determinar que una dirección histórica estaba muerta desde hace tres semanas: respondía con 200 a todo, con un código de error "esta API no existe" en el cuerpo.

2. El título es un identificador de hilo

En el ámbito de la mensajería de equipo, title se convierte en el asunto. Un título con marca de tiempo crea un nuevo hilo cada vez que se envía — 48 hilos por día para un emisor que se ejecuta cada media hora.

El título contiene la identidad del emisor; lo que varía va en message. Un título que varía en una entidad (🔴 CRITICAL — <conteneur>) es legítimo: proporciona un hilo por contenedor, lo que queremos.

3. Una protección sobre un token muerto neutraliza el retroceso

El patrón, encontrado en siete archivos de cuatro hosts en 2026-09:

poster_sur_le_repartiteur "$1" && return 0
[ -n "${JETON_D_UNE_DESTINATION_MORTE:-}" ] || return 0   # ← ici
repli_direct "$1"

El sistema de supervisión prueba el token de una ubicación deshabilitada para permitir un retorno, mientras que este último apunta a una ubicación activa. Dado que el token ya no existe, la función devuelve 0 sin intentar nada: parece un éxito, pero la alerta se pierde, precisamente el día en que falla el distribuidor.

Daño medido en una de estas sondas: 18 alertas detectadas, incluyendo la falla de un dispositivo, que fue detectada, decidida y nunca anunciada.

No fue un olvido

La corrección se aplicó a dos de los seis archivos, y nunca se propagó. Una corrección que no se aplica en todos los lugares donde existe el problema es una corrección que se cree que existe.

4. Una supervisión por ventana horaria supera su propósito

Algunas sondas HOUR_START / HOUR_END estaban diseñadas para que dos máquinas descansaran durante la noche. Ya no descansan. La supervisión, en cambio, ha permanecido — y ha eliminado alertas reales durante la migración.

Supervisar la causa, nunca el momento. Una falla se diagnostica; no se explica de antemano en el momento en que ocurre.

Activar una nueva alerta

Una alerta conectada a un sistema que ya está en funcionamiento primero revisa todo el inventario.

1. Medir el volumen que produciría la regla, durante un período representativo, antes de activar la alerta.
2. Ajustar el umbral en función de este historial; de lo contrario, se mide la frecuencia del instrumento, no el estado del parque.
3. Establecer una fecha de activación: lo que existía antes no es un evento.
4. Establecer una histeresis y una duración de serie. Una alerta que se repite exactamente no dice nada más que la primera.

Verificar

# 1. le répartiteur répond
curl -s http://<répartiteur>:8099/health

# 2. le chemin nominal — lire les destinations dans la RÉPONSE, pas le code HTTP
curl -s -X POST http://<répartiteur>:8099/alerts-notify \
  -H 'Content-Type: application/json' \
  -d '{"channel":"general","title":"probe","message":"test"}'

# 3. le repli — celui qu'on oublie, et le seul qui compte la nuit

/health también revela la profundidad de la cola de la mensajería móvil. Esta cola existe porque este destino impone limitaciones de velocidad: esperar a que la solicitud entrante se procese, en septiembre de 2026, suponía la pérdida de 2.295 mensajes en quince días en una recuperación que, de hecho, estaba correctamente escrita, pero que se veía afectada por una constante demasiado baja.

Lo que cuesta esta cola y lo que hay que vigilar

Un fallo en este destino ya no es visible para el remitente: solo aparece en el registro y en la profundidad de la cola. Sin un monitor en esta profundidad, hemos sustituido una pérdida ruidosa por una pérdida silenciosa.

Lo que no debe pasar por el enrutador

• Los sensores fuera de banda, que existen para comunicarse cuando la red está inactiva. Deben llegar a un teléfono sin atravesar la infraestructura supervisada.
• Los puentes de conversación — permitir la comunicación con un asistente desde una mensajería no es una notificación, sino un transporte bidireccional.
• El correo electrónico para usuarios finales.

Dernière vérification de cette page : 2026-09-09