Contexte enrichi & preuves d'impact
Introduction
Section titled “Introduction”Gward capture automatiquement le contexte technique au moment exact d’un incident. Ces données sont figées à la création de l’impact et historisées pour garantir une traçabilité complète, même après résolution du problème.
Preuves d’impact
Section titled “Preuves d’impact”Chaque impact conserve les informations suivantes :
| Donnée | Description |
|---|---|
triggerStdout |
Sortie standard réelle du script ayant déclenché le problème |
triggerStderr |
Sortie d’erreur du script au moment du déclenchement |
checkEntries |
Résultats des scripts de contexte configurés sur le check (voir ci-dessous) |
startedAt |
Horodatage de la première détection de l’impact |
lastSeenAt |
Horodatage de la dernière vérification en échec |
resolvedAt |
Horodatage de résolution (si l’impact est résolu) |
Ces données sont accessibles depuis la vue d’une alerte, onglet Agents, via le bouton Contexte sur chaque impact (visible si triggerStdout ou triggerStderr est présent).
Scripts de contexte enrichi
Section titled “Scripts de contexte enrichi”L’onglet Contexte du check permet d’ajouter des scripts complémentaires qui s’exécutent automatiquement lors d’un incident. Leur résultat est capturé dans checkEntries et conservé avec l’impact pour faciliter le diagnostic.
Configuration d’une entrée de contexte
Section titled “Configuration d’une entrée de contexte”Chaque entrée contient deux champs :
| Champ | Description |
|---|---|
label |
Nom descriptif de l’information capturée (ex: État du service, Logs nginx) |
script |
Script exécuté sur l’agent pour collecter l’information |
Vous pouvez ajouter autant d’entrées que nécessaire via le bouton + Ajouter une entrée de contexte.
Types de données récupérables
Section titled “Types de données récupérables”| Type | Exemples de scripts |
|---|---|
| État des services | systemctl is-active nginx, systemctl status postgresql |
| Processus | `ps aux –sort=-%cpu |
| Logs | tail -n 20 /var/log/nginx/error.log |
| Informations système | df -h, free -m, uptime |
| Données métier | Requêtes SQL, métriques applicatives, files de messages |
Exemple d’entrées de contexte
Section titled “Exemple d’entrées de contexte”| Label | Script |
|---|---|
Services en échec |
systemctl list-units --state=failed |
Utilisation disque |
df -h |
Mémoire disponible |
free -m |
Derniers logs nginx |
tail -n 20 /var/log/nginx/error.log |
Moment de capture
Section titled “Moment de capture”Le contexte (checkEntries) est capturé à la création de l’impact, c’est-à-dire lors du premier résultat failing qui ouvre l’impact. Les triggerStdout et triggerStderr sont quant à eux mis à jour à chaque nouveau résultat failing pour refléter l’état courant.
Utilisation des preuves
Section titled “Utilisation des preuves”Les preuves d’impact permettent :
- de comprendre l’état exact du système au moment du problème
- de diagnostiquer la cause racine sans avoir à reproduire l’incident
- de constituer un dossier d’audit complet
- de rejouer la timeline d’un incident