Installation depuis Azure Marketplace

Si vous êtes un utilisateur d’Azure, vous avez toujours eu la possibilité d’ajouter Checkmk à une image Ubuntu existante disponible sur le Marketplace, afin de mettre en place une « supervision dans le cloud ». Nous allons désormais plus loin en proposant une image préinstallée, basée sur Ubuntu 22.04 (Jammy Jellyfish), avec toutes les dépendances requises déjà incluses. Seule la version Checkmk Ultimate est utilisée dans ce scénario. Celui-ci sera sous statut de licence « Trial » de 30 jours sans aucune restriction lors de la configuration du premier site. À l’expiration de la période de test, Checkmk peut continuer à être utilisé en tant que instance unique avec jusqu’à 750 services surveillés sans nécessiter d’abonnement. Si davantage de services doivent être surveillés, ou si plusieurs instances sont requises, vous aurez besoin d’une clé de licence.

En général, la configuration est un peu plus complexe que, par exemple, celle d’une image Docker ; après tout, l’image fournie doit couvrir divers scénarios de déploiement :

C'est pourquoi l'image Azure ne comprend pas d'instance prête à l'emploi, ni de configuration de courrier électronique ou de pare-feu.

Dans cet article, nous vous guiderons tout au long de la configuration complète. Lorsque des informations complémentaires sont utiles, nous vous renvoyons vers des articles détaillés de notre guide de l'utilisateur.

Étant donné qu'Azure ne prend actuellement pas en charge les clés ED25519 ou ECDSA, vous devrez créer une paire de clés RSA pour le premier login à la machine virtuelle (VM), dont vous téléchargerez la clé publique lors de la création de la VM. Vous pouvez également laisser Azure créer la paire de clés. Dans ce cas, n'oubliez pas de télécharger la clé privée lors du processus de commande.

Dans une configuration Checkmk à instance unique, où les ordinateurs hôtes envoient également des données à l'instance Checkmk en mode Push, les ports suivants du serveur Checkmk doivent être accessibles :

Le partage de ces ports est prédéfini dans notre configuration « Inbound port rules ». Pour une sécurité optimale, vous devriez restreindre davantage l'accès dans l'onglet « Networking ».

Consultez notre aperçu de tous les ports utilisés si vous souhaitez mettre en place une supervision distribuée ou, par exemple, effectuer des requêtes d'état via l'interface Livestatus.

Les instances de VM suivantes constituent une recommandation pour le dimensionnement du nombre de services à soumettre à la supervision. Lors de la commande de l'instance, désactivez l'option « burstable ».

Ces calculs de dimensionnement se basent sur environ 15 % de services assurés par des agents spéciaux et des contrôles actifs, ainsi que sur 25 services ou plus par ordinateur hôte fourni via un agent en mode Push. Dans certaines circonstances, un nombre nettement plus élevé de services est possible dans le cadre d’une supervision purement synthétique (dans laquelle les données sont principalement fournies par des agents spéciaux). Lors de l’utilisation d’agents en mode Pull, le nombre de services spécifié ne peut être atteint que grâce à une optimisation constante.

Le dimensionnement de l'espace disque dur repose sur l'expérience acquise dans des environnements de serveurs Windows et Linux classiques. Si de nombreux services génèrent un volume important de métriques, un espace de stockage plus important peut s'avérer nécessaire.

En raison des coûts de trafic avantageux, nous vous recommandons d’utiliser Azure Blob Storage. Pour le calcul de l’espace de stockage requis, veuillez consulter les remarques concernant le format de données RRD. À titre indicatif pour le calcul d’une sauvegarde complète, les bases de données tourniquet auront atteint un peu plus d’un tiers de leur capacité maximale après 10 jours. Cela signifie qu’après ce délai, il est judicieux de réexaminer la taille de l’espace de stockage de sauvegarde qui a été réservé.

Le login en tant qu'utilisateur root est désactivé sur les images AWS/Azure. À la place, l'utilisateur ubuntu est utilisé ; celui-ci dispose des autorisations nécessaires pour exécuter sudo avec des instructions arbitraires sans invite de mot de passe. Si vous avez créé une paire de clés distincte pour vous connecter à la machine virtuelle (VM), vous devez spécifier le chemin d'accès à sa clé privée à l'aide du paramètre -i. Bien entendu, l'adresse IP doit être remplacée par celle sous laquelle la machine virtuelle (VM) est accessible à distance :

Vous vous trouvez désormais à l'invite de l'utilisateur ubuntu. L'invite réelle peut contenir le nom de domaine spécifié lors de la création de la VM ou une adresse IP en tant que nom de domaine. Nous utiliserons le nom de domaine cloud tout au long du reste de cet article :

Une instance Checkmk doit avoir un nom unique et être facilement identifiable. Ici, comme dans la plupart des autres sections de ce manuel, nous utilisons mysite comme nom d'instance. Dans cet exemple, le mot de passe de l'administrateur de l'instance cmkadmin est défini sur t0p53cr3t.

La création d'une instance s'effectue à l'aide de l'outil d'administration Checkmk omd. La dernière version de Checkmk est toujours préinstallée :

Démarrez maintenant l'instance nouvellement créée avec

L'URL figurant dans la sortie d'instruction ci-dessus (http://cloud/mysite) contient le nom de domaine utilisé en interne par votre machine virtuelle AWS ou Azure. Comme elle n'est généralement pas résolue en externe, cette URL a une utilité limitée. En règle générale, vous y accéderez initialement à l'aide de l'adresse IP ou d'un nom de domaine stocké sur votre propre serveur DNS.

Pour que le système Apache puisse effectivement écouter sur le port HTTPS 443, il aura besoin de certificats valides. Les certificats auto-signés de Snakeoil Inc. sont générés à cette fin lors du premier démarrage de la machine virtuelle. Nous vous recommandons vivement de les remplacer dès que possible par vos propres certificats, qui permettent de vérifier facilement la chaîne de certificats complète.

Ce faisant, la configuration d'Apache suit de près les normes Ubuntu, et les chemins d'accès aux certificats modifiés doivent être saisis dans le fichier `/etc/apache2/sites-enabled/000-default.conf`.

Étant donné que les chemins d'accès pour les notifications dans Checkmk sont nombreux et peuvent varier, aucun système de courrier électronique par défaut n'est prédéfini.

Checkez régulièrement la page de téléchargement pour vérifier la disponibilité de mises à jour et téléchargez le paquet mis à jour à l'aide de l'instruction wget qui y est indiquée.

L'installation d'une mise à jour s'effectue en deux étapes, car omd peut gérer plusieurs instances, chacune avec une version différente de Checkmk, sur le même serveur.

Checkmk dispose d'une fonction de sauvegarde pratique, qui se configure sous « Setup > Maintenance > Backups > Backup targets ». Sous « Add backup target », vous ajoutez un emplacement de stockage. Il est conseillé de sélectionner « Azure Blob Storage » comme Destination en raison de la rapidité et du faible coût du transfert de données.

Outre les informations d'identification, vous devez également spécifier un chemin d'accès au dossier où l'archive est stockée temporairement avant d'être copiée vers le magasin d'objets. Cela peut se faire sous /tmp. Si votre machine virtuelle Azure fournit un disque volatile (éphémère) sous /mnt, vous pouvez également y créer un répertoire servant de cache :

Pour que l'utilisateur de l'instance puisse écrire dans ce répertoire, vous devez le lui transférer :