Avant de commencer
Vous avez besoin d’un compte de surveillance et d’une URL à surveiller. C’est tout. Pas de code à déployer. Pas d’agent à installer. Pas de fichiers de configuration à modifier.
Si vous n’avez pas encore de compte, le plan gratuit de PingWatchdog vous offre 15 moniteurs, des vérifications toutes les 5 minutes, la surveillance SSL, la surveillance heartbeat et une page de statut personnalisée. Aucune carte bancaire requise.
Étape 1 : Ajouter votre premier moniteur
Allez sur votre tableau de bord et cliquez sur « Ajouter un moniteur ». Vous verrez un formulaire avec quelques champs.
URL : Saisissez l’URL complète que vous souhaitez surveiller. Utilisez le point de terminaison exact que vos utilisateurs atteignent. Pour un site web, c’est https://votresite.com. Pour une API, utilisez le point de terminaison spécifique comme https://api.votresite.com/v1/health.
Type de vérification : Choisissez HTTP pour les sites web et les API. Choisissez TCP pour les bases de données, les serveurs de messagerie ou les ports personnalisés. Choisissez UDP pour les serveurs de jeux ou DNS (disponible sur les plans payants).
Intervalle de vérification : À quelle fréquence devons-nous vérifier ? Commencez par 5 minutes pendant que vous testez. Vous pourrez réduire cet intervalle plus tard. Les plans payants descendent jusqu’à 30 secondes.
Régions : Choisissez d’où vérifier. Plus de régions vous donnent une meilleure assurance qu’une alerte signifie « le site est hors service globalement » plutôt que « le site est lent depuis un emplacement ».
Canaux d’alerte : Choisissez où vont les alertes. L’e-mail fonctionne pour les tests. Ajoutez Slack ou Discord pour votre équipe. Ajoutez PagerDuty pour l’astreinte.
Cliquez sur « Créer le moniteur ». C’est tout. Votre site est maintenant surveillé.
Étape 2 : Tester vos alertes
N’attendez pas une vraie panne pour savoir si vos alertes fonctionnent. Testez-les maintenant.
La plupart des outils de surveillance ont un bouton « tester l’alerte ». Cliquez dessus. Vous devriez recevoir une notification dans le canal que vous avez configuré. Si ce n’est pas le cas, vérifiez la configuration de votre canal d’alerte.
Pour Slack ou Discord, assurez-vous que l’URL du webhook est correcte et que le bot a la permission de publier dans ce canal. Pour l’e-mail, vérifiez votre dossier spam et mettez l’adresse d’envoi du service de surveillance en liste blanche.
Étape 3 : Configurer les paramètres d’alerte
Les alertes ne sont utiles que si elles atteignent les bonnes personnes sans provoquer de fatigue d’alerte. Prenez quelques minutes pour ajuster vos paramètres.
Escalade d’alerte : Définissez un seuil pour ne pas être alerté pour chaque incident passager. Un seuil de 2 ou 3 échecs consécutifs filtre les microcoupures réseau de 30 secondes. Vous n’êtes alerté que lorsque le problème persiste.
Heures de silence : Si vous effectuez une maintenance planifiée le dimanche à 3h du matin, définissez des heures de silence pour que votre équipe ne soit pas réveillée pour un travail planifié. Les heures de silence sont par moniteur, vous pouvez donc supprimer les alertes sur les moniteurs non critiques en dehors des heures ouvrées tout en gardant les critiques actifs.
Routage des canaux : Différents moniteurs, différents canaux. Les moniteurs de production critiques vont vers PagerDuty. Les moniteurs de staging vont vers un canal Slack. Les moniteurs à faible priorité vont par e-mail. Cela garde vos canaux d’alerte principaux propres.
Étape 4 : Ajouter plus de moniteurs
Votre premier moniteur était votre page d’accueil. Bon début. Ajoutez maintenant les points de terminaison qui comptent.
Votre API : Si votre application dépend d’une API, surveillez l’API directement. Une page d’accueil en bonne santé ne signifie pas une API en bonne santé.
Vos flux de connexion et de paiement : Surveillez les pages où les utilisateurs agissent, pas seulement celles qu’ils consultent. Un paiement cassé coûte de l’argent. Une connexion cassée bloque les utilisateurs.
Votre base de données et votre cache : Ajoutez des moniteurs TCP pour votre port de base de données (généralement 5432 pour PostgreSQL, 6379 pour Redis). Ils vous indiquent si le service accepte les connexions, pas seulement si le serveur est en ligne.
Vos tâches de fond : Ajoutez des moniteurs heartbeat pour les tâches planifiées critiques. Sauvegardes de base de données, files d’e-mails, synchronisations de données. Elles tournent silencieusement. Si elles échouent, vous pourriez ne pas le remarquer pendant des semaines. En savoir plus sur la surveillance heartbeat.
Vos certificats SSL : Ajoutez des moniteurs SSL pour chaque domaine que vous possédez. Vous recevez des alertes 30, 14 et 7 jours avant l’expiration. L’expiration des certificats est l’une des causes de panne les plus évitables. En savoir plus sur la surveillance SSL.
Étape 5 : Partager votre page de statut
Si votre outil de surveillance inclut des pages de statut, configurez-en une. Une page de statut répond à la question « c’est down ou c’est juste moi ? » avant que vos utilisateurs ne vous contactent.
Choisissez quels moniteurs apparaissent sur la page. Il s’agit généralement de vos services publics : site web, API, tableau de bord. Les moniteurs internes (base de données, tâches de fond) restent privés.
Personnalisez la page avec votre logo et vos couleurs. Sur les plans payants, utilisez votre propre domaine (statut.votreentreprise.com). Partagez l’URL dans le pied de page de votre application, votre documentation de support et votre bio Twitter.
Lorsqu’un incident se produit, votre page de statut se met à jour automatiquement. Les utilisateurs voient l’état actuel sans vous contacter. Pendant l’incident, publiez des mises à jour pour que les utilisateurs sachent que vous travaillez dessus. En savoir plus sur les pages de statut.
Que faire lorsque vous recevez une alerte
Votre téléphone vibre. Un moniteur est hors service. Et maintenant ?
D’abord, vérifiez. Consultez le site vous-même. Parfois, c’est vraiment juste vous. Si le site se charge pour vous mais que la sonde signale une panne, il pourrait y avoir un problème réseau régional.
Si le site est vraiment hors service, vérifiez les choses évidentes : votre hébergeur a-t-il eu un incident ? Avez-vous déployé récemment ? Un certificat a-t-il expiré ? Avez-vous atteint une limite de débit ou manqué d’espace disque ?
Corrigez le problème. Ensuite, mettez à jour votre page de statut pour que les utilisateurs sachent que vous êtes dessus. Après la récupération, examinez la chronologie de l’incident. Qu’est-ce qui a échoué ? Combien de temps a pris la détection ? Combien de temps la correction ? Utilisez ces données pour vous améliorer.
Prochaines étapes
Vous avez maintenant la surveillance configurée. Votre site est vérifié. Vous êtes alerté quand les choses tournent mal. Voici quoi faire ensuite :
- Comparez PingWatchdog avec UptimeRobot pour voir comment nous nous comparons à l’outil gratuit le plus populaire
- Configurez la surveillance des certificats SSL si ce n’est pas déjà fait
- Apprenez-en plus sur la gestion d’incidents pour suivre automatiquement les événements de panne
Commencez avec 15 moniteurs gratuits. Voir nos offres quand vous êtes prêt pour des vérifications plus rapides et plus de fonctionnalités.