Règles d'alerte & temporisations
Le principe. Chaque règle observe une métrique, la compare à un seuil, et n'alerte que si la condition persiste (pas un simple à-coup). L'alerte est alors levée, expliquée, puis résolue d'elle-même quand la situation revient à la normale. Les seuils sont lus en direct depuis le moteur de supervision.
Les règles
| Règle | Se déclenche quand… | Sévérité | Portée |
|---|---|---|---|
| Authentification bloquée | les identifiants sont refusés et le disjoncteur d'auth s'arme (connexion suspendue sans marteler Oracle) | Critique | Tous |
| Base injoignable | la base ne répond plus (dernière collecte en échec) | Critique | Tous |
| Score de santé bas | le score passe sous 60 (vigilance) ou sous 40 (critique) | Variable | Tous |
| Note de santé non établie | Deynao cesse de publier une note alors que la base répond : trop de mesures sont inaccessibles pour calculer un score fiable. Tant que la note manque, la règle « Score de santé bas » ne peut plus prévenir pour cette base | Vigilance | Tous |
| Tablespace critique | un tablespace ne peut plus s'étendre (autoextend saturé et disque plein), jamais un simple pourcentage d'occupation | Critique | Tous |
| Sauvegarde à risque | mode ARCHIVELOG désactivé, ou dernière sauvegarde trop ancienne vs la cadence détectée, ou archive logs non sauvegardés (RPO), ou aucune sauvegarde depuis 90 jours | Critique | Production* |
| Zone de récupération pleine | la FRA est occupée à ≥ 90 % par de l'espace non recyclable (risque d'ORA-00257, arrêt de la base) | Critique | Production |
| Sécurité perfectible | l'audit est désactivé, ou le score de sécurité passe sous 30 | Vigilance | Production |
| Tâche planifiée en échec | un job Oracle est cassé (BROKEN, désactivé par Oracle → critique) ou sa dernière exécution a échoué (vigilance) | Variable | Production |
| Collecte en échec | un module de collecte de Deynao est en panne durable (distinct des jobs du client) | Vigilance | Tous |
| Alertes Oracle critiques | au moins une alerte critique est détectée dans l'alert.log | Vigilance | Tous |
Les garde-fous anti-bruit
- Priorité aux causes racines. Si l'authentification est bloquée ou la base injoignable, Deynao ne lève que cette alerte : inutile d'empiler des symptômes sur une base qu'on n'a pas pu sonder.
- Modulation par environnement. Plusieurs règles (sécurité, FRA, jobs, mode ARCHIVELOG) ne valent qu'en production. Un audit perfectible ou des jobs qui cassent au fil du développement ne sont pas des incidents.
- Aucune alerte sur donnée périmée. Un module dont la collecte a échoué ou est périmée ne nourrit aucune règle : pas de « tablespace critique » calculé sur un état d'il y a une heure.
- Des mesures qui jugent la marge réelle. Le tablespace n'alerte que s'il ne peut plus s'étendre ; la FRA se juge sur l'espace non recyclable ; la sauvegarde se compare à la cadence réellement détectée (quotidienne, hebdomadaire, mensuelle).
- Anti-fausse-résolution. Si la donnée d'une alerte active devient indisponible, Deynao la suspend au lieu de la marquer « résolue » à tort : « la donnée a disparu » n'est pas « le problème est réglé ».
- Des seuils volontairement prudents. Deynao démarre peu bruyant, puis se resserre : un alerting qu'on apprend à ignorer est un alerting mort.
Le cycle de vie d'une alerte
- Levée une fois, horodatée, expliquée, avec son action recommandée.
- Rappelée au plus une fois toutes les 24 heures tant qu'elle reste active. Pas de spam.
- Jamais perdue : un envoi e-mail en échec est retenté avec un back-off croissant (30 s → 1 h), sans jamais abandonner, et sans marteler un serveur de messagerie en panne.
- Résolue d'elle-même quand la condition revient à la normale, avec sa durée. La ligne reste consultable dans l'historique.