Een notificatie instellen

Machinevertaling van het Franse origineel.

Elk element dat iemand moet waarschuwen, stuurt één JSON naar de router. Deze router stuurt het naar twee bestemmingen: de team-e-mail en de mobiele e-mail. Een uitzender kent geen van beide — de router heeft de informatie, en dit maakt het mogelijk om een bestemming toe te voegen of te verwijderen zonder de uitzender te wijzigen.

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

De actie

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

Dat is alles. Drie velden, waarvan er één in de praktijk verplicht is: message.

Veld	Functie
channel	selecteert de bestemming. Als dit ontbreekt of onbekend is, wordt er teruggegrepen naar general, wordt het gelogd, en wordt het gemeld in de reactie
title	wordt het onderwerp van de e-mail aan de kant van de team-e-mail — zie val 2
message	het bericht
format: "raw"	dwingt een codeblok, voor een commando

Wat niet moet gebeuren

• Geen publieke URL van de workflow-engine. Deze werkt — het is een façade die doorstuurt — maar het voegt twee componenten toe aan het pad van een notificatie. Een nieuwe uitzender stuurt direct naar de router.
• Geen directe team-e-mail, behalve voor de fallback zoals hieronder beschreven. Een uitzender die direct naar de team-e-mail stuurt, bereikt nooit de mobiele e-mail, dus nooit een telefoon, dus nooit iemand buiten het kantoor.
• Geen handgeschreven webhook. Het gedeelde fallback-mechanisme lost vier valkuilen op die niet te voorspellen zijn, en alle vier zijn stil.

De fallback

De router stuurt 200 zodra de team-e-mail is ontvangen, 502 anders. Deze 502 is het signaal: het triggert de fallback van de uitzender, direct naar de team-e-mail.

De fallback bestaat voor één situatie: de router reageert niet. Het bereikt de mobiele e-mail niet — deze is alleen bereikbaar via de router.

Twee mechanismen, en de keuze is duidelijk:

De zender…	Mechanisme
draait vanaf de notitie-opslag	import van het gedeelde module
is uitgeplaatst buiten de notitie-opslag of bevindt zich in een container	kopie van het gedeelde module

De reden voor het tweede geval is niet het gemak: een import vanaf een netwerkgedeelte zou dit gedeelte op de waarschuwingsroute plaatsen. Een server voor bestanden ontbreekt ⇒ het script stopt voordat het probeert, en we verliezen ook de route die wel zou werken.

Een ongetest fallback is een fallback waarvan men aanneemt dat het werkt

Het werkt alleen als de zender uitvalt — dat wil zeggen, als niemand er naar kijkt. Het testen betekent de hoofdroute afsnijden, op de betreffende host, en constateren dat het bericht tóch aankomt.

En het ook testen dat het mislukt: alle bronnen van de sleutel legen, niet slechts één. Een negatief testresultaat dat om onverklaarbare redenen slaagt, is slechter dan een afwezig testresultaat.

De zender registreren – onvermijdelijk

Een zender die niet in het manifest staat, wordt nooit bijgewerkt wanneer het gedeelde module verandert. Het blijft functioneren, met de versie van het moment waarop het is geïnstalleerd, totdat een correctie die het niet heeft ontvangen, daadwerkelijk effect heeft.

Twee bestanden, in dezelfde sessie als de installatie:

• het manifest van de kopieën die bijgewerkt moeten worden;
• het inventaris van de zenders, gegenereerd door het scannen van alle hosts.

De inventaris is de enige weergave die vindt wat niemand heeft aangegeven. Zo zijn vier verschillende versies van dezelfde watchdog ontdekt, waarvan er slechts één in het manifest stond.

De inventaris geeft aan waar het naar gestuurd wordt, niet waar het naar gestuurd is

Het sorteert op basis van het patroon. Het weet niet of het bestand wordt uitgevoerd. Een meting op 2026-09 vond vijf "uitzenders" van een categorie, waarvan twee geen werkend code waren – hun doelpad bestond niet op een enkele machine. Dit valse positief leidt tot actie: "Dit zijn uitzenders die niet werken, corrigeer dit". Het uitlijnen van inactieve code produceert een kaart die een script beschrijft dat niet werkt.

Voordat je handelt op een regel in de inventaris, zoek dan de oorzaak: cron, timer, service, of een ander script.

De vier valkuilen

1. Een HTTP 200-statuscode bevestigt geen succes

Meerdere API's verpakken fouten in een body success: false onder een 200. Een controle op de vorm curl -o /dev/null -w '%{http_code}' reageert dan op "de webserver is actief", maar nooit op "de aanvraag is succesvol". De gedeelde component leest de body en weigert een 200 die geen JSON is.

Dit heeft ertoe geleid dat, in 2026-09, werd vastgesteld dat een historische bestemming al drie weken dood was: deze antwoordde met 200 op alles, met een foutmelding "Deze API bestaat niet" in de body.

2. Een titel is een thread-identifier

In de teamcommunicatie title wordt de titel de onderwerp. Een getimede titel creëert een nieuwe thread bij elke verzending – 48 threads per dag voor een uitzender die elke halve uur draait.

De titel bevat de identiteit van de uitzender; dit kan variëren message. Een titel die varieert over een entiteit 🔴 CRITICAL — <conteneur> is legitiem: het creëert een thread per container, wat we willen.

3. Een beveiliging op een dode token neutraliseert het terugtrekken

Het patroon, gevonden op zeven bestanden van vier hosts in 2026-09:

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

De bewakingsfunctie test het token van een ontmantelde bestemming om een terugkeer mogelijk te maken, terwijl de andere bestemming nog actief is. Omdat het token niet meer bestaat, retourneert de functie 0 zonder iets te proberen: een vermeend succes, een verloren melding, precies op het moment dat de router uitvalt.

Schade is gemeten aan één van deze sensoren: 18 meldingen zijn verloren gegaan, waaronder de storing van een host, die is gedetecteerd, hersteld en nooit gemeld.

Dit was geen vergissing

De correctie is toegepast op twee van de zes bestanden, en nooit verspreid. Een correctie die niet overal wordt toegepast waar het probleem zich voordoet, is een correctie die men denkt te hebben.

4. Een bewakingsfunctie per tijdsinterval overleeft zijn doel

Sommige sensoren HOUR_START / HOUR_END omdat er twee machines 's nachts uitgeschakeld waren. Ze zijn nu uitgeschakeld. De bewakingsfunctie blijft echter actief en voorkomt valse meldingen tijdens de migratie.

Focus op de oorzaak, niet op het tijdstip. Een storing wordt gediagnosticeerd; deze kan niet van tevoren worden verklaard op het moment dat deze zich voordoet.

Een nieuwe melding activeren

Een melding die is aangesloten op een systeem dat al draait, bekijkt eerst alle beschikbare gegevens.

1. Meet het volume dat de regel zou produceren, over een representatieve periode, voordat de melding wordt geactiveerd.
2. Stel het drempelwaarde in op basis van deze gegevens — anders meet je de snelheid van het instrument, niet de status van het systeem.
3. Stel een activeringsdatum in: wat er was voordat, is geen gebeurtenis.
4. Stel een hysteresis en een tijdsduur in. Een melding die zich steeds herhaalt, zegt niets nieuws dan de eerste melding.

Controleren

# 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 laat ook de diepte van de wachtrij van de mobiele communicatie zien. Deze wachtrij bestaat omdat dit bestemming bepaalde bandbreedtebeperkingen oplegt: het wachten door de inkomende verzoek kostte in 2026-09 2.295 verloren berichten in vijftien dagen op een correct geschreven herstel, ondanks een constante van slechts één seconde.

Wat de wachtrij kost en waar je op moet letten

Een mislukking op deze bestemming is niet meer zichtbaar voor de afzender: het verschijnt alleen in het logboek en in de diepte van de wachtrij. Zonder een meting op deze diepte, hebben we een lawaaierige fout vervangen door een stille fout.

Wat niet via de router mag gaan

• Externe sensoren, die bestaan om te communiceren wanneer het netwerk uitvalt. Deze moeten een telefoon bereiken zonder de gecontroleerde infrastructuur te hoeven passeren.
• Gespreksbruggen – het mogelijk maken om met een assistent te communiceren vanuit een bericht, is geen notificatie, maar bidirectionele communicatie.
• Toepassingspost voor een eindgebruiker.

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