Beaucoup de projets d’infrastructure Cloud contiennent des services Cloud de type IaaS. Entièrement configurable, une machine virtuelle en est un bon exemple chez tous les principaux fournisseurs de Cloud. Le IaaS apporte des avantages par une grande flexibilité, mais aussi des inconvénients, comme par exemple sa gestion des mises à jour.
Dans le cadre d’un hébergement d’un service web, la machine virtuelle n’est d’ailleurs pas le premier choix proposé par les fournisseurs Cloud. Néanmoins, il arrive qu’une machine virtuelle soit le seul choix technique possible.
Dans cet article, nous n’allons pas nous intéresser au choix VM / App Service. Mais à la mise en place d’une alerte de disponibilité HTTP, dans le but vérifier le bon fonctionnement de l’accès externe.
Que sont les alertes d’Azure Monitor ?
Les alertes vous permettre de détecter et de résoudre des problèmes avant que les utilisateurs ne les remarquent en vous informant de manière proactive quand les données Azure Monitor indiquent qu’il peut y avoir un problème avec votre infrastructure ou votre application.
Vous pouvez définir une alerte sur n’importe quelle source de données de métrique ou de journal dans la plateforme de données Azure Monitor.
Microsoft Learn
Il est très facile de créer une alerte sur un Web App. Mais il est aussi possible d’en créer sur d’autres services, comme sur un service IIS hébergé sur une machine virtuelle.
Afin des tester ce scénario, nous allons créer une machine virtuelle avec un rôle IIS afin de créer une alerte HTTP pour vérifier sa bonne disponibilité à travers le globe :
- Etape 0 – Rappel des prérequis
- Etape I – Création de la machine virtuelle Azure
- Etape II – Installer un rôle IIS sur votre machine virtuelle
- Etape III – Configuration du test de disponibilité HTTP
- Etape IV – Vérification du test de disponibilité HTTP
- Etape V – Configuration des alertes de disponibilité
- Etape VI – Test de la notification d’alerte
Etape 0 – Rappel des prérequis :
Pour réaliser cet exercice sur les alertes d’Azure Monitor, il vous faudra disposer de :
- Un tenant Microsoft
- Une souscription Azure valide
Si vous ne disposez pas de machine virtuelle Azure sur votre environnement, commencez par l’étape I afin de préparer l’environnement nécessaire à la mise en place de l’alerte.
Etape I – Création de la machine virtuelle Azure :
Commencez par créer une Machine Virtuelle Azure en utilisant la barre de recherche en haut du portail :
Sélectionnez le premier choix pour créer votre machine virtuelle :
Sur le premier onglet, renseignez les champs relatifs aux principales caractéristiques de votre VM :
Définissez un compte d’administrateur local, ouvrez le port HTTP pour le traffic entrant, puis cliquez sur Suivant :
Cliquez sur Suivant pour continuer la configuration :
Vérifiez sur cet onglet que le port HTTP est toujours listé, puis cliquez-ici pour lancer la validation de la configuration :
Une fois la validation correctement terminée, cliquez sur Créer :
Environ 3 minutes plus tard, votre machine virtuelle est créée et est accessible.
Cliquez-ici pour rentrer dans la configuration de votre VM :
Copiez l’adresse IP publique de votre machine virtuelle :
Ouvrez un nouvel onglet dans votre navigateur, puis collez l’adresse IP publique précédemment copiée :
Le message d’erreur affiché s’explique par l’absence d’écoute sur le port 80 (HTTP) de votre machine virtuelle.
Pour y remédier, nous allons installer le rôle IIS (Internet Information Services) sur votre machine virtuelle.
Etape II – Installer un rôle IIS sur votre machine virtuelle :
Comme aucun port RDP n’est ouvert sur la machine virtuelle, utilisez le menu suivant pour lancer le script d’installation de IIS depuis le portail Azure :
Collez la commande ci-dessous :
Install-WindowsFeature -name Web-Server -IncludeManagementToolsLancez le script, puis attendez que celui-ci se termine :
Environ 2 minutes plus tard, constatez la bonne exécution du script :
Dans l’onglet précédemment ouvert avec l’adresse IP publique de votre machine virtuelle, rafraichissez la page web, puis constatez l’apparition de la page d’accueil de IIS :
Notre environnement est maintenant en place, il ne nous reste qu’à installer le mécanisme d’alerte. Avant cela, il est nécessaire d’ajouter d’autres composants Azure.
Etape III – Configuration du test de disponibilité HTTP :
Sur votre portail Azure, commencez par rechercher le service Application Insights :
Créez votre premier application Insights :
Renseignez tous les champs, également ceux concernant la création d’un Log Analytics Workspace, puis lancez la validation :
Une fois validation terminée, lancez le processus de création des ressources :
Environ 3 minutes plus tard, cliquez-ici pour configurer votre Application insights :
Cliquez-ici pour ajouter votre test HTTP :
Renseignez les informations demandées, ainsi que l’adresse IP publique de votre VM au format HTTP://, puis choisissez la fréquence et les régions Azure dont le signal de test doit provenir :
Le test est maintenant en place
Etape IV – Vérification du test de disponibilité HTTP :
Attendez environ 2 minutes, puis cliquez sur Rafraichir :
Les premiers succès de réponse apparaissent :
- A droite se trouvent des compteurs de succès et d’échecs
- Le détail par région source est affiché en bas
- Un graphique avec un taux de disponibilité est présent en haut à gauche
Un tour dans les logs de notre Application Insights affiche bien toutes les informations stockées par chaque test :
Toutes ces informations bien pratiques, mais les administrateurs IT doivent aussi être alertés quand le service HTTP est en panne. Il est donc nécessaire de mettre en place une règle d’alerte pour les avertir au plus tôt.
Un mail sur une messagerie surveillée est une bonne pratique.
Etape V – Configuration des alertes de disponibilité :
Toujours dans votre Application Insights, rendez-vous dans la section des alertes pour modifier la règle d’alerte déjà en place :
Cliquez sur la règle d’alerte portant le nom combo « alerte »-« Application Insight » :
Cliquez ensuite sur Editer :
Sous la section Actions, cliquez-ci dessous :
Cliquez-ici pour créer un groupe d’actions :
Nommez-le, puis passer sur l’onglet suivant :
Dans l’onglet Notifications, définissez un type de notification Email, puis nommez-le également :
Renseignez une adresse email à cibler :
Cliquez sur Créer votre groupe d’actions :
Sauvegardez votre règle d’alerte :
Attendez quelques secondes, puis constatez la bonne modification de celle-ci :
Quelques secondes après, le destinataire du groupe d’actions reçoit un email lui informant son intégration dans un système de règle d’alerte Azure :
Il ne nous reste plus qu’à tester la notification par email. Pour cela, rien de plus simple, un arrêt de la machine virtuelle Azure devrait suffire.
Etape VI – Test de la notification d’alerte :
Avant d’arrêter votre machine virtuelle, vérifier la bonne santé du test de disponibilité de votre HTTP :
Retournez sur la page des machines virtuelles, puis déclenchez un arrêt de celle-ci :
Confirmez la procédure d’arrêt :
Retournez sur l’onglet internet ouvert sur l’adresse IP publique de votre machine virtuelle, puis constatez l’apparition d’un message d’indisponibilité :
Retournez sur le test d’alerte de votre Application Insights, les premiers échecs devraient apparaître.
Notez que la notion de 5 minutes entre deux tests ne s’applique que pour chaque région Azure. C’est donc pour cela que les tests sont très fréquents, car le test de disponibilité repose ici sur 5 régions :
Une fois que 2 localisations sur 5 constatent des échecs, l’alerte est déclenchée et le mail est envoyé sur l’adresse de message renseignée sur le groupe d’actions :
Consultez le détail de cette alerte :
Retournez sur la page des machines virtuelles, puis redémarrez la VM précédemment éteinte :
Quelques minutes plus tard, un autre email arrive sur la boite de messagerie. Celui-ci indique une bonne reprise de la disponibilité sur les régions concernées :
De retour sur la page des alertes de notre Applications Insights, l’alerte n’y figure plus car elle a été automatiquement levée :
Il est malgré tout possible de retrouver l’historique de cette alerte en retirant un filtre :
Conclusion :
L’architecture Cloud n’est pas infaillible et la mise en place d’alerte permet de gérer au plus tôt un incident. Ce type de règle alerte ne coûte pas cher et permet de centraliser l’information sur un seul point. Un autre test intéressant serait de créer une alerte sur la charge d’une machine virtuelle ou d’un autre service de calcul.
