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.
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 :
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 :
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 :
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
Bilan : 300 clients potentiels perdus pour l’entreprise et grande insatisfaction client
Scénario 2 : Monitoring blackbox seul
Bilan : 5 clients potentiels perdus pour l’entreprise, peu d’insatisfaction client
Scénario 3 : Monitoring whitebox seul
Bilan : 300 clients potentiels perdus pour l’entreprise et grande insatisfaction client
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.
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.