Supervision distribuée

Livestatus est une interface intégrée au noyau de supervision qui permet à d’autres programmes externes d’interroger les données d’état et d’exécuter des instructions. Livestatus peut être mis à disposition sur le réseau afin d’être accessible depuis une instance Checkmk distante. L’interface utilisateur de Checkmk utilise Livestatus pour regrouper toutes les instances en un aperçu, qui ressemble alors à un seul et même grand système de supervision.

Le schéma suivant illustre la structure d’une supervision avec Livestatus répartie sur trois sites. L’instance centrale Checkmk se trouve sur le site de traitement central. C’est à partir de là que les systèmes centraux seront directement contrôlés. De plus, il existe l’instance distante 1 et l’instance distante 2, qui sont situées sur d’autres réseaux et contrôlées par leurs systèmes locaux :

Ce qui rend cette méthode particulière, c’est que l’état de supervision des instances distantes n’est pas envoyé en continu vers l’instance centrale. L’interface graphique ne récupère les données en temps réel depuis les instances distantes que lorsque cela est demandé par un utilisateur du poste de contrôle. Les données sont ensuite compilées dans une vue centralisée. Il n’y a donc pas de stockage centralisé des données, ce qui offre d’énormes avantages pour la mise à l’échelle !

Voici quelques-uns des avantages de cette méthode :

Dans un système distribué utilisant Livestatus comme décrit ci-dessus, il est tout à fait possible que les instances individuelles soient gérées indépendamment par différentes équipes, et que l’instance centrale ait pour seule tâche de fournir un tableau de bord centralisé.

Dans le cas où plusieurs sites, voire tous, doivent être administrés par la même équipe, une configuration centralisée est beaucoup plus facile à gérer. Checkmk prend en charge cette approche et désigne une telle configuration sous le nom de « configuration centralisée ». Dans ce cas, tous les ordinateurs hôtes et services, les utilisateurs et autorisations, les périodes de temps, les notifications, etc., seront gérés dans l’Setup de l’instance centrale, puis automatiquement distribués aux instances distantes selon vos spécifications.

Un tel système offre non seulement un aperçu commun de l’état, mais aussi une configuration commune, et donne effectivement « l’impression d’un grand système ».

Vous pouvez même étendre ce système avec, par exemple, des instances de la visionneuse dédiées qui servent uniquement d’interfaces de suivi d’état pour des sous-domaines ou des groupes d’utilisateurs spécifiques.

Aucune exigence particulière n'est imposée à l'instance centrale. Cela signifie qu'une instance existante de longue date peut être étendue à une supervision distribuée en ne nécessitant qu'une seule modification — nécessaire pour la gestion correcte des données ferroutées. Il vous suffit d'activer le hub ferroutage sur la page de configuration Setup > General > Global settings dans la section «Site management» :

Activez ensuite les modifications, car l'activation ou la désactivation du hub de ferroutage nécessite le redémarrage de l'instance.

Les instances distantes sont ensuite générées comme de nouvelles instances de la manière habituelle via omd create. Cette opération s'effectue naturellement sur le serveur (distant) destiné à l'instance distante concernée.

Remarques particulières :

Voici un exemple de création d'une instance distante nommée myremote1 avec le mot de passe t0p53cr3t pour l'administrateur de l'instance cmkadmin :

Les étapes les plus importantes consistent désormais à activer Livestatus via TCP pour le réseau et à activer également le hub de ferroutage ici. Notez que Livestatus n’est pas en soi un protocole sécurisé et ne doit être utilisé que dans un réseau sécurisé (LAN sécurisé, VPN, etc.). L’activation s’effectue en utilisant omd config en tant qu’utilisateur de l’instance alors que l’instance est arrêtée :

Sélectionnez maintenant Distributed Monitoring :

Définissez LIVESTATUS_TCP sur on , et pour LIVESTATUS_TCP_PORT, entrez un numéro de port non attribué qui soit unique sur ce serveur. La valeur par défaut est 6557 :

Après avoir enregistré, démarrez l'instance comme d'habitude avec omd start :

Mémorisez le mot de passe pour cmkadmin. Vous n'en aurez besoin que deux fois : d'abord pour activer le hub de ferroutage, puis pour établir la connexion entre l'instance distante et l'instance centrale. Une fois que l'instance distante aura été subordonnée à l'instance centrale, tous les utilisateurs seront de toute façon remplacés par ceux de l'instance centrale.

L'instance est désormais prête. Un check avec netstat montre que le port 6557 est ouvert. La connexion à ce port s'effectue avec une instance du superserver internet xinetd, qui s'exécute directement sur le site :

Connectez-vous maintenant une fois à l'instance distante en tant qu'utilisateur cmkadmin et activez le hub de ferroutage à l'aide des paramètres Setup > General > Global dans la section Site management :

Appliquez ensuite les modifications, car l'activation ou la désactivation du hub de ferroutage nécessite le redémarrage de l'instance.

La configuration de la supervision distribuée s'effectue exclusivement sur l'instance centrale dans le menu Setup > General > Distributed monitoring, qui sert à gérer les connexions vers les différents sites. Pour cette fonction, l'instance centrale elle-même est considérée comme une instance et figure déjà dans la liste :

À l'aide de Add connection , définissez maintenant la connexion à la première instance distante :

Dans l’Basic settings, il est important d’utiliser le nom EXACT de l’instance distante — tel que défini avec omd create — comme Site ID. Comme toujours, l’alias peut être défini selon vos besoins et modifié ultérieurement.

Les paramètres de l’Status connection déterminent la manière dont l’instance centrale interroge l’état des instances distantes via Livestatus. L’exemple de la capture d’écran montre une connexion utilisant la méthode Connect via TCP(IPv4). C’est la solution optimale pour des connexions stables avec de faibles niveaux de latence (comme, par exemple, dans un réseau local). Nous aborderons plus tard les paramètres optimaux pour les connexions WAN.

Saisissez ici l’URL HTTP de l’interface web de l’instance distante, sans le check_mk/ à la fin de l’URL. Si vous accédez habituellement à Checkmk via HTTPS, remplacez ici http par https. Vous trouverez de plus amples informations dans l’aide en ligne ou dans l’article consacré à la sécurisation de l’interface web avec HTTPS.

La réplication de la configuration et, par conséquent, l'utilisation de la configuration centrale sont, comme nous l'avons mentionné dans l'introduction, facultatives. Activez la réplication en sélectionnant Push configuration to this site si vous souhaitez configurer l'instance distante à partir de l'instance centrale. Dans ce cas, sélectionnez exactement les paramètres indiqués dans l'image ci-dessus.

Veillez à vérifier quelle adresse Message broker port vous devez spécifier. Pour le savoir, connectez-vous à l’instance distante concernée et exécutez l’instruction omd config depuis la ligne de commande. Accédez à la section Basic. Ici, la variable RABBITMQ_PORT est celle qui vous intéresse.

Il est très important de configurer correctement l’URL of remote site. L’URL doit toujours se terminer par /check_mk/. Une connexion via HTTPS est recommandée, à condition que le serveur Apache de l’instance distante prenne en charge le protocole HTTPS. Celui-ci doit être installé manuellement sur l’instance distante au niveau du système d’exploitation Linux. Pour la Checkmk Appliance, le protocole HTTPS peut être configuré à l’aide de l’interface de configuration Web. Si vous utilisez un certificat auto-signé, vous devrez cocher la case « Ignore SSL certificate errors ».

Une fois le masque enregistré, une deuxième instance apparaîtra dans l'aperçu :

Le statut de supervision de l'instance distante (pour l'instant) vide est désormais correctement intégré. Pour utiliser la configuration centrale, vous avez encore besoin d'un compte Login pour l'instance Checkmk distante. À cette fin, l'instance centrale échange avec l'instance distante un secret de login généré aléatoirement, par l'intermédiaire duquel toutes les communications futures auront lieu. Le compte cmkadmin sur l'instance distante ne sera par la suite plus utilisé.

Dans le formulaire suivant, utilisez comme identifiant cmkadmin et le mot de passe attribué lors de la création de l’instance distante. À ce stade, confirmez que vous souhaitez remplacer les paramètres en cliquant sur «Confirm overwrite».

Un login réussi sera confirmé comme suit :

Si une erreur survient lors du login, cela peut être dû à plusieurs raisons – par exemple :

Les deux premiers éléments de la liste peuvent être facilement vérifiés en appelant manuellement l'URL du site distant dans votre navigateur.

Une fois que tout a fonctionné, lancez Activate Changes. Comme toujours, cela vous mènera à un aperçu des modifications qui n’ont pas encore été activées. Parallèlement, l’aperçu affichera également les états des connexions Livestatus, ainsi que les états de synchronisation des différentes instances dans la configuration centrale :

La colonne « Version » indique la version Livestatus de l’instance concernée. Lorsque vous utilisez le CMC comme noyau de Checkmk (éditions commerciales), le numéro de version du noyau (affiché dans la colonne « ‘Core’ ») est identique à celui de Livestatus. Si vous utilisez Nagios comme noyau (Checkmk Community), c’est le numéro de version de Nagios qui s’affiche ici.

Les icônes suivantes indiquent l'état de réplication de l'environnement de configuration :

Dans la colonne « Status », vous pouvez voir l'état de la connexion Livestatus pour l'instance concernée. Cette information est fournie à titre purement indicatif, car la configuration n'est pas transmise via Livestatus, mais via HTTP. Les valeurs suivantes sont possibles :

Cliquer sur le bouton « » (Synchroniser toutes les instances) Activate on selected sites synchronisera alors toutes les instances et activera les modifications. Cette opération s’effectue en parallèle, de sorte que la durée totale correspond au temps requis par l’instance la plus lente. Ce temps comprend la création d’un snapshot de configuration pour l’instance concernée, la transmission via HTTP, la décompression du snapshot sur l’instance distante et l’activation des modifications.

Important : ne quittez pas la page avant que la synchronisation ne soit terminée sur toutes les instances — quitter la page interrompra la synchronisation.

Une fois votre environnement distribué installé, vous pouvez commencer à l'utiliser. Il vous suffit en fait d'indiquer à chaque ordinateur hôte par quelle instance il doit être supervisé. L'instance centrale est spécifiée par défaut.

L'attribut requis pour cela est « Monitored on site ». Vous pouvez le définir individuellement pour chaque ordinateur hôte. Cela peut bien sûr également être effectué au niveau des dossiers :

L'ajout d'ordinateurs hôtes s'effectue comme d'habitude — mis à part le fait que la supervision ainsi que la reconnaissance du service seront exécutées à partir de l'instance distante correspondante, il n'y a pas de considérations particulières.

Lors de la migration d’ordinateurs hôtes d’une instance vers une autre, il convient de tenir compte de plusieurs points. Ni les données d’état actuelles ni les données historiques de l’ordinateur hôte ne seront transférées. Seule la configuration de l’ordinateur hôte est conservée dans l’environnement de configuration. En effet, c’est comme si l’ordinateur hôte avait été supprimé d’une instance et nouvellement installé sur l’autre instance :

Si la continuité de l'historique est importante pour vous, lors de la mise en place de la supervision, vous devez planifier avec soin quel ordinateur hôte doit être surveillé et depuis quel emplacement.

Pour assurer le chiffrement, Checkmk utilise le programme stunnel ainsi que son propre certificat et sa propre autorité de certification (CA) pour signer le certificat. Ceux-ci seront générés automatiquement et individuellement lors de la création d’une nouvelle instance ; il ne s’agit donc pas de CA ou de certificats statiques prédéfinis. Il s’agit là d’un facteur de sécurité très important pour empêcher l’utilisation de faux certificats par des attaquants, car ceux-ci pourraient alors accéder à une CA accessible au public.

Les certificats générés présentent également les propriétés suivantes :

Le fait que le certificat standard soit valable aussi longtemps vous évite très efficacement de rencontrer des problèmes de connexion que vous ne pourriez pas identifier. Dans le même temps, il est bien sûr possible qu’une fois qu’un certificat a été compromis, il reste exposé aux abus pendant une période proportionnellement longue. Ainsi, si vous craignez qu’un attaquant accède à l’autorité de certification ou au certificat de l’instance signé par celle-ci, remplacez toujours les deux certificats (autorité de certification et instance) !

Lors d'une mise à jour de Checkmk, les deux options LIVESTATUS_TCP et LIVESTATUS_TCP_TLS ne sont jamais modifiées automatiquement. L'activation automatique du TLS pourrait en fin de compte empêcher toute interrogation de vos instances distantes.

Si vous utilisiez jusqu'à présent Livestatus sans cryptage et que vous décidez désormais d'utiliser le cryptage, vous devez l'activer manuellement. Pour ce faire, arrêtez d'abord les instances concernées, puis activez TLS à l'aide de l'instruction suivante :

Les certificats ayant été générés automatiquement lors de la mise à jour, l'instance utilise alors immédiatement la nouvelle fonctionnalité de chiffrement. Afin de pouvoir continuer à accéder à l'instance depuis l'instance centrale, vérifiez que l'option « Encryption » est définie sur « Encrypt data using TLS » dans le menu sous « Setup > General > Distributed Monitoring » : Vérifiez ce point et, si nécessaire, configurez l'option comme indiqué dans la capture d'écran suivante :

La dernière étape est celle décrite ci-dessus — là encore, vous devez d’abord marquer l’autorité de certification (CA) de l’instance distante comme étant de confiance.

Tous les accès à un ordinateur hôte surveillé s’effectuent systématiquement à partir du site auquel l’ordinateur hôte est affecté. Cela s’applique non seulement à la supervision proprement dite, mais aussi à la reconnaissance du service, à la page Diagnostics, aux notifications, aux gestionnaires d’alertes et à tout le reste. Ce point est très important, car on ne part pas du principe que l’instance centrale a effectivement accès à cet ordinateur hôte.

Certaines vues standard sont regroupées en fonction de l’instance à partir de laquelle l’ordinateur hôte sera supervisé — cela s’applique, par exemple, à All hosts :

L’instance apparaîtra également dans les détails de l’ordinateur hôte ou du service :

Ces informations sont généralement disponibles dans une colonne lorsque vous créez vos propres vues de la table. Il existe également un filtre permettant de filtrer les ordinateurs hôtes d'une instance spécifique :

Il existe un snap-in enfichable « Site status » pour la barre latérale, que vous pouvez ajouter via . Celui-ci affiche l’état de chaque instance. Il offre également la possibilité de désactiver et de réactiver temporairement une instance individuelle en cliquant sur son état — ou toutes les instances à la fois en cliquant sur « Disable all » ou « Enable all ».

Les sites désactivés seront signalés par le statut « ». Cela vous permet également de désactiver un site qui génère des timeouts, évitant ainsi des timeouts superflus. Cette désactivation n’est pas la même chose que la désactivation de la connexion Livestatus via la configuration de connexion dans Setup. Ici, la « désactivation » n’affecte que l’utilisateur actuellement connecté et a une fonction purement visuelle. Cliquer sur le nom d’un site affichera une vue de tous ses hôtes.

Dans une supervision distribuée, le snap-in « Master control » présente une apparence différente. Chaque instance dispose de son propre commutateur global :

Si vous effectuez une supervision avec un cluster HA Checkmk, les nœuds individuels du cluster doivent être affectés au même site que le cluster lui-même. En effet, la détermination de l’état des services en cluster nécessite l’accès à des fichiers de cache générés lors de la supervision du nœud. Ces données se trouvent localement sur le site concerné.

Certains plugins de supervision utilisent des données ferroutées, par exemple pour attribuer des données de supervision qui ont été « ferroutées » depuis un ordinateur hôte vers les machines virtuelles individuelles. Dans la supervision distribuée, l’hôte ferrouté — c’est-à-dire l’ordinateur hôte qui reçoit les données ferroutées — et les ordinateurs hôtes qui en dépendent — en tant que consommateurs effectifs des données ferroutées — ne sont pas toujours surveillés depuis la même instance. Dans ce cas, une attribution inter-sites des données ferroutées peut être activée.

Pour permettre cette communication, il vous suffit de vous assurer que le port du courtier de messages est correctement configuré sur toutes les instances participantes et que le hub de ferroutage est activé.

Vous devez checker cela au plus tard lorsque le message « Disabled » s’affiche ici :

Le trafic de données crée souvent un goulot d’étranglement dans la communication. Si les données sont transmises dans les deux sens entre tous les points, cela peut rapidement entraîner un afflux massif de données et donc une surcharge du réseau de communication. Il est donc conseillé de réduire le nombre de canaux de communication et de limiter l’échange de données principalement au réseau local. Ainsi, pour réduire la charge sur votre instance centrale ou pour optimiser le trafic réseau, vous pouvez également autoriser les instances distantes à communiquer directement entre elles (connexion peer-to-peer). Pour cela, les deux instances distantes doivent également avoir été configurées par l'instance centrale — c'est-à-dire que la fonction « Push configuration to this site » doit être activée pour les deux, comme décrit dans la section « Affectation de instances distantes à l'instance centrale ».

Dans l’Setup > General > Distributed monitoring, sélectionnez l’entrée « Connections > Add peer-to-peer message broker connection ». Attribuez ici un identifiant unique et sélectionnez les deux instances pour la connexion directe. Veillez à suivre les instructions de l’aide en ligne.

L'inventaire matériel/logiciel de Checkmk fonctionne également dans les environnements distribués. Pour cela, les données d'inventaire du répertoire ~/var/check_mk/inventory doivent être régulièrement transmises des instances distantes vers l'instance centrale. Pour des raisons de performances, l'interface utilisateur accède toujours à ce répertoire localement.

Dans les éditions commerciales, la synchronisation s’effectue automatiquement sur toutes les instances connectées via le proxy Livestatus.

Si vous exécutez l'inventaire à l'aide de Checkmk Community dans des systèmes distribués, le répertoire doit être régulièrement répliqué vers l'instance centrale à l'aide de vos propres outils (par exemple, avec rsync).

Même lorsque toutes les instances sont sous supervision centralisée, il est tout à fait possible, et souvent approprié, de réaliser un login sur l’interface d’une instance individuelle. C’est pourquoi Checkmk veille à ce que le mot de passe d’un utilisateur soit toujours le même pour toutes les instances.

Un changement de mot de passe effectué par l'administrateur prendra effet automatiquement dès qu'il sera partagé sur toutes les instances via Activate pending changes.

Un changement effectué par l’utilisateur lui-même via la barre latérale dans ses paramètres personnels fonctionne de manière quelque peu différente. Cela ne permet pas d’exécuter une commande `Activate pending changes`, car l’utilisateur ne dispose bien sûr pas d’autorisation générale pour cette fonction. Dans un tel cas, Checkmk partagera automatiquement le mot de passe modifié sur toutes les instances — dès qu’il aura été enregistré, en fait.

Comme nous le savons tous, les réseaux ne sont jamais disponibles à 100 %. Si une instance est inaccessible au moment d’un changement de mot de passe, elle ne recevra pas le nouveau mot de passe. Jusqu’à ce que l’administrateur exécute avec succès une commande « Activate pending changes », ou respectivement jusqu’au prochain changement de mot de passe réussi, cette instance conservera l’ancien mot de passe pour l’utilisateur. Une icône d’état informera l’utilisateur de l’état du partage du mot de passe vers les différentes instances.

Il va de soi que les balises de l’hôte utilisées sur l’instance distante doivent également être connues de l’instance centrale afin de pouvoir être transférées. Vérifiez-les avant la migration et ajoutez manuellement les balises manquantes à l’instance centrale. Il est ici essentiel que les identifiants de balise (Tag-ID) correspondent — le titre de la balise n'a aucune importance.

Ensuite, déplacez les ordinateurs hôtes et les règles vers l’environnement de configuration de l’instance centrale. Cela ne fonctionne que pour les ordinateurs hôtes et les règles situés dans des sous-dossiers (c’est-à-dire pas dans le dossier Main). Les ordinateurs hôtes du dossier Main doivent d’abord être simplement déplacés vers un sous-dossier de l’instance distante via Setup > Hosts > Hosts.

La migration proprement dite peut ensuite être effectuée très simplement en copiant les répertoires appropriés. Chaque dossier de l’environnement de configuration correspond à un répertoire au sein de ~/etc/check_mk/conf.d/wato/. Ceux-ci peuvent être copiés à l’aide d’un outil de votre choix (par exemple scp) depuis l’instance connectée vers le même emplacement sur l’instance centrale. Si un répertoire portant le même nom existe déjà à cet emplacement, il suffit de le renommer. Notez que les utilisateurs et groupes Linux sont également utilisés par l’instance centrale.

Une fois la copie effectuée, les ordinateurs hôtes apparaîtront dans le répertoire Setup de l'instance centrale, ainsi que les règles que vous avez créées dans ces dossiers. Les propriétés des dossiers seront également incluses dans la copie. Celles-ci se trouvent dans le répertoire du fichier caché .wato.

Afin que les attributs des fonctions du dossier parent de l’instance centrale soient correctement hérités, la dernière étape après la migration consiste à ouvrir et à enregistrer une fois les caractéristiques des dossiers parents – les attributs de l’ordinateur hôte seront ainsi redéfinis.

L'installation du proxy Livestatus est très simple. Il est activé par défaut dans les éditions commerciales — ce qui est visible au démarrage d'une instance :

Sélectionnez le paramètre « Use Livestatus Proxy-Daemon » pour la connexion aux instances distantes au lieu de « Connect via TCP » :

Les détails concernant l'ordinateur hôte et le port restent inchangés. Aucune modification ne doit être effectuée sur l'instance distante. Dans « Number of channels to keep open », saisissez le nombre de connexions TCP parallèles que le proxy doit établir et maintenir vers l'instance cible.

Le pool de connexions TCP est partagé par toutes les requêtes de l'interface graphique. Le nombre de connexions limite le nombre maximal de requêtes pouvant être traitées simultanément. Cela limite indirectement le nombre d'utilisateurs. Dans les situations où tous les canaux sont réservés, cela n'entraîne pas immédiatement une erreur. L'interface graphique attend un certain temps qu'un canal se libère. La plupart des requêtes ne nécessitent en réalité que quelques millisecondes.

Si l'interface graphique doit attendre plus longtemps qu'Timeout waiting for a free channel pour obtenir un canal, elle sera interrompue par une erreur et l'utilisateur recevra un message d'erreur. Dans ce cas, le nombre de connexions doit être augmenté. Sachez toutefois que l'instance distante doit autoriser un nombre suffisant de connexions entrantes parallèles — cette valeur est fixée à 20 par défaut. Ce paramètre se trouve dans les options globales sous « Monitoring core > Maximum concurrent Livestatus connections ».

La fonction « Regular heartbeat » assure une supervision constante des connexions directement au niveau du protocole. Dans ce cadre, le proxy envoie régulièrement une simple requête « Livestatus » à laquelle l’instance distante doit répondre dans un délai prédéfini (par défaut : 2 secondes). Cette méthode permet également de détecter une situation où le serveur cible et le port TCP sont effectivement joignables, mais où le noyau de supervision ne répond plus.

Si aucune réponse n’est reçue, toutes les connexions seront déclarées « mortes » et, après un délai de « refroidissement » (par défaut : 4 secondes), elles seront rétablies. Tout cela se déroule de manière proactive, c’est-à-dire sans que l’utilisateur ait besoin d’ouvrir une fenêtre d’interface graphique. De cette manière, les pannes peuvent être rapidement détectées, et grâce à une procédure de récupération, les connexions peuvent être immédiatement rétablies et, dans le meilleur des cas, être disponibles avant même qu’un utilisateur ne remarque la panne.

L’Cachinge garantit que les requêtes statiques ne nécessitent qu’une seule réponse de la part de l’instance distante et qu’à partir de ce moment-là, elles peuvent être traitées directement et localement, sans délai. La liste des ordinateurs hôtes surveillés requise par Quicksearch en est un exemple.

Le proxy Livestatus dispose de son propre fichier journal ~/var/log/liveproxyd.log. Sur une instance distante correctement configurée avec cinq canaux (configuration standard), il ressemblera à ceci :

Le proxy Livestatus enregistre régulièrement son état dans le fichier ~/var/log/liveproxyd.state :

Et lorsqu'une instance est actuellement arrêtée, l'état se présentera comme suit :

Ici, l'état est « starting ». Le proxy tente donc d'établir des connexions. Il n'y a pas encore de canaux. Dans cet état, les requêtes adressées à l'instance recevront une réponse d'erreur.

Tout d'abord, sur l'instance distante, créez une copie des configurations de ses ordinateurs hôtes et de ses services au format de configuration Nagios. Redirigez également la sortie de la commande « livedump -TC » vers un fichier :

Le début du fichier ressemblera à ceci :

Transférez le fichier vers l'instance centrale (par exemple, à l'aide d'scp) et enregistrez-le dans le répertoire ~/etc/nagios/conf.d/ – où Nagios s'attend à trouver les données de configuration des ordinateurs hôtes et des services. Choisissez un nom de fichier se terminant par .cfg, par exemple ~/etc/nagios/conf.d/config-myremote1.cfg. Si un accès SSH de l'instance distante vers l'instance centrale est possible, cela peut être effectué, par exemple, comme suit :

Connectez-vous maintenant à l’instance centrale et activez les modifications :

Tous les ordinateurs hôtes et services de la télécommande devraient désormais apparaître sur l'instance centrale – initialement avec l'état PEND, qu'ils conserveront pour le moment :

Remarques :

Une fois que les ordinateurs hôtes sont visibles sur l'instance centrale, il faudra effectuer la configuration d'une transmission (régulière) de l'état de supervision des instances distantes. Créez à nouveau un fichier avec la commande `livedump`, mais cette fois sans options secondaires :

Ce fichier contient les états de tous les ordinateurs hôtes et services dans un format que Nagios peut lire directement à partir des résultats de check. Le début de ce fichier ressemble à ceci :

Copiez ce fichier sur l'instance centrale dans le répertoire ~/tmp/nagios/checkresults. Important : le nom de ce fichier doit commencer par c et comporter sept caractères. Avec scp, il ressemblera à ceci :

Enfin, créez un fichier vide sur l'instance centrale portant le même nom et l'extension .ok. Grâce à cela, Nagios saura que le fichier d'état a été entièrement transféré et peut désormais être lu :

L'état des ordinateurs hôtes/services distants sera désormais immédiatement mis à jour sur l'instance centrale :

La transmission de l'état doit désormais être effectuée régulièrement. Vous pouvez utiliser un script pour répéter les étapes décrites ci-dessus à des intervalles de votre choix. Au lieu de copier les données via scp, votre script peut être exécuté directement depuis l'instance centrale afin de recevoir les données d'état ou de configuration via ssh.

Un script permettant d'effectuer ces actions est disponible sur GitHub dans le répertoire treasures.

La configuration et le vidage d'état peuvent également être restreints à l'aide des filtres Livestatus. Par exemple, vous pourriez limiter les ordinateurs hôtes aux membres du groupe d'hôtes « mygroup » :

Les éditions commerciales fournissent un mécanisme intégré de notifications centralisées qui peut être activé individuellement pour chaque instance distante. Ces instances distantes acheminent alors toutes les notifications vers l’instance centrale pour traitement ultérieur. La notification centralisée est ainsi indépendante du mode de configuration de la supervision distribuée : qu’elle soit standard, via CMCDump ou en combinant ces deux procédures. Techniquement parlant, le serveur de notification central n’a même pas besoin d’être littéralement au « centre ». Cette tâche peut être assurée par n’importe quelle instance Checkmk.

Si une instance distante a été configurée en « transfert », toutes les notifications seront transférées directement vers l’instance centrale comme si elles provenaient du noyau du processeur — en fait, au format brut. Une fois sur place, les règles de notification détermineront qui doit effectivement être notifié et de quelle manière. Les scripts de notification requis seront exécutés sur l’instance centrale.

Les spouleurs de notification des instances distantes et de l’instance centrale (de notification) communiquent entre eux via TCP. Les notifications sont envoyées depuis les instances distantes vers l’instance centrale. L’instance centrale confirme la réception des notifications auprès des instances distantes, ce qui empêche toute perte de notifications même si la connexion TCP est interrompue.

Il existe deux alternatives pour l'établissement d'une connexion TCP :

Par conséquent, rien n’empêche le transfert des notifications si, pour des raisons liées au réseau, l’établissement de connexions n’est possible que dans une direction spécifique. Les connexions TCP sont surveillées par le spooler à l’aide d’un signal de pulsation et sont immédiatement rétablies si nécessaire — et pas seulement en cas d’événement.

Étant donné que les instances distantes et l’instance centrale nécessitent des paramètres globaux différents pour le spooler, vous devez définir des paramètres spécifiques à chaque instance pour toutes les instances distantes. La configuration de l’instance centrale s’effectue à l’aide des paramètres globaux habituels. Remarque : ces paramètres seront automatiquement hérités par toutes les instances distantes pour lesquelles aucun paramètre spécifique n’a été défini.

Examinons d'abord un exemple dans lequel l'instance centrale établit les connexions TCP vers les instances distantes.

Étape 1 : Sur l’instance distante, modifiez le paramètre global spécifique à l’instance « Notifications > Notification Spooler Configuration » et activez l’option « Accept incoming TCP connections ». Le port TCP 6555 sera recommandé pour les connexions entrantes. Si vous n’avez aucune objection, adoptez ces paramètres.

Étape 2 : À présent, de la même manière, dans le sous-menu « Notification Spooling » (Paramètres globaux) de l’instance distante uniquement, sélectionnez l’option « Forward to remote site by notification spooler » (Établir les connexions TCP vers les instances distantes).

Étape 3 : À présent, sur l'instance centrale — c'est-à-dire dans les paramètres globaux normaux —, configurez la connexion vers l'instance distante (puis vers d'autres instances distantes si nécessaire) :

Étape 4 : Définissez le paramètre global « Notification Spooling » sur « Asynchronous local delivery by notification spooler », afin que les communications de l’instance centrale soient également traitées via le même spooler central.

Étape 5 : Activez les modifications.

Si la connexion TCP doit être établie depuis l’instance distante vers l’extérieur, la procédure est identique, la seule différence par rapport à la description ci-dessus étant l’inversion des rôles entre l’instance centrale et l’instance distante.

Une combinaison des deux procédures est également possible. Dans ce cas, l’instance centrale doit être configurée de manière à écouter les connexions entrantes tout en se connectant aux instances distantes. Cependant, dans toute relation central/distant, seul l’un des deux est autorisé à établir la connexion !

Le spouleur de notification consigne ses activités dans le fichier ~/var/log/mknotifyd.log. Dans la configuration du spouleur, le niveau de journalisation peut être augmenté afin de recevoir davantage de messages. Avec un niveau de journalisation standard, vous devriez voir quelque chose comme ceci sur l’instance centrale :

À tout moment, le fichier ~/var/log/mknotifyd.state contient l'état actuel du spooler et de toutes ses connexions :

Une version de ce même fichier est également présente sur l’instance distante. Là-bas, la connexion ressemblera à ceci :

Pour effectuer un test, sélectionnez n'importe quel service distant sous supervision et définissez-le manuellement sur « CRIT » à l'aide de l'instruction « Fake check results ».

Une notification entrante devrait alors apparaître sur l’instance centrale dans le fichier journal des notifications (notify.log) :

Le même événement se présentera comme suit sur l'instance distante :

Dans les paramètres généraux, vous pouvez définir un niveau de journalisation plus élevé à la fois pour le fichier journal normal des notifications (notify.log) et pour le fichier journal du spouleur de notification.

Une fois que vous aurez tout configuré comme décrit, vous remarquerez que sur l’instance centrale, et respectivement sur les instances distantes, un nouveau service apparaîtra qui devra impérativement être pris en compte dans la supervision. Celui-ci surveille le spouleur de notification et ses connexions TCP. Chaque connexion sera ainsi surveillée deux fois : une fois par l’instance centrale, et une fois par l’instance distante :