Supervision de Microsoft Azure

Commencez par enregistrer une application dans Azure. Cette application sera utilisée par Checkmk pour lire les données souhaitées depuis Azure. Vous trouverez cette option dans le portail Azure sous « (All services > Identity > Identity management > ) App registrations ». Vous pouvez également utiliser la recherche du portail et saisir « App registrations ». Une fois sur la page, vous devez cliquer sur « New registration ».

Attribuez un nom d'identification de votre choix. Dans l'exemple, nous utilisons my-checkmk-app. Ce nom est toutefois uniquement à titre informatif. La référence à l'application se fait plutôt via l'ID d'application, que vous verrez à l'étape suivante. Vous n'avez rien à modifier dans la section Supported account types et le champ Redirect URI doit rester vide. Confirmez vos saisies en cliquant sur « Register ».

Une fois l'application créée, vous devriez voir un aperçu de cette nouvelle application. Si ce n'est pas le cas, vous trouverez la nouvelle application dans la liste de toutes les applications décrites ci-dessus, sous l'onglet « All applications ». Dans les détails de l'application, vous trouverez désormais à la fois l'Application (client) ID et l'Directory (tenant) ID, que vous devrez saisir ultérieurement dans Checkmk.

Vous aurez ensuite besoin d’un secret client permettant à Checkmk de se connecter à l’API Azure. Pour générer ce secret, cliquez sur « Certificates & secrets » dans l’aperçu de l’application, puis sur l’onglet « Client secrets » et enfin sur « New client secret ».

La boîte de dialogue « Add a client secret » s’ouvre alors. Attribuez-lui un nom de votre choix et sélectionnez la durée de validité de la clé. Si vous activez ultérieurement l’option « App Registrations » dans la règle de l’agent spécial, vous bénéficierez d’un service pratique qui vous rappellera lorsque cette période de validité touche à sa fin. Confirmez le dialogue en cliquant sur « Add ».

Il est important que vous copiez immédiatement le contenu de l'Valuee dans ce nouveau secret, car après un certain temps, seuls les trois premiers caractères de ces secrets s'afficheront dans le portail Azure.

Vous devez accorder à l'application des autorisations API supplémentaires si vous souhaitez effectuer la supervision des services suivants avec Checkmk :

Vous commencez à attribuer les autorisations dans l'aperçu de votre nouvelle application, que vous devriez toujours avoir ouvert depuis la section précédente.

Cliquez sur « API permissions », puis sur « Add a permission. ». Dans le dialogue qui s'ouvre, vous devez rechercher et cliquer sur « Microsoft Graph ». Sélectionnez ensuite « Application permissions » et saisissez « Directory.Read.All » dans le champ de recherche. Cochez la case à cocher correspondante et cliquez sur « Add permissions ». Une autorisation supplémentaire de la part d'un administrateur de votre environnement Azure est requise pour cette autorisation (Admin consent required). Si vous ne voyez pas le bouton « Grant admin consent » au-dessus de la liste des autorisations accordées, vous devez contacter l'administrateur responsable.

Pour permettre à Checkmk d’accéder aux données de supervision via la nouvelle application, vous devez attribuer un rôle à l’application au niveau de l’abonnement. Pour ce faire, sélectionnez « All services » dans le menu de navigation principal à gauche, puis, sous « General », l’entrée « Subscriptions ». Là encore, vous pouvez utiliser la fonction de recherche du portail si vous ne trouvez pas le bouton correspondant.

Si vous disposez de plusieurs abonnements, vous devez maintenant cliquer sur le nom de l'abonnement que vous souhaitez superviser. Vous serez alors redirigé vers une page d'aperçu de votre abonnement. Notez l'Subscription ID qui y figure. Vous devrez la saisir ultérieurement dans la règle d'agent spécial.

Cliquez ensuite sur « Access Control (IAM) », puis sur « Add » et enfin sur « Add role assignment: ».

Sélectionnez maintenant le rôle nommé « Reader » et associé à l’Type « BuiltInRole ». Comme il existe au total plus de 100 rôles dont le nom contient le mot « Reader », il est important d’être vigilant à ce stade. Cliquez ensuite sur « Next » pour accéder à l’onglet « Members ».

Cliquez ici sur « + Select members. »

Dans le dialogue « Select members », saisissez le nom de l’application que vous avez créée précédemment dans le champ de recherche, sélectionnez cette application, puis cliquez sur « Select. » Après deux clics supplémentaires sur « Review + assign », la configuration dans le portail Azure sera terminée.

Même si vous n’avez pas affaire à un ordinateur hôte dans Azure, créez un hôte pour votre répertoire Azure dans Checkmk. Vous pouvez définir le nom de domaine à votre guise. Important : Azure étant un service et ne disposant donc pas d’adresse IP ni de nom DNS (l’agent spécial se charge lui-même de l’accès), vous devez définir l’IP address family sur No IP.

Il est préférable d'enregistrer avec l'Save & view folder à ce stade, car bien sûr, la reconnaissance du service ne peut pas encore fonctionner.

Étant donné qu’Azure ne peut pas être interrogé via l’agent Checkmk standard, vous devez maintenant configurer l’agent spécial Azure. Dans ce cas, Checkmk ne contacte pas l’ordinateur hôte cible via le port TCP 6556 comme d’habitude, mais appelle un utilitaire qui communique avec le système cible via l’API spécifique à l’application d’Azure.

Pour ce faire, sous « Setup > Agents > VM, cloud, container > Microsoft Azure », créez une règle dont les conditions s’appliquent exclusivement à l’ordinateur hôte Azure qui vient d’être créé. Vous y trouverez les champs de saisie pour les identifiants et le secret :

Vous pouvez également sélectionner ici les groupes de ressources ou les ressources que vous souhaitez superviser. Si vous n’avez pas checké « explicitly specified groups », tous les groupes de ressources sont automatiquement supervisés.

Si vous effectuez maintenant une reconnaissance du service sur l'ordinateur hôte Azure, le service appelé Azure Agent Info devrait au moins être détecté :

Si l'accès à l'API ne fonctionne pas (en raison d'un identifiant incorrect, d'autorisations inappropriées ou d'un secret client erroné, comme dans l'exemple ci-dessous), un message d'erreur correspondant s'affichera dans le texte d'état de Azure Agent Info :

Pour plus de clarté, la supervision Azure dans Checkmk a été conçue de manière à ce que chaque groupe de ressources Azure soit représenté par un hôte logique (pour ainsi dire) dans Checkmk. Ceci est réalisé à l’aide du mécanisme de ferroutage. Ce ferroutage récupère les données de l’hôte Azure à l’aide d’agents spéciaux, puis les redirige au sein de Checkmk vers ces hôtes de groupes de ressources.

Les hôtes de groupes de ressources n’apparaissent pas automatiquement dans Checkmk. Ajoutez ces hôtes manuellement ou, si vous le souhaitez, à l’aide de la gestion dynamique des hôtes. Important — lors de cette opération, les noms des hôtes doivent correspondre exactement aux noms des groupes de ressources — et cela tient compte de la casse ! Si vous n’êtes pas certain de l’orthographe exacte des noms des groupes, vous pouvez effectuer cette opération directement à partir du service Azure Agent Info sur l’hôte Azure.

Configurez les hôtes du groupe de ressources sans adresse IP (à l'instar de l'hôte Azure), puis sélectionnez No API integrations, no Checkmk agent comme agent et Always use and expect piggyback data comme hôte ferrouté.

Si vous effectuez maintenant une reconnaissance du service sur l'un de ces ordinateurs hôtes du groupe de ressources, vous constaterez qu'il existe des services supplémentaires spécifiquement liés à ce groupe de ressources :

Lorsque vous utilisez Azure pour superviser des machines virtuelles qui servent simultanément d’hôtes normaux dans Checkmk, vous pouvez attribuer les services Azure associés à ces VM directement aux hôtes de VM dans Checkmk plutôt qu’aux hôtes du groupe de ressources.

Pour ce faire, dans la règle Azure, sous l’option «Map data relating to VMs», sélectionnez le paramètre «Map data to the VM itself». Pour que cela fonctionne, l’ordinateur hôte Checkmk de la VM en supervision doit porter exactement le même nom que la VM correspondante dans Azure.

La règle « Microsoft Azure » est prédéfinie de manière à ce que Checkmk effectue également la supervision de tous les coûts engagés dans votre environnement Azure. Plus précisément, les services affichent les coûts engagés la veille. Vous pouvez ainsi déterminer rapidement s’il y a eu des changements.

Plusieurs services sont créés afin d’obtenir un meilleur aperçu des coûts engagés et de pouvoir définir des valeurs seuils spécifiques. Les coûts totaux au niveau de votre répertoire Azure s’affichent pour l’hôte Azure que vous avez créé en premier. De plus, des services sont créés pour chaque hôte représentant un groupe de ressources. À ces deux niveaux, Checkmk génère un service pour les coûts par « fournisseur de ressources » (par exemple microsoft.compute et microsoft.network). Le service « Costs Summary » affiche ensuite la somme totale pour le groupe de ressources ou pour l'ensemble du répertoire Azure.

Vous pouvez utiliser la règle Azure Usage Details (Costs) pour définir des valeurs seuils individuelles pour tous ces services.

Si vous ne souhaitez pas effectuer la supervision des coûts, vous devez désactiver l'option « Usage Details » dans la règle « Microsoft Azure ».

Par défaut, Checkmk importe toutes les balises de votre environnement Azure et les convertit en étiquettes d’hôte et de service. L’affectation s’effectue comme prévu. Les balises associées à un groupe de ressources sont attribuées dans Checkmk à l’hôte représentant ce groupe de ressources, et les balises d’une machine virtuelle deviennent des étiquettes d’hôte pour cette machine virtuelle.

Toutes les étiquettes ainsi créées reçoivent le préfixe cmk/azure/. De plus, les caractères et les valeurs qui entraîneraient des étiquettes non valides dans Checkmk sont remplacés. Les valeurs vides (c'est-à-dire le champ « Value » dans Azure) sont remplacées par true et les deux-points présents dans le nom ou la valeur sont remplacés par un trait de soulignement.

L'option « Filter tags imported as host/service labels » vous permet de contrôler l'importation des balises depuis Azure. Si vous cochez cette case à cocher, vous pouvez empêcher complètement l'importation avec Do not import tags. Si vous sélectionnez Filter valid tags by key pattern ici, vous pouvez saisir une expression régulière dans le champ suivant. Checkmk ne générera alors des étiquettes qu'à partir des balises correspondant à cette expression régulière.

Actuellement, les requêtes API dont Checkmk a besoin pour la supervision d’Azure (contrairement à AWS) sont gratuites — il existe toutefois une limite au nombre de requêtes autorisées par période de temps (« limite de débit »). À ce jour, les requêtes API dont Checkmk a besoin pour la supervision sont gratuites avec Azure (contrairement à AWS). Il existe toutefois une limite au nombre de requêtes par période de temps (« limites de débit »).

En raison de la structure de l’API, Checkmk nécessite au moins une ou plusieurs requêtes par ressource demandée. Par conséquent, le nombre total de requêtes évolue linéairement avec le nombre de ressources sous supervision. Si la limite de requêtes est atteinte ou dépassée, la requête échoue avec un code HTTP 429 (trop de requêtes), et le service d’Check_MKs pour l’ordinateur hôte Azure est signalé comme « CRIT ».

Cette limite résulte de l’algorithme dit « token bucket » d’Azure. Tout commence par un « crédit » de 250 requêtes restantes — chaque requête en consomme une. Simultanément, 25 requêtes par seconde sont ajoutées au crédit. La sortie du service Azure Agent Info vous permet de voir combien de requêtes il reste actuellement.

Concrètement, cela signifie que :

Dans ce cas, vous pouvez réduire le taux d'interrogation en interrogeant moins de groupes de ressources ou de ressources, ou en réduisant l'intervalle de vérification pour la vérification active d'Check_MK sur l'ordinateur hôte Azure. Cela est possible grâce à la règle Normal check interval for service checks.

Afin que vous puissiez réagir à temps, le service Azure Agent Info effectue la supervision du nombre de requêtes restantes. Par défaut, aucune valeur seuil n'est définie. Vous pouvez les définir vous-même dans la règle Azure Agent Info.

L'article « Comprendre comment Azure Resource Manager limite les requêtes » sur Microsoft Learn explique cela plus en détail.