Surveillez d’abord vos endpoints orientés client
Chaque produit SaaS a des endpoints avec lesquels les utilisateurs interagissent directement. Ce sont votre priorité de surveillance absolue.
Commencez par votre tableau de bord applicatif. Si les utilisateurs se connectent à app.votresociete.com, surveillez cette URL. Ajoutez ensuite votre endpoint d’authentification. Si les utilisateurs ne peuvent pas se connecter, le reste de votre surveillance n’a pas d’importance.
Ajoutez vos endpoints API principaux. Si votre produit a une API REST que les clients intègrent, surveillez les endpoints qu’ils appellent le plus. Un endpoint /v1/health c’est bien, mais il peut retourner 200 alors que vos endpoints de données réels renvoient des erreurs 500. Surveillez les endpoints que vos utilisateurs atteignent réellement.
Ajoutez votre flux de facturation et de paiement. Si les webhooks Stripe ou Paddle cessent d’arriver, ou si votre endpoint de gestion d’abonnement tombe, vous perdez de l’argent. Surveillez les endpoints qui touchent au chiffre d’affaires.
Vérifiez vos tâches en arrière-plan
Votre serveur est en ligne. Votre API retourne 200. Votre tableau de bord se charge. Tout semble aller bien. Mais votre sauvegarde nocturne de base de données échoue silencieusement depuis deux semaines. Votre file d’attente d’e-mails est bloquée avec 8 000 messages non livrés. Votre pipeline d’exportation de données s’est arrêté il y a trois jours.
C’est l’écart de surveillance qui piège la plupart des équipes. La surveillance de disponibilité couvre le chemin requête-réponse. Elle ne couvre pas les tâches planifiées, les workers en arrière-plan ou les pipelines asynchrones.
La surveillance heartbeat comble cet écart. Chaque tâche planifiée reçoit une URL unique. Lorsque la tâche s’exécute avec succès, elle envoie un ping à cette URL. Si le ping n’arrive pas dans la fenêtre attendue, vous recevez une alerte. La configuration est une simple commande curl à la fin de votre script cron.
Surveillez ces tâches au minimum :
- Sauvegardes de base de données
- Files d’attente de livraison d’e-mails
- Facturation et génération de factures
- Synchronisations et exportations de données
- Rotation et nettoyage des logs
- Automatisation du renouvellement des certificats
En savoir plus sur la surveillance heartbeat et comment elle détecte ce que les vérifications de disponibilité manquent.
Choisissez le bon intervalle de vérification
Tous les endpoints n’ont pas besoin de la même fréquence de vérification. Alignez vos intervalles sur l’impact commercial de l’indisponibilité.
Vérifications toutes les 30 secondes pour les endpoints critiques pour le chiffre d’affaires : votre flux de paiement, votre API principale, votre service d’authentification. S’ils tombent, vous perdez de l’argent ou bloquez les utilisateurs. Vous devez le savoir aussi vite que possible.
Vérifications toutes les minutes conviennent à la plupart des services de production. Votre tableau de bord applicatif, les API secondaires, les endpoints de statut. Assez rapide pour détecter les vrais problèmes, assez lent pour éviter les fausses alarmes.
Vérifications toutes les 5 minutes suffisent pour les endpoints à faible priorité : pages marketing, sites de documentation, outils internes. Si le site marketing est indisponible pendant 4 minutes, l’impact commercial est faible.
Plus vos vérifications sont rapides, plus tôt vous savez. Mais des vérifications plus rapides signifient aussi plus de données, plus de bruit et potentiellement des coûts plus élevés. Faites correspondre l’intervalle à l’impact.
Configurez des alertes qui n’épuisent pas votre équipe
La fatigue des alertes est le tueur silencieux de la surveillance. Quand chaque micro-incident déclenche une notification, votre équipe cesse de prêter attention. Ils coupent le canal. Ils ignorent les e-mails. Puis un vrai incident se produit et personne ne le remarque.
Utilisez des seuils d’escalade d’alerte. Exigez 2 ou 3 échecs consécutifs avant qu’une alerte ne se déclenche. Cela filtre les problèmes réseau transitoires qui se résolvent en quelques secondes. Un seul échec de vérification n’est pas un incident. Trois d’affilée le sont.
Routez les alertes par gravité. Les moniteurs critiques vont vers PagerDuty ou les téléphones d’astreinte. Les moniteurs de niveau avertissement vont vers un canal Slack. Les moniteurs informatifs vont par e-mail ou vers un tableau de bord. N’envoyez pas tout au même endroit.
Utilisez des heures de silence pour la maintenance. Si vous déployez chaque mardi à 2h du matin, supprimez les alertes sur les moniteurs concernés pendant cette fenêtre. Votre équipe est au courant du déploiement. Elle n’a pas besoin d’être notifiée parce que l’application a redémarré.
Séparez les canaux d’alerte des canaux de discussion. Votre canal #alertes ne doit contenir que des messages d’alerte automatisés. La discussion humaine a lieu dans #ops ou #ingenierie. Cela garde le flux d’alertes propre et lisible.
Construisez une page de statut que vos utilisateurs consulteront vraiment
Votre page de statut n’est pas juste une case à cocher. C’est un outil de communication qui réduit la charge de support pendant les incidents.
Placez-la sur votre propre domaine (statut.votresociete.com). Personnalisez-la avec votre marque. Liez-la depuis le pied de page de votre application, votre documentation de support et vos pages d’erreur.
Quand un incident se produit, publiez des mises à jour. « Nous enquêtons sur des signalements d’erreurs API accrues » est mieux que le silence. « Le problème a été identifié comme un épuisement du pool de connexions de base de données. Nous montons en puissance. » indique aux utilisateurs que vous savez ce qui ne va pas. « Surveillance de la récupération. La latence API est revenue à la normale. » boucle la communication.
Une page de statut qui se met à jour automatiquement à partir de vos données de surveillance signifie que vous n’avez pas à actionner manuellement des interrupteurs pendant un incident. La page reflète la réalité. Vous vous concentrez sur la résolution du problème. En savoir plus sur les pages de statut PingWatchdog.
Passez en revue vos incidents
Après chaque incident, passez 10 minutes à examiner ce qui s’est passé. Regardez la chronologie. Combien de temps pour détecter ? Combien de temps pour répondre ? Combien de temps pour résoudre ?
Ces trois chiffres sont vos indicateurs fondamentaux de fiabilité : temps moyen de détection (MTTD), temps moyen de réponse (MTTR) et temps moyen de résolution (MTTResolve). Suivez-les dans le temps. Devenez-vous plus rapide ? Plus lent ?
Utilisez les données d’incident pour justifier des améliorations. Si 40 % de vos incidents sont causés par des problèmes de connexion à la base de données, c’est un signal pour investir dans le pool de connexions ou les réplicas de lecture. Si l’expiration des certificats SSL cause des incidents tous les 90 jours, automatisez le renouvellement des certificats.
PingWatchdog crée automatiquement des incidents lorsque les moniteurs tombent et les résout automatiquement lorsque les services récupèrent. Vous obtenez une chronologie complète sans travail manuel. En savoir plus sur la gestion des incidents.
Superposez votre surveillance
Un seul outil ne peut pas tout couvrir. Utilisez PingWatchdog pour la surveillance externe : disponibilité, SSL, heartbeat, pages de statut. Utilisez des outils de surveillance des performances applicatives (APM) comme Datadog ou Sentry pour les métriques internes. Utilisez l’agrégation de logs pour le débogage.
La vue externe vous dit si les utilisateurs peuvent atteindre votre service. La vue interne vous dit pourquoi. Les deux comptent.
Comparer les outils de surveillance pour trouver la stack adaptée à votre équipe.