Une autre nouveauté est apparu récemment en “preview” sur le portail Windows Azure pour venir tenir compagnie au tout frais AutoScaling : le système d’alerte. Celui-ci permet de disposer d’un mécanisme extrêmement simple à configurer qui permet aux administrateurs du portail d’être notifié en cas de soucis sur ses services / machines hébergés par Azure.

Comment cela fonctionnait avant?

Le besoin d’être notifié en cas de surconsommation de ressource a toujours existé dans Azure (ou sur tout autre environnement).

Jusqu’à présent, le meilleur moyen d’être alerté en cas de soucis était de :

• Activer dans les services hébergés le système de diagnostic pour consolider les compteurs de performance dans un compte de stockage Azure.
• Utiliser un outil pour aller régulièrement consulter ces compteurs …
• … ou bien d’écrire un Worker Rôle utilisant l’API de Diagnostic pour surveiller en boucle ce log centralisé et d’alerter (par email par exemple) un administrateur en cas de soucis

Qu’est-ce que ce nouveau service?

Le système d’alertes est transverse à l’ensemble des services d’hébergement Azure. De ce fait, son utilisation s’effectue depuis le module “paramètres” du portail Azure. Il permet de reproduit une partie du scénario précédant en quelques clics.

Depuis l’onglet Alertes, il est possible de consulter les alertes levées par les règles actives ou d’ajouter / modifier / activer / désactiver des règles de monitoring.

La configuration d’une règle s’effectue en saisissant les champs suivants :

• Nom : Le nom de l’alerte qui apparaitra dans la liste principale
• Description : Un peu plus d’informations pour qualifier la règle
• Subscription : le nom de l’abonnement Azure à laquelle appartient la règle
• Type de service : le type de service d’hébergement d’Azure à surveiller, entre Service de Cloud Computing (service hébergé / PaaS), Machine Virtuelle (IaaS), Site Web ou Service Azure Mobile
• Nom du service : le service à surveiller, parmi ceux créés sur l’abonnement
• (Différent en fonction du type de service) : L’instance du service à surveiller, par exemple, le nom du déploiement et le rôle pour les services hébergés

Une fois le service à surveiller sélectionné, il reste, dans le deuxième onglet, à définir la règle en tant que tel, au travers des options suivantes :

• Métrique : la métrique à surveiller, parmi : Pourcentage CPU, Accès disques en lecture / écriture, Bande passante consommée entrante / sortante, et, pour les machines virtuelle, le temps d’activité et le temps de réponse
• Condition / valeur de seuil : la valeur à partir de laquelle l’alerte va se déclencher
• Fenêtre d’évaluation d’alerte : la durée d’évaluation avant de lever une alerte. Par exemple, si la valeur saisie est “moyenne sur les 5 dernières minutes” et qu’une alerte doit se déclencher dans le cas ou le CPU est supérieur à 50%, l’alerte ne sera levée que si la moyenne totale de consommation de CPU est supérieure à 50% sur les 5min. Ceci évite de lever des alertes pour des micro pics de dépassement de seuil.
• Actions : le mode de notification – soit par Email aux administrateurs du service Azure, soit en saisissant un nouvel Email

Une fois la règle créée et activée, le système se met en mode analyse.

L’interface générale permet de consulter d’un œil toutes les règles et de pouvoir filtrer parmi celle-ci afin de mettre en évidence les alertes récemment levées.

L’interface de détail de l’alerte permet quant à elle de consulter l’historique des alertes levées, de disposer d’un graphique sur 1 heure / 24 heures / 7 jours qui affiche la valeur du compte surveillé ainsi que le seuil d’alerte.

Enfin, quand le seuil est franchit, un Email de notification est bien instantanément envoyé !

Et voilà, encore une bonne nouvelle fonctionnalité !

Comme pour l’autoscaling, cette fonctionnalité permet de répondre simplement à une majorité des besoins de “surveillance et de notification”. Pour aller encore plus loin, notamment en terme de type d’alerte (SMS par exemple) ou de compteur de performance à surveiller (espace disque, log applicatif), il reste bien sur possible et intéressant de continuer à développer son propre agent de monitoring.