Publié le 2 août 2022, mis à jour le 21 décembre 2023.
Dans la culture DevOps, le monitoring correspond à la détection de problèmes ou d’incidents sur un site internet ou une application. Dans cet article, je ne reverrai pas la base du monitoring dans le Devops, et vous présenterai directement les deux méthodes de monitoring : le monitoring whitebox et le monitoring blackbox. Nous allons donc voir quelles sont ces manières d’assurer le monitoring d’une infrastructure cloud et lequel privilégier selon votre contexte business.
Qu’est-ce que le monitoring whitebox ?
Le monitoring whitebox consiste à surveiller les serveurs en se concentrant sur leurs composants physiques tels que : l'espace disque, l'utilisation du processeur (CPU), l'utilisation de la mémoire (RAM), les erreurs 5XX, etc.
Dans le marché actuel, la majorité des acteurs du monde du DevOps considèrent le monitoring whitebox comme le monitoring des paramètres standards du système à surveiller.
À noter qu’il existe d'autres types de monitoring whitebox comme le monitoring de composants réseaux, de ressources de l’hyperviseur (pour des machines VMware par exemple).
Pour résumer, le monitoring whitebox consiste à se concentrer sur ce qui se passe à l'intérieur du système sans avoir la vision d’un utilisateur final. Lorsque vous utilisez ce type de monitoring, vous surveillez uniquement le comportement de votre machine. Vous êtes en mesure de voir les problèmes permanents des systèmes, mais vous n’avez pas la connaissance de l’impact de ces problèmes pour votre utilisateur final.
L’avantage majeur du monitoring whitebox est de pouvoir anticiper les problèmes. Par exemple, si je sais que j’utilise déjà tout mon CPU disponible, le fait de rajouter une application engendrera un incident, car ma machine n’aura pas assez de puissance pour la supporter.
Un autre avantage de ce monitoring est de pouvoir suivre et observer des composants qui ne sont pas user facing. Dans ce type de cas, le monitoring whitebox devient obligatoire.
Qu’est-ce que le monitoring blackbox ?
Le monitoring blackbox correspond pour sa part à la surveillance des parcours utilisateurs (applications web ou mobile par exemple) et non plus des composants du serveur.
Un exemple est la surveillance du nombre de requêtes HTTP qui sont envoyées au serveur web par un client et qui reviennent sans retour de la part de ce dernier (ou avec un message d’erreur).
Le monitoring blackbox possède donc dans sa définition une composante plus orientée business que le monitoring whitebox. On se place d’un point de vue externe au serveur et non plus interne.
Sur le marché actuellement, il existe des dizaines de manières d’assurer un monitoring blackbox. En voici deux exemples :
- Le nombre d’utilisateurs sur une application web ou mobile
- Le nombre de requêtes HTTP sans retour envoyées
Lorsqu’une entreprise choisit le monitoring blackbox pour assurer la surveillance de son infrastructure, elle va généralement définir des parcours critiques sur son site web.
Ces parcours sont souvent :
- Des chemins réalisés fréquemment par les utilisateurs
- Des chemins critiques pour le business (exemple : la redirection vers la page de paiement d’un site web).
Une sonde va ensuite être placée sur ces parcours critiques. Et ces sondes vont remonter une alerte selon un indicateur choisi en amont (ex : 3 requêtes HTTP qui reviennent sans retour).
Les avantages du monitoring blackboxsont multiples :
- Nous obtenons une meilleure vue d'ensemble de la situation.
- La recherche d'erreurs et de problèmes est facilitée.
- Les indicateurs sont des indicateurs mesurables qui impactent directement le business de l’entreprise
Quelles sont les grandes différences entre le monitoring whitebox et le monitoring blackbox ?
Comme vu ci-dessus, les différences entre monitoring whitebox et monitoring blackbox sont multiples.
Historiquement, le monitoring whitebox était majoritaire et il y avait une lacune dans la surveillance des applications à destination des utilisateurs finaux.
Ceci posait de nombreux problèmes, car le monitoring whitebox détectait les problèmes des systèmes, tels qu'une charge élevée ou un trafic réseau important. Cependant, aucune information du côté de l'application n’était remontée. Or, en général, ces incidents sont causés par des problèmes applicatifs, et non de serveur.
Prenons un exemple concret pour éclaircir le sujet :
Scénario 1 : Sans monitoring
- Le système de paiement d’un site e-commerce spécialisé dans la vente de cactus tombe en panne;
- 300 utilisateurs (et donc clients potentiels !) ont essayé d’acheter un cactus sans pouvoir accéder à la page du paiement et quittent donc le site internet sans avoir réalisé d’achat
- Le 301ᵉ utilisateur appelle le support client insatisfait de la prestation du site
- Le service client envoie un ticket à l’équipe technique qui prend le problème en charge
Bilan : 300 clients potentiels perdus pour l’entreprise et grande insatisfaction client
Scénario 2 : Monitoring blackbox seul
- Le système de paiement d’un site e-commerce spécialisé dans la vente de cactus tombe en panne
- Au bout de la cinquième requête HTTP qui revient en erreur (seuil défini par l’entreprise), la sonde posée en amont sur ce parcours critique alerte l’équipe technique pour remonter l’incident
- L’équipe technique est au courant que le problème concerne la page de paiement et commence à débugueur
Bilan : 5 clients potentiels perdus pour l’entreprise, peu d’insatisfaction client
Scénario 3 : Monitoring whitebox seul
- Le système de paiement d’un site e-commerce spécialisé dans la vente de cactus tombe en panne
- La panne ne concerne pas un problème lié au CPU ou à la RAM du serveur, et aucune alerte n’est donc déclenchée !
- 300 utilisateurs (et donc clients potentiels !) ont essayé d’acheter un cactus sans pouvoir accéder à la page du paiement et quittent donc le site internet sans avoir réalisé d’achat
- Le 301ᵉ utilisateur appelle le support client insatisfait de la prestation du site
- Le service client envoie un ticket à l’équipe technique qui prend le problème en charge
Bilan : 300 clients potentiels perdus pour l’entreprise et grande insatisfaction client
Quel type de monitoring utiliser selon votre situation ?
Il est important de réaliser l'importance de ces deux types de monitoring.
Comme nous l’avons vu dans l’exemple ci-dessus, le type de monitoring utilisé dépend en grande partie de l’utilisation finale du produit ou des services de l’entreprise : si l’entreprise a une application qui interagit avec des utilisateurs finaux, le monitoring blackbox s’impose, sinon nous pencherons peut-être pour le monitoring whitebox.
La grande différence entre l’utilisation du monitoring blackbox et du monitoring whitebox se situe donc dans le fait que votre application soit utilisée par des utilisateurs finaux ou non.
Néanmoins, il faut également noter que les deux types de monitoring peuvent (et doivent) être utilisés en parallèle : le monitoring blackbox permettant de réagir rapidement aux incidents critiques pour votre business et le monitoring whitebox permettant d’enquêter en profondeur pour la résolution de l’incident (par exemple, est-ce que c’est ma requête qui est trop gourmande en CPU ?) et d’anticiper les incidents liés à l’infrastructure.
Conclusion
Le monitoring blackbox est ainsi en train de prendre le dessus sur le monitoring whitebox pour sa vision business et la manière dont il permet d’identifier rapidement les problèmes. Néanmoins, le monitoring whitebox peut lui aussi être la bonne solution pour vous selon vos objectifs et votre business model.
Pour leurs avantages respectifs, les deux types de monitoring doivent être utilisés en parallèle. Cependant, leur articulation est particulière à chacun et demande une réflexion approfondie pour s’adapter au mieux à vos enjeux. Afin de vous aider dans cette réflexion et dans la mise en place du système de monitoring le plus adapté, le pôle infogérance de Padok vous conseille dans ce choix et vous propose d’externaliser la supervision de votre infrastructure cloud.