Incidents automatiques

Servor peut ouvrir un incident à votre place dès qu'un moniteur détecte une panne, pour que votre page de statut et vos abonnés soient informés d'un problème sans que personne ne touche un clavier. Cette page explique comment les incidents automatiques se déclenchent, à quoi ils ressemblent et comment les régler pour obtenir du signal, pas du bruit.

Les incidents automatiques s'appuient sur vos moniteurs et vos alertes. Si vous préférez annoncer un problème vous-même, vous pouvez toujours signaler un incident manuellement.

Fonctionnement

Lorsqu'un moniteur passe hors service, Servor peut ouvrir automatiquement un incident rattaché à ce moniteur. Le déclencheur est le changement de statut — le passage de up (ou degraded) à down — et non chaque vérification en échec, pour qu'un simple à-coup ne vienne pas inonder votre chronologie.

Incidents automatiques ou manuels

Les deux types d'incident cohabitent au même endroit et se comportent de façon identique une fois ouverts : vous publiez des mises à jour et les résolvez de la même manière. La différence tient à qui les ouvre, et pourquoi.

	Automatique	Manuel
Ouvert par	Le passage hors service d'un moniteur	Une personne
Idéal pour	Les pannes détectables par un moniteur (un endpoint, un port, un certificat)	Les problèmes que vous connaissez d'abord, ou qu'aucun moniteur ne surveille
Premier message	Généré à partir du moniteur	Rédigé par vous
Rapidité	Immédiat, sans intervention	Aussi vite que vous tapez

Une configuration saine combine généralement les deux : les moniteurs attrapent les pannes qu'ils peuvent voir, et vous signalez le reste à la main — une dépendance tierce dégradée, un changement planifié qui tourne mal, un problème remonté par un client avant que vos moniteurs ne le voient.

Garder un signal propre

Les incidents automatiques ne valent que ce que valent les moniteurs qui les alimentent. Un moniteur instable donne un flux d'incidents instable.

• Réglez le moniteur, pas l'incident. Si vous recevez des incidents pour des pannes qui n'en sont pas, la correction se fait à la source : ajustez l'intervalle de vérification, le délai d'expiration ou les seuils du moniteur. Voir les bonnes pratiques de supervision. Ouvrir vos moniteurs dans Servor
• Liez le bon composant. Pointez chaque moniteur vers le composant qui représente ce que vivent réellement les utilisateurs, pour que le statut public colle à la réalité.
• Surveillez « dégradé », pas seulement « hors service ». Un moniteur qui bascule directement en down raconte une histoire abrupte. Bien comprendre le statut d'un moniteur aide à décider ce qui doit devenir un incident.
• Routez aussi les alertes. Incidents automatiques et alertes sont complémentaires : l'incident prévient vos utilisateurs, l'alerte prévient votre équipe. Configurez vos canaux de notification pour que les bonnes personnes soient alertées pendant que la page de statut se met à jour toute seule. Configurer les alertes dans Servor

Automatiser avec vos propres outils

Si vous disposez d'un système d'alerte hors de Servor, vous pouvez ouvrir et mettre à jour des incidents via l'API plutôt que de vous reposer sur les moniteurs — utile quand le signal vient d'un système que Servor ne surveille pas. Cette voie nécessite le scope incidents:write ; voir l'API Incidents.

Voir aussi