Surveiller votre serveur

Module 8: Sauvegardes et surveillance · Temps de lecture : 10 minutes

Objectif pédagogique : Après cette leçon, vous saurez déterminer ce que vous surveillez sur votre serveur (de l'extérieur et de l'intérieur), quels seuils sont pertinents, et comment faire en sorte qu'une alerte vous parvienne vraiment sans que vous soyez submergé d'alertes.

Notions clés : surveillance externe, surveillance interne, disponibilité (uptime), contrôle http, contrôle de port, expiration du certificat, espace disque, mémoire, charge (load), heartbeat (dead man's switch), seuil, canal d'alerte, fatigue d'alerte, graphiques de l'hébergeur

Pourquoi surveiller ?

Sans surveillance, vous apprenez les problèmes par vos clients, ou pas du tout. Un site web hors ligne depuis samedi, un certificat expiré, un disque saturé, une sauvegarde qui échoue en silence depuis trois semaines : autant de choses que vous auriez pu voir à temps. Surveiller signifie : un programme observe en continu et vous avertit si quelque chose ne va pas.

Une bonne surveillance répond à deux questions :

1. Est-ce que cela fonctionne pour l'utilisateur ? Cela se mesure depuis l'extérieur.
2. Est-ce que quelque chose va bientôt mal tourner ? Cela se mesure depuis l'intérieur : disque, mémoire, mises à jour, sauvegardes.

Depuis l'extérieur : ce que voit l'utilisateur

La surveillance externe tourne sur une autre machine que votre serveur, idéalement chez un autre fournisseur. C'est logique : si votre serveur est hors service, il ne peut plus lancer d'alerte lui-même.

Le certificat mérite une attention particulière. Les certificats Let's Encrypt ont une courte durée de validité et sont renouvelés automatiquement (leçon 7.3), mais si ce renouvellement échoue en silence, vous ne le remarquez que lorsque les visiteurs reçoivent un avertissement. Depuis juin 2025, Let's Encrypt n'envoie plus d'e-mails de rappel pour les certificats qui expirent et recommande lui-même la surveillance. Un contrôle de certificat qui avertit lorsqu'il reste moins de 14 jours de validité n'est donc pas un luxe.

Un programme courant pour le faire vous-même est Uptime Kuma, que vous installerez dans un conteneur à la leçon 9.4. Ne le placez de préférence pas sur le serveur qu'il doit surveiller, ou combinez-le avec un second contrôle externe. Il existe aussi des services tiers qui font la même chose ; choisissez-en un qui vous convient, et vérifiez où il est établi si des données de vos clients peuvent figurer dans les alertes.

Depuis l'intérieur : ce qui va bientôt mal tourner

Certains problèmes ne se voient de l'extérieur que lorsqu'il est trop tard. Vous les mesurez sur le serveur lui-même :

Vous pouvez le faire avec un simple script et un timer (leçon 6.3) qui envoie une alerte en cas de dépassement, ou avec un programme de surveillance doté d'un agent sur le serveur (des exemples open source connus sont Netdata et la combinaison Prometheus avec node_exporter). Commencez petit : le disque, les services en échec et les sauvegardes couvrent la plupart des problèmes.

Les graphiques du panneau de votre hébergeur (processeur, mémoire, réseau, disque sur une période d'un jour à un an) sont un excellent complément pour repérer les tendances : si votre disque grossit de quelques pour cent chaque mois, vous savez quand il sera plein. Chez WebOké, ils se trouvent dans l'écran du VPS ; chez les autres hébergeurs, c'est comparable. En général, ils n'envoient pas d'alerte, ils ne remplacent donc pas la surveillance.

Le heartbeat : alerter quand il ne se passe rien

Certaines choses doivent justement être surveillées sur l'absence d'un signal. La sauvegarde de cette nuit en est le meilleur exemple : si le script ne démarre même pas (timer désactivé, serveur éteint, script cassé), aucun message d'erreur n'arrive non plus.

La solution s'appelle un heartbeat ou dead man's switch : votre surveillance attend un signal chaque jour. À la fin, et seulement si tout a réussi, le script de sauvegarde envoie une petite requête http vers une URL fixe et secrète de votre surveillance :

restic backup ... && restic check && curl -fsS -m 10 https://status.example.com/api/push/Xyz123abc?status=up >/dev/null

Si le signal n'arrive pas pendant un jour, vous recevez une alerte. Uptime Kuma propose pour cela le type de moniteur Push ; il existe aussi des programmes auto-hébergeables comme Healthchecks. Ainsi, une seule ligne vous permet de vérifier que votre sauvegarde a réellement tourné.

Des alertes qui arrivent, sans excès

Une alerte que personne ne lit n'est pas de la surveillance. Réglez trois points :

1. Un canal d'alerte que vous voyez vraiment : une notification push sur votre téléphone, un canal de messagerie instantanée, un SMS. L'e-mail est possible, mais seulement si votre serveur peut envoyer des e-mails de manière fiable, et un e-mail passe facilement inaperçu. Utilisez deux canaux pour les alertes les plus importantes.
2. Indépendant de ce que vous surveillez. Si votre serveur envoie lui-même l'e-mail concernant un disque plein, celui-ci n'arrivera pas quand le disque sera plein. La surveillance externe et un heartbeat couvrent ce cas.
3. Peu d'alertes, mais justifiées. Si vous recevez chaque jour dix alertes dont vous ne faites rien, vous finirez par les ignorer, y compris celle qui compte. C'est ce qu'on appelle la fatigue d'alerte. Réglez les seuils de sorte qu'une alerte signifie : vous devez agir. Ne déclenchez une alerte qu'après plusieurs contrôles échoués consécutifs (par exemple trois), afin qu'un seul paquet perdu ne vous réveille pas.

Testez vos alertes : arrêtez un service un instant et vérifiez si l'alerte arrive, et en combien de temps.

Ce qu'il ne faut pas faire

• Des pages de surveillance ouvertes à tous avec des noms et adresses internes. Une page de statut publique est acceptable, mais n'y montrez que ce que les visiteurs peuvent savoir.
• Un compte administrateur de votre surveillance sans mot de passe robuste ni 2FA. Quiconque accède à votre surveillance peut désactiver les alertes.
• Des agents disposant de plus de droits que nécessaire. Un agent de surveillance n'a généralement pas besoin d'être root.

Résumé

• Surveillez depuis l'extérieur si cela fonctionne (http, port, certificat, DNS), à partir d'une autre machine, et depuis l'intérieur si quelque chose va bientôt mal tourner (disque, mémoire, services, mises à jour, sauvegardes).
• Les certificats méritent leur propre contrôle : depuis juin 2025, Let's Encrypt n'envoie plus d'e-mails de rappel.
• Un heartbeat signale l'absence d'un signal ; idéal pour les sauvegardes et les tâches planifiées.
• Choisissez un canal d'alerte que vous voyez vraiment, indépendant du serveur lui-même, et réglez les seuils de sorte que chaque alerte demande une action.
• Les graphiques de votre hébergeur montrent les tendances, mais n'envoient généralement pas d'alerte.

Quiz

Exercice

Exercice O8.3 : Votre liste de surveillance. Établissez une liste de surveillance pour votre propre serveur : quels contrôles externes (à quel intervalle et depuis où), quels contrôles internes (avec quels seuils), quel(s) heartbeat(s), et par quel canal arrivent les alertes. Mettez en place au moins un contrôle externe http ou de certificat et un heartbeat (par exemple pour votre sauvegarde), puis testez l'alerte en arrêtant un service un instant. Notez le temps qu'il a fallu pour que l'alerte arrive.

Pour aller plus loin

• Plus d'accès à votre VPS : que faire ?
• Let's Encrypt, Expiration Notification Service Has Ended (en anglais) : https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended
• Uptime Kuma (GitHub) : https://github.com/louislam/uptime-kuma