Depannage

Une alerte manquante ne produit aucune erreur dans l’interface. Suivez la liste de controle, puis confirmez avec le journal de l’Integrator et un moniteur de test.

Liste de controle : aucune alerte recue

  1. L’onglet Actions du moniteur. Le declencheur (On fail / On change) est-il actif pour ce canal ? La carte affiche-t-elle un avertissement (switched off on integrator, Email notifications are unavailable, destination vide sans defaut) ? Voir Ce que le formulaire du moniteur indique.
  2. L’Integrator. Clic droit → edit server → Notifications : le meme declencheur est-il actif pour le canal ? Est-ce bien l’Integrator qu’utilise la sonde du moniteur (sonde → Integrators & notification resilience) ?
  3. La regle. ON FAIL exige after x checks + 1 controles en echec consecutifs au niveau choisi ou au-dessus, et s’arrete apres for x checks alertes. Un moniteur en MAJOR ne declenche jamais une regle critical ou pire. Voir ON FAIL et ON CHANGE.
  4. L’anti-rebond. Avec Debounce status-change alerts actif sur la sonde, un changement bref n’est jamais notifie.
  5. Les composants tournent. La sonde et l’Integrator sont demarres et la sonde atteint l’Integrator : le controle apparait sur la page Events.
  6. Le fournisseur. Cliquez sur ⚡ sur la carte du canal dans le bloc Notifications de l’Integrator : la reponse nomme le probleme. Ou testez la destination seule : Email, Slack, Teams, PagerDuty, SIGNL4, script.

Lire le journal de l’Integrator

Le journal est log/integrator.log dans le dossier d’installation de l’Integrator. Passez Log Level en debug dans les parametres de l’Integrator (Application Logs) le temps de l’analyse, puis revenez en arriere.

Ligne Ce qu’elle indique
handleSetSetting - notification flags: emailOnF=true emailOnSC=false slackOnF=... smtpEnabled=true Les interrupteurs de l’Integrator, journalises a chaque enregistrement de ses parametres.
handleNotifications - [<moniteur>] emailIntFlag=true smtpEnabled=true emailRecipient=... emailMonFlag=true alertingFlag=false Decision email pour un controle. alertingFlag=false : la regle ON FAIL n’est pas satisfaite pour ce controle. emailRecipient= vide : ni destination ni defaut.
sendMsgSlack - [<moniteur>] Success: alert sent (aussi sendAlertEmail, sendMsgTeams, sendMsgPagerDuty) Envoye.
... - attempt 1/3 failed: <erreur>, retrying in 1s Le fournisseur a refuse ou etait injoignable ; l’erreur est celle du fournisseur.
... - all 3 attempts failed: <erreur> Abandon pour l’instant ; la notification part dans le tampon de nouvelles tentatives.
runCommand - ... Rejected invalid script name / Script not found / timeout occured Problemes de script personnalise : voir Script personnalise.

Le tampon de nouvelles tentatives

Une notification en echec apres 3 essais est enregistree comme fichier dans le dossier notif_buffer de l’Integrator et retentee toutes les 30 secondes pendant une heure ; une alerte plus recente pour le meme moniteur et le meme canal la remplace. Des fichiers qui restent la signifient que la destination refuse toujours : lisez l’erreur dans le journal. Apres une heure, la notification est abandonnee. Les scripts ne passent jamais par le tampon.

Test de bout en bout avec un moniteur en echec

Un moniteur jetable toujours en echec valide toute la chaine : sonde → Integrator → fournisseur.

  1. Ajoutez un moniteur URL nomme notif-test, sur une sonde routee par l’Integrator a tester, avec l’URL https://notif-test.invalid/ (le domaine .invalid ne se resout jamais) et une planification d’une minute.
  2. Dans son onglet Actions, reglez la regle sur error, after 1 check, for 1 check, et activez On fail et On change pour le canal teste. Laissez la destination vide pour tester le defaut de l’Integrator, ou renseignez-la.
  3. Enregistrez. Verifiez que la carte du canal n’affiche aucun avertissement.
  4. En deux minutes environ, vous recevez une alerte On fail, intitulee [ERROR] notif-test, au deuxieme controle en echec, puis plus rien (for 1 check). Aucune alerte On change n’arrive au debut : le premier statut d’un nouveau moniteur n’est pas un changement.
  5. Supprimez le moniteur une fois termine.

Si rien n’arrive, suivez la liste de controle ci-dessus avec le nom de moniteur notif-test.

Trop d’alertes

Symptome Cause et action
Une alerte par controle tant qu’un moniteur est en panne ON FAIL avec for 0 checks (illimite). Reglez for N checks.
Chaque alerte arrive deux fois La sonde liste deux Integrators et les deux ont le canal actif, ou ON FAIL et ON CHANGE se sont declenches sur le meme controle (deux alertes differentes).
Alertes pour un moniteur qui oscille Activez Debounce status-change alerts sur la sonde, augmentez after x checks, ou revoyez les seuils du moniteur.
Alertes pendant une intervention planifiee Declarez un arret programme.

Notes de version

Les destinations par defaut de l’Integrator et l’envoi d’un canal laisse vide sur un moniteur exigent une sonde et un Integrator en version 4.2.0 ou ulterieure. Avec une sonde plus ancienne, un moniteur dont la destination est vide ne demande jamais l’envoi a l’Integrator : renseignez la destination sur le moniteur, ou mettez la sonde a jour.

La version 4.3.0 apporte : les boutons de test ⚡, PagerDuty sur Events API v2 (une cle Events API V1 doit etre remplacee, voir PagerDuty) et sa resolution avec On fail seul, les arguments et variables MNS_* des scripts sur l’Integrator, le delai de repli de 30 secondes des scripts, et un nouveau moniteur qui attend after x checks + 1 controles avant sa premiere alerte ON FAIL. Chacune demande la mise a jour du composant concerne (Webserver pour les boutons ; Integrator, sondes et Sentinel agents pour l’envoi).

Traductions