Comment sont détectées les anomalies serveur sur un hébergement infogéré ?

Pour différentes raisons, un serveur peut tomber. Cela peut venir d’une saturation mémoire, d’un service qui ne répond plus, d’un disque plein, d’un certificat SSL expiré… Grâce à un hébergement infogéré, ce genre d’anomalies est généralement détecté et traité avant que vous n’en constatiez les effets. C’est ce que le monitoring continu permet lorsqu’une équipe technique est disponible pour agir derrière les alertes. Mais comment cette surveillance fonctionne-t-elle ?

Qu’est-ce que couvre le monitoring sur un hébergement infogéré ?

Le monitoring est souvent résumé à tort à une vérification de disponibilité : le serveur répond ? Alors tout va bien ! En réalité, le monitoring est un dispositif sérieux qui surveille bien plus. Il couvre l’état des ressources système, le comportement des services applicatifs, les seuils d’alerte configurés et la cohérence des sauvegardes.

Sur un hébergement infogéré, le dispositif tourne en continu pour repérer les anomalies. Des sondes actives interrogent le serveur à intervalles réguliers, collectent des métriques et les comparent à des seuils définis. Quand une valeur sort de la plage normale, une alerte est ainsi générée. Ce n’est évidemment pas un humain qui surveille un écran en permanence, c’est le système automatisé qui remonte les signaux et une équipe technique qui les traite.

La différence entre un hébergement mutualisé standard et un hébergement infogéré tient largement à ce point. Sur un mutualisé, personne ne surveille spécifiquement votre site internet. En revanche, sur un infogéré, le périmètre de surveillance est défini contractuellement et l’équipe technique est engagée à réagir dans des délais courts.

Les métriques surveillées en temps réel par l’hébergeur infogérant

Les sondes de monitoring collectent en permanence un ensemble de métriques système. Chacune renseigne sur un aspect de l’état du serveur et permet alors d’anticiper les anomalies sur votre hébergement infogéré avant qu’elles n’affectent les utilisateurs et votre activité.

La surveillance des services applicatifs

Les métriques système ne suffisent pas à garantir qu’un hébergement fonctionne correctement. En effet, un serveur peut afficher une charge CPU normale et un service applicatif critique en état d’échec. La surveillance des processus et des services est un second niveau de monitoring.

Le serveur web, qu’il s’agisse d’Apache ou de Nginx, est le premier maillon à surveiller. Une sonde vérifie à intervalles réguliers que le serveur répond aux requêtes HTTP et HTTPS dans des délais normaux. Un processus bloqué ou un worker saturé peut faire chuter les temps de réponse sans que les métriques CPU ou RAM n’affichent d’anomalie évidente sur votre hébergement infogéré.

Le PHP-FPM fait également l’objet d’une surveillance lors d’une infogérance. Le nombre de workers actifs, le taux de requêtes en attente et les éventuels crashes de processus sont des indicateurs de la santé de la couche applicative. En cas de saturation du pool PHP-FPM, des erreurs 502 ou 504 apparaissent côté utilisateur.

MySQL ou MariaDB est surveillé sur sa disponibilité mais aussi sur ses performances (nombre de connexions actives, requêtes lentes, verrous en attente…). Une base de données qui répond peut accumuler des slow queries qui viennent dégrader l’expérience utilisateur sans déclencher d’alerte de disponibilité.

Les certificats SSL sont également surveillés par un hébergement infogéré. Une expiration coupe drastiquement l’accès HTTPS et génère des alertes de sécurité dans les navigateurs, ce qui est bien évidemment très mauvais signe. La sonde vérifie la date d’expiration et déclenche une alerte suffisamment en amont pour permettre un renouvellement sans interruption.

Les sauvegardes sont aussi vérifiées. Qu’elles soient quotidiennes ou plus fréquentes, leur bonne exécution est contrôlée pour éviter qu’un échec de sauvegarde ne survienne au pire moment.

Comment l’équipe technique d’un hébergeur infogéré réagit face à une anomalie ?

Savez-vous ce qu’il se passe après le déclenchement d’une alerte générée par une sonde lors de l’infogérance ? Eh bien on vous explique tout !

Distinction entre une alerte préventive et un incident critique

Il existe plusieurs niveaux d’alerte qu’un système de monitoring distingue. Il ne traitera pas chaque dépassement de seuil comme une urgence. Par exemple, une utilisation CPU à 85% pendant deux minutes est un signal à surveiller, mais pas une urgence. Un service MySQL qui ne répond plus est quant à lui un incident critique qui impacte directement les utilisateurs. Sans gradation du genre, l’équipe technique se noierait dans des alertes peu significatives.

Le circuit d’intervention

Lorsqu’une alerte critique est déclenchée, elle remonte vers l’équipe d’astreinte par plusieurs canaux simultanés quelle que soit l’heure : notification dans l’outil de supervision, SMS, appel si nécessaire. La prise en charge suit un ordre logique :

• identification de la source de l’anomalie
• évaluation de l’impact
• action corrective

Selon la nature de l’incident ou de l’anomalie sur votre hébergement infogéré, cela peut aller d’un redémarrage de service à une intervention plus profonde sur la configuration ou les ressources. Le client est informé dès lors que l’incident affecte la disponibilité ou les performances de son hébergement.

Une disponibilité 24h/24 côté équipe ne signifie pas qu’un ingénieur surveille activement chaque serveur à toute heure. Cela signifie qu’une personne compétente est joignable et en capacité d’intervenir à tout moment, y compris la nuit et le week-end.

Ce que Gladhost met en place pour ses clients infogérés

L’infogérance chez Gladhost est réalisée par une équipe technique française, joignable et en capacité d’intervenir à tout moment. Nos techniciens connaissent donc les environnements qu’ils administrent et interviennent directement sur les serveurs de nos clients.

Le périmètre d’intervention de Gladhost couvre l’ensemble de la couche système :

• configuration et optimisation du serveur
• mises à jour de sécurité
• gestion des services applicatifs
• surveillance continue des métriques et des processus…

En cas d’incident, le diagnostic et la résolution sont pris en charge sans que le client ait à intervenir ou à ouvrir un terminal.

La communication est aussi un point sur lequel Gladhost s’engage. Le client est informé de la nature du problème, des actions engagées et du retour à la normale pour éviter que le site soit indisponible pendant des heures sans que son propriétaire en soit averti.

Les limites du monitoring automatique

Un dispositif de monitoring sur un hébergement infogéré ne détecte les anomalies que s’il est bien configuré pour surveiller. Les sondes mesurent des métriques système et vérifient que les services répondent. Elles ne comprennent pas ce qui se passe à l’intérieur de l’application.

Une boutique PrestaShop qui affiche des erreurs sur le tunnel de commande à cause d’un module mal configuré ne déclenchera malheureusement pas d’alerte système. Le serveur web répond, PHP-FPM tourne, MySQL est disponible : tout est vert côté monitoring, mais l’utilisateur ne peut pas finaliser son achat. Ce type d’anomalie relève du diagnostic applicatif, pas de la surveillance infrastructure.

Les lenteurs liées à des requêtes SQL sont dans le même cas. Une requête qui met trois secondes à s’exécuter à cause d’un index manquant ne génère pas d’alerte de disponibilité mais dégrade l’expérience utilisateur. L’identifier nécessite une analyse des slow query logs, ce qui sort du périmètre du monitoring automatique et suppose une intervention humaine.

L’infogérance couvre la stabilité et la disponibilité de l’infrastructure. Elle ne se substitue pas au développeur ou à l’intégrateur responsable de l’application.