Configurare una notifica

Traduzione automatica dell'originale francese.

Ogni elemento che deve avvisare qualcuno invia un unico JSON al gestore. Questo lo indirizza a due destinazioni: la messaggistica di gruppo e la messaggistica mobile. Ogni emettitore non conosce l'una né l'altra — è il gestore a gestire la connessione, e questo permette di aggiungere o rimuovere una destinazione senza modificare alcun emettitore.

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

Il meccanismo

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

Questo è tutto. Tre campi, di cui solo uno è obbligatorio in pratica: message.

Campo	Funzione
channel	seleziona la destinazione. Se assente o sconosciuta, si ricorre a general, viene registrato e segnalato nella risposta
title	diventa l'oggetto del messaggio nella messaggistica di gruppo — vedere il punto 2
message	il corpo
format: "raw"	forza l'esecuzione di un blocco di codice per l'invio di un comando

Cosa evitare

• Non l'URL pubblico del motore di workflow. Funziona, è una sorta di interfaccia che reindirizza, ma aggiunge due componenti al percorso di una notifica. Un nuovo emettitore invia il messaggio direttamente al gestore.
• Non la messaggistica di gruppo, a meno che non si utilizzi il meccanismo descritto più in basso. Un emettitore che la invia direttamente non raggiunge mai la messaggistica mobile, quindi non raggiunge mai un telefono, e quindi non raggiunge mai nessuno al di fuori dell'ufficio.
• Non un webhook scritto a mano. Il meccanismo di fallback condiviso risolve quattro potenziali problemi, e tutti e quattro sono silenziosi.

Il meccanismo di fallback

Il gestore risponde con 200 una volta che la messaggistica di gruppo ha ricevuto il messaggio, e con 502 altrimenti. Questo 502 è il segnale: è ciò che innesca il meccanismo di fallback dell'emettitore, reindirizzando direttamente verso la messaggistica di gruppo.

Il meccanismo di fallback esiste per un solo caso: il gestore non risponde. In questo caso, il messaggio non raggiunge la messaggistica mobile — questa è raggiungibile solo tramite il gestore.

Due meccanismi, e la scelta è inequivocabile:

L'emettitore…	Meccanismo
gira dopo la creazione dei messaggi	import dal modulo condiviso
è fuori dal modulo condiviso o si trova in un contenitore	copia del blocco condiviso

La ragione del secondo caso non è il comfort: un import da una rete condivisa metterebbe questo blocco sul percorso di allerta. Assenza del server di file ⇒ lo script termina prima di tentare, e si perde anche il percorso che avrebbe funzionato.

Un percorso non testato è un percorso che si presume funzioni

Funziona solo quando il distributore è inattivo — ovvero, quando nessuno lo controlla. Testare significa interrompere il percorso principale, sull'host specifico, e constatare che il messaggio arriva comunque.

E testare anche che fallisca: svuotare tutte le fonti di chiave, non solo una. Un test negativo che passa per un motivo sbagliato è peggiore di un test assente.

Registrare l'emettitore — inamovibile

Un emettitore che non è presente nel manifesto non viene mai aggiornato quando il blocco condiviso evolve. Continuerà a funzionare, con la versione del giorno in cui è stato installato, fino a quando un aggiornamento che non ha ricevuto non avrà effettivamente effetto.

Due file, nella stessa sessione di installazione:

• il manifesto delle copie da mantenere aggiornate;
• l'inventario degli emettitori, generato da uno scan di tutti gli host.

L'inventario è l'unico che trova ciò che nessuno ha dichiarato. È così che sono stati scoperti quattro esemplari diversi dello stesso watchdog, di cui uno solo era presente nel manifesto.

L'inventario indica a quale destinazione si invia, non a quale si emette

Il utilizza la ricerca di pattern. Non sa se il file viene eseguito. Una misurazione effettuata il 2026-09 ha rilevato cinque "emittenti" di una categoria, di cui due erano codice morto — il loro percorso di destinazione non esisteva su nessuna macchina. Questo falso positivo porta all'azione: "Questi emittenti non sono nel router, allinea". Allineare codice inerte produce una mappa che appare completa e descrive uno script che non viene eseguito.

Prima di agire su una riga dell'inventario, cercare l'origine: cron, timer, servizio, o un altro script.

I quattro pericoli

1. Un codice HTTP 200 non stabilisce una risposta

Molte API incapsulano i loro errori in un corpo success: false sotto il codice 200. Un controllo della forma curl -o /dev/null -w '%{http_code}' risponde quindi a "il server web è attivo", mai a "la chiamata ha avuto successo". Il blocco condiviso legge il corpo e rifiuta un 200 non-JSON.

Questo ha permesso, nel 2026-09, di stabilire che una destinazione storica era morta da tre settimane: rispondeva con 200 a tutto, con un codice di errore "questa API non esiste" nel corpo.

2. L'oggetto è un identificatore di thread

Nel contesto della messaggistica di team, title diventa l'oggetto. Un oggetto con timestamp crea un nuovo thread ogni volta che viene inviato — 48 thread al giorno per un emettitore che gira ogni mezz'ora.

L'oggetto porta l'identità dell'emettitore; ciò che varia va in message. Un oggetto che varia su un'entità 🔴 CRITICAL — <conteneur> è legittimo: fornisce un thread per contenitore, che è ciò che vogliamo.

3. Una guardia su un token morto neutralizza il rollback

Il pattern, trovato su sette file di quattro host nel 2026-09:

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

Il sistema di monitoraggio verifica la validità di un token per una destinazione disattivata, al fine di consentire un ripristino. Questo ripristino, invece, è diretto verso una destinazione ancora attiva. Poiché il token non è più valido, la funzione restituisce 0 senza tentare nulla: un risultato apparentemente positivo, ma senza alcun avviso, proprio nel momento in cui il dispositivo smette di funzionare.

Danni rilevati su una sola di queste sonde: 18 avvisi ignorati, tra cui il malfunzionamento di un dispositivo, che è stato rilevato, risolto e mai segnalato.

Non si trattava di un errore

La correzione è stata applicata a due file su sei, e non è stata propagata. Una correzione che non viene applicata ovunque dove esiste il problema, è una correzione che si crede di aver fatto.

4. Un sistema di monitoraggio per ogni intervallo orario sopravvive al suo scopo

Alcune sonde HOUR_START / HOUR_END erano presenti perché due macchine erano inattive durante la notte. Ora non lo sono più. Il sistema di monitoraggio, invece, è rimasto attivo — e ha eliminato falsi avvisi durante i periodi di migrazione.

Concentrarsi sulla causa, non sull'ora. Un guasto viene diagnosticato; non si può prevedere quando si verifica.

Attivare un nuovo avviso

Un avviso attivato su un sistema già in funzione, prima di tutto verifica lo stato attuale.

1. Misurare il volume che l'apparecchio produrrebbe, su un periodo rappresentativo, prima di attivare l'avviso.
2. Impostare il limite in base a questo storico — altrimenti si misura la frequenza dell'apparecchio, non lo stato del sistema.
3. Definire una data di attivazione: ciò che esisteva prima non è un evento.
4. Definire un limite di isteresi e una durata. Un avviso che si ripete esattamente allo stesso modo non fornisce ulteriori informazioni rispetto al primo.

Verificare

# 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 evidenzia anche la profondità della coda del servizio di messaggistica mobile. Questa coda esiste perché questa destinazione impone dei limiti di banda: far aspettare il messaggio in attesa comportava, nel 2026-09, 2.295 messaggi persi in quindici giorni anche in un caso in cui la richiesta era correttamente scritta, ma era stata interrotta da un ritardo di una sola seconda.

Cosa costa questa coda e cosa bisogna monitorare

Un errore su questa destinazione non è più visibile per l'emittente: compare solo nel log e nella profondità della coda. Senza un monitoraggio di questa profondità, abbiamo sostituito un errore rumoroso con un errore silenzioso.

Cosa non deve passare attraverso il router

• I sensori fuori banda, che esistono per comunicare quando la rete è inattiva. Devono raggiungere un telefono senza attraversare l'infrastruttura monitorata.
• I ponti di conversazione – consentire di dialogare con un assistente tramite messaggistica non è una notifica, ma un trasporto bidirezionale.
• La posta elettronica destinata a un utente finale.

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