 |
This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved. |
1. Migration de Nagios vers le CMC
Les éditions commerciales créent automatiquement de nouvelles instances avec le Checkmk Micro Core (CMC) comme noyau. Si votre instance provient d'une version antérieure, elle peut être convertie a posteriori de Nagios vers le CMC. La procédure en elle-même est très simple :
Commencez par arrêter votre instance Checkmk :
Procédez ensuite à la conversion :
Ensuite, n'oubliez pas de redémarrer :
Attention : l'état actuel du noyau du processeur (les états actuels des ordinateurs hôtes et des services, etc.) ne sera PAS conservé. L'état du système sera dans tous les cas redéfini une fois que chaque check aura été exécuté avec la nouvelle configuration. Tout ordinateur hôte ou service qui ne présente pas un état « UP » ou « OK » déclenchera une nouvelle notification. Si vous ne le souhaitez pas, désactivez les notifications avant la conversion — à l’aide du snap-in de master control de la barre latérale. Les périodes de maintenance planifiées et les commentaires, ainsi que les données historiques de performance dans les RRD, seront toutefois transférés.
L'historique des événements (Nagios-Log) sera conservé dans un format compatible par le CMC — mais à un emplacement différent (var/check_mk/core/history).
L'archive des journaux se trouve dans var/check_mk/core/archive.
Si vous souhaitez conserver l'historique des événements (par exemple, pour des raisons de disponibilité), copiez les fichiers nécessaires à l'aide d'une instruction :
1.1. De CMC vers Nagios
Si vous constatez que votre configuration n'est pas encore compatible avec CMC (voir ci-dessous pour des conseils), vous pouvez revenir à Nagios de la même manière que celle décrite ci-dessus :
Il n'est pas possible de transférer les périodes de maintenance planifiées, etc. de CMC vers Nagios. Nagios importera toutefois son état antérieur à la migration vers CMC.
2. Conseils pour la migration vers le CMC
Afin de conserver au CMC une structure aussi légère et efficace que possible, et de moderniser certains composants importants, toutes les fonctions de Nagios n’ont pas été réécrites à l’identique. Cela signifie qu’il peut s’avérer nécessaire de modifier certains éléments de votre configuration.
Le CMC ne peut en principe pas importer les fichiers de configuration de Nagios.
Si toutefois vous avez saisi manuellement certaines données de Nagios ou utilisé des constructions telles que extra_nagios_conf dans le fichier main.mk, celles-ci ne pourront pas être traitées.
Si vous avez toujours utilisé la Configuration de l'interface web, aucune modification n'est nécessaire.
Dans les sections suivantes, vous trouverez un résumé de tous les éléments qui auraient pu être configurés manuellement dans Nagios, mais qui ne peuvent pas être mis en œuvre (ou pour lesquels une procédure différente est nécessaire) dans le CMC :
2.1. Processus d'aide
L'utilisation du CMC modifie fondamentalement la manière dont les données sont collectées puis vérifiées. Par conséquent, lors du passage au CMC — en particulier pour les instances comportant plusieurs milliers d'ordinateurs hôtes —, il est probablement nécessaire de vérifier et d'ajuster le nombre de Checkmk Checkers et de récupérateurs de données prédéfinis. La fonction « Analyze configuration » peut fournir une première indication à ce sujet. Cependant, nous vous recommandons vivement de lire le chapitre consacré aux processus d'aide dans le manuel.
Et pour tous ceux qui sont pressés :
Maximum concurrent Checkmk checkers = nombre de noyaux de processeur sur votre serveur
Maximum concurrent Checkmk fetchers = Chaque « fetcher » nécessite environ 50 Mo de mémoire — n'hésitez donc pas à augmenter cette valeur.
2.2. Gestionnaire d'événements
Le CMC ne prend pas en charge de gestionnaire d'événements Nagios classique. Les éditions commerciales disposent toutefois de ce que l'on appelle des gestionnaires d'alertes pour cette fonction, qui sont nettement plus flexibles. Ils peuvent être configurés via Setup > Events > Alert handlers.
2.3. Dépendances de service
Cette fonctionnalité n'est actuellement pas prise en charge par le CMC. Étant donné que les dépendances de service sont fastidieuses à configurer dans Nagios et peu transparentes pour l'utilisateur, il n'est pas prévu de les implémenter sous cette forme.
2.4. Modules de courtier d'événements
Livestatus et le traitement des données de performance font partie intégrante du CMC. Aucun autre module ne peut être chargé.
2.5. Escalades
L'escalade des notifications ne s'effectue plus au niveau du noyau du processeur, mais via des notifications basées sur des règles.
2.6. Périodes de temps
En ce qui concerne les périodes de temps, certaines des conditions d'exception prises en charge par Nagios ne sont pas possibles.
Actuellement, seul le format YYY-MM-DD, par exemple 1970-12-18, est pris en charge, mais pas un format tel que february -2.
Avec Setup > General > Time periods, il est toutefois possible d'importer des fichiers de calendrier au format iCal.
2.7. Variable de configuration legacy_checks
La variable de configuration legacy_checks, utilisée pour configurer les contrôles actifs dans les anciennes versions de Checkmk, n'existe plus.
Vous pouvez bien sûr exécuter des contrôles actifs avec le CMC, mais sous une forme quelque peu différente.
La raison en est que les variables de configuration « legacy_checks » font référence à des instructions définies manuellement dans la configuration Nagios et qui ne sont donc pas disponibles pour le CMC.
À la place, vous pouvez utiliser les variables de configuration plus modernes « custom_checks ».
Vous les gérez à l'aide du jeu de règles « Integrate Nagios plugins », que vous trouverez dans « Setup > Services > Other services » — et, soit dit en passant, vous pouvez également les utiliser sans le CMC.
L'exemple suivant montre comment modifier une check existante …
# Definition of the Nagios command
extra_nagios_conf += r"""
define command {
command_name check-my-foo
command_line $USER1$/check_foo -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$
}
"""
# Create service definition
legacy_checks += [
(( "check-my-foo!20!40", "FOO", True), [ "foohost", "othertag" ], ALL_HOSTS ),
]… au nouveau format d’custom_checks :
custom_checks += [
({
'command_name': 'check-my-foo',
'service_description': 'FOO',
'command_line': 'check_foo -H $HOSTADDRESS$ -w 20 -c 40',
'has_perfdata': True,
},
[ "foohost", "othertag" ],
ALL_HOSTS )]La nouvelle méthode fonctionne également avec un noyau du processeur Nagios, de sorte qu’après la conversion, vous pouvez passer sans problème de l’un à l’autre.
2.8. Données de performance issues des checks d'ordinateurs hôtes
Le CMC utilise Smart Ping comme norme pour les checks des ordinateurs hôtes. Cela signifie qu'après une migration depuis le noyau du processeur Nagios :
les contrôles d'ordinateurs hôtes ne fournissent dans un premier temps aucune donnée de performance, et
les contrôles ping créés manuellement sur les ordinateurs hôtes ne disposant pas d’autres contrôles génèrent des données de performance par défaut.
Si vous avez besoin des données de performance ping pour un ordinateur hôte unique ou pour tous les ordinateurs hôtes, nous vous recommandons d'ajouter une check active par ping pour les ordinateurs hôtes souhaités à l'aide du jeu de règles « Check hosts with PING (ICMP Echo Request) ».
Si vous souhaitez conserver les bases de données Round Robin (RRD) existantes, il vous suffit — pendant que le noyau du processeur est arrêté — de renommer les fichiers des répertoires var/pnp4nagios/perfdata/<hostname> qui commencent par _HOST_ : de _HOST_* à PING*.
Sinon, avec le jeu de règles Host check command, vous pouvez désactiver Smart Ping et le remplacer par un ping classique qui fonctionne en interne comme d'habitude avec check_icmp.
Dans ce cas, vous n'avez pas besoin de renommer les RRD, mais vous devez toutefois renoncer aux avantages de Smart Ping.