La surveillance de l'infrastructure AWS

Introduction

Dans les chapitres précédents, nous avons créé et manipulé de nombreux éléments d’infrastructure AWS, à commencer par les pièces de base comme les AMI et les EC2, jusqu’aux périphériques de stockage ou réseaux. Ils ont tous besoin d’une constante surveillance, non seulement du point de vue de leurs performances et efficacité, mais aussi du point de vue de leurs coûts.

Contrairement aux environnements classiques, un cloud présente un comportement extrêmement dynamique, grâce au scale-up et scale-down qu’on a examiné en détail précédemment. Cette capacité d’adaptation à la demande peut augmenter dramatiquement les ressources mises à disposition des applications et des services, ou au contraire, les diminuer de manière drastique. On comprend bien que ce processus doit impérativement être tenu sous surveillance accrue.

Or, cette activité de surveillance, au-delà du fait qu’elle ne peut pas s’effectuer manuellement, nécessite des outils très différents de ceux utilisés traditionnellement par les administrateurs système et réseau. Ne serait-ce que parce qu’ils ne pourraient jamais surveiller des milliers de machines virtuelles à la fois, tel que c’est le plus souvent...

Concepts et terminologie de base

Avant de nous plonger dans les subtilités du monitoring de l’infrastructure AWS avec CloudWatch, nous allons d’abord faire une courte incursion dans la terminologie et les concepts de base.

Démarrer avec CloudWatch

Voyons maintenant comment utiliser CloudWatch pour générer des alarmes en tout genre et pour surveiller non seulement notre infrastructure AWS, mais également notre activité.

1. Surveiller les coûts d’utilisation de CloudWatch

Ce qui est bien avec CloudWatch, c’est que ce service peut se surveiller lui-même et vous aider à estimer les coûts associés. Pour avoir accès à cette fonctionnalité, il est nécessaire de se connecter à AWS en tant qu’utilisateur root et pas IAM, même si ce dernier dispose des droits d’administration. Ceci va un peu à l’encontre de nos recommandations précédentes consistant à ne jamais utiliser le compte root, on fera ici une exception, car AWS a ses propres raisons que, quelquefois, la raison ignore.

 Connectez-vous donc à AWS en utilisant votre compte root. Sélectionnez l’option Tableau de bord de ma facturation qui apparaît en haut à droite, lorsque vous faites un clic droit sur votre nom dans la barre de navigation.

Vous allez être dirigé vers le tableau de bord vous permettant de gérer votre facturation, comme montré ci-dessus :

Le tableau de commande pour la gestion de la facturation

 Ici, cliquez sur Préférences de facturation dans la zone de navigation à gauche et, dans l’écran de préférences qui s’affiche, cocher la case Recevoir des alertes de facturation. Cette opération vous permettra désormais de surveiller l’utilisation de votre compte.

 Cliquez ensuite sur le bouton Sauvegarder les préférences. Mais attention, cette case une fois cochée, vous ne pourrez plus revenir en arrière et annuler cette modification.

 Cliquez maintenant sur le lien Gérer les alertes de facturation. Le nouvel écran qui s’affiche vous permet de créer votre première alarme de facturation. 

 Dans l’écran Sélectionner une métrique, choisissez EstimatedCharges comme métrique et cliquez sur le bouton Suivant. Vous allez entrer dans la première étape du processus à quatre étapes de configuration de l’alarme. Cette étape s’intitule Indiquer la métrique et les conditions et ici vous pouvez choisir, en plus du nom de la métrique...

Surveillance des volumes de stockage avec des scripts CloudWatch

Bien que CloudWatch fasse un travail formidable lorsqu’il s’agit de la surveillance de vos instances EC2 et leur état, tout n’est pas parfait dans ce bas monde. Pour donner juste quelques exemples, CloudWatch surveille l’utilisation CPU par des instances EC2, mais pas sa charge de travail proprement dite. De la même manière, on peut surveiller les performances de la mémoire RAM ou des entrées-sorties des disques de stockage, mais on ne peut pas savoir exactement quelle est la taille de la mémoire utilisée ou celle des partitions des disques. Il y a évidemment de bonnes raisons à tout ça et, sans trop entrer dans les détails, ces raisons ont à voir avec l’architecture d’ensemble de CloudWatch et de sa dépendance par rapport aux hyperviseurs Xen qui constitue un de ses composants fondamentaux. Mais heureusement, CloudWatch est ainsi conçu pour pouvoir accepter des métriques à partir de sources alternatives que son hyperviseur Xen.

Dans ce chapitre on va utiliser un ensemble de scripts en Perl fournis par AWS pour être utilisés avec CloudWatch. Ceux-ci doivent d’abord être installés dans les instances EC2 faisant l’objet de la surveillance et, une fois installés, ils créent des métriques personnalisées, comme on le verra tout de suite.

La surveillance des fichiers journaux avec CloudWatch Logs

CloudWatch Logs est un ensemble fonctionnel séparé qui permet, comme son nom le suggère sans équivoque, la surveillance de fichiers journaux. Si vous avez été confronté à un environnement d’exécution où tournent une douzaine de serveurs web, de bases de données, d’applications ou de daemons en tout genre, alors vous comprenez à quel point la capacité de surveillance de tout ce beau monde via leurs propres fichiers journaux est importante. C’est précisément la valeur ajoutée que CloudWatch Logs vous apporte.

Dans cette section on va mettre en place la surveillance automatique, par CloudWatch Logs, d’un serveur web Apache HTTP Server via son fichier journal. Mais d’abord expliquons quelques notions de base.