La surveillance de vos services web
Quel que soit le site internet ou l’application que vous développez, il y a fort à parier que vous lui souhaitiez la meilleure disponibilité possible — voir que cela soit une contrainte forte. Pour cela, il y a deux volets. Tout d’abord le proactif, c’est-à-dire un ensemble de mesures que vous pouvez prendre avant qu’un incident intervienne, dans l’objectif de limiter l’importance ou la durée d’un tel incident. Puis il y a le réactif, ce que vous faites une fois l’incident déclaré. Toutes les mesures réactives commencent par un point essentiel : être au courant qu’il y a un incident en cours. Pour cela, il existe depuis bien longtemps des systèmes permettant de surveiller des points spécifiques de votre infrastructure, tel que le taux d’utilisation du CPU ou la quantité de mémoire vive disponible. Ces indicateurs restent tout à fait pertinents.
Cependant, les nouveaux modes de déploiement des applications nécessitent plus : Les applications hébergées dans le cloud peuvent souffrir de contentions liées à la virtualisation ; Les services isolés dans des conteneurs peuvent devenir non réactifs ; Les briques techniques consommés en mode PaaS — et donc, par définition, vous sont livrés sans ces informations systèmes tant utiles à la surveillance — peuvent souffrir de divers problèmes de disponibilité.
Ces contraintes nous poussent à concevoir de nouvelles manières de surveiller nos applicatifs, afin d’être le plus réactif et le plus précis possible lors de la survenue d’un incident.
Quels sont les éléments à surveiller ?
Votre application web, ou votre API, est rarement autosuffisante. Vous utilisez probablement une base de données — voire plusieurs. Votre application écrit peut-être des fichiers sur un espace de stockage, même temporaire. Il se peut également que vous utilisez des services externes, comme pour l’envoi d’email.
Tous ces éléments sont susceptibles de devenir défaillants, et donc doivent être surveillés. De plus, chaque système peut avoir des particularités qu’il convient peut-être de distinguer. Par exemple, une requête de récupération de données dans une base de données est à différencier de l’insertion d’un nouvelle donnés.
En effet, le système que nous souhaitons implémenter doit permettre de vérifier que le serveur d’application et tous les services dont il dépend sont fonctionnels, et ce dans les conditions de production. Votre système de fichiers est peut-être disponible et avec de l’espace disque libre, mais le compte de service de votre application n’a peut-être que les droits en lecture seule.
L’un des design patterns couramment utilisé est celui du “Heart Beat” (littéralement battement de cœur). Votre site expose, à une URL spécifique que vous seul connaissez, une méthode un peu particulière qui va effectuer l’ensemble de ces vérifications pour vous, et qui vous retournera un état complet de votre système.
Comment implémenter les possibilités de surveillance dans votre code ?
L’implémentation concrète de cette méthode est dépendante des technologies que vous utilisez pour développer votre application, ainsi que des services dont elle dépend. Il y a cependant plusieurs éléments que vous pouvez prendre en compte :
- Ne jamais effectuer une opération irréversible : Les données manipulées lors de ce test ne doivent pas altérer le fonctionnement de votre logiciel ou corrompre les données de quelque manière que ce soit. Vous pouvez, par exemple, écrire dans une table de la base de données créée spécifiquement pour les besoins des tests.
- Prévoir des timeouts : Votre service de test aura probablement intérêt à considérer qu’un service qui ne répond pas dans un laps de temps déterminé n’est pas disponible.
- Ne jamais bloquer les autres clients du service : Tout comme vos tests ne doivent pas impacter les données de production, vous devez vous assurer qu’ils ne doivent pas non plus ralentir de manière considérable l’exécution du service pour les autres utilisateurs.
- Utiliser un maximum de code d’infrastructure ou métier : Si votre application utilise un ORM, alors vos tests devront l’utiliser également. Ce principe permet de tester non seulement le service externe, mais également la configuration de votre application permettant d’interagir avec ce système.
Une autre bonne pratique est de rendre accessible ces différents tests séparément. Cela peut vous permettre de mieux comprendre le service défaillant dans votre topologie, ou de tester vos différents services à des fréquences adaptées à leurs contraintes.
Ces tests, qui exécutés à intervalles régulières par un système que vous maîtrisez, sont inoffensifs. Les mêmes tests exécutés plusieurs centaines de fois pas seconde peuvent devenir un formidable point d’entrée pour une attaque en déni de service — appelée DDoS. C’est pourquoi il conviendra de sécuriser cette API comme il se doit. Encore une fois, les possibilités de sécurisation sont nombreuses : tokens HTTP, filtrage par IP, etc..
Comment mettre en place une surveillance active ?
Une fois votre méthode de tests prête, il vous faut maintenant effectuer deux actions :
- L’appeler à intervalle régulière (toutes les minutes, toutes les 5 minutes, …)
- Si elle ne s’exécute pas correctement une ou plusieurs fois, vous alerter ou alerter votre équipe.
Pour des raisons évidentes, le système qui teste votre service devra être hébergé en dehors de votre infrastructure, et si possible chez un autre prestataire. De plus, l’héberger vous-même impliquerai que cela soit aussi un service qui doit être surveillé, ce qui créerai une boucle infinie de surveillance :)
Il existe donc des services, la plupart payant, permettant d’interroger à intervalles régulières votre service, et de vous envoyer des alertes ou des rapports. Il en existe de nombreux, dont Pingdom et UptimeRobot.
Ces services, bien que répondant au besoin premier de surveillance et d’alerte, n’ont pas d’intelligence particulière. Si votre service principal est une API, il peut être intéressant de tester l’exactitude des réponses données. Des services tel que Runscope vous permettent d’écrire des jeux de tests et de les jouer à intervalle régulière.
Lors d’un incident, la transparence de l’information à l’utilisateur est l’une des clés de la gestion des incidents. Dans ce cadre, il peut être intéressant de créer une page de “status” indiquant l’état de votre service, ainsi que d’éventuelles informations sur la prise en charge et résolution d’un incident. Le service — payant — statuspage.io, ou le projet opensource Cachet vous permettent de réaliser cela simplement.
En fonction de l’importance de votre projet, ou de ses contraintes, il est possible d’aller plus loin dans la surveillance active. Par exemple, une application s’exécutant dans des containers peut avoir un orchestrateur qui redémarre automatiquement un conteneur après que son heartbeat ne réponde pas trois fois. Les systèmes d’alertes peuvent être couplés à des systèmes de gestion d’astreintes, qui possèdent des systèmes automatiques d’escalade : si vous ne répondez pas à l’alerte dans un certain laps de temps, elle sera automatiquement transférée à un collègue.
Citation
Pour attribuer ce texte, merci d'utiliser la formule suivante
Maneu (2017, Avril 20). maneu.net: La surveillance de vos services web. Retrieved from https://www.maneu.fr/dev/2017-surveillance-services-web/
@misc{ 2017-surveillance-services-web,
author = {Maneu, Christopher},
title = { La surveillance de vos services web },
url = { https://www.maneu.fr/dev/2017-surveillance-services-web/ },
year = { 2017 }
}