Administration de site avec omd

Dans certains cas, il est également souhaitable de spécifier l'ID utilisateur/groupe du nouvel utilisateur à créer. Cela s'effectue à l'aide des options -u et -g, par exemple :

Vous pouvez afficher un aperçu des autres options à l'aide de omd create --help. Les options les plus importantes sont les suivantes :

Par défaut, le répertoire personnel d'une nouvelle instance est créé à l'adresse /omd/sites/ et rempli de fichiers par défaut. Cependant, vous pouvez également créer un répertoire personnel vide, par exemple pour monter un volume externe à cet emplacement. Pour ce faire, utilisez l'option --no-init :

Cette option omet également l'intégration avec le serveur Apache du système, laissant /omd/apache/mysite.conf vide. Vous pouvez alors monter n'importe quel répertoire ou volume et poursuivre la configuration :

omd init puis rattrape les deux étapes omises, de sorte qu'il ajoute les fichiers par défaut et crée la configuration Apache.

En tant qu'utilisateur de l'instance, vous pouvez simplement activer le mode interactif à l'aide de la commande suivante :

Dès que vous modifiez un paramètre alors que l'instance est en cours d'exécution, OMD vous informe que votre instance doit d'abord être arrêtée et procède à cette opération si nécessaire :

N'oubliez pas de redémarrer l'instance une fois les modifications effectuées. L' omd configne le fera pas automatiquement pour vous.

Ceux qui n'apprécient pas le mode interactif ou préfèrent travailler avec des scripts peuvent définir les paramètres individuels sous forme de variables via la ligne de commande. Pour cela, il existe l'instruction omd config set. L'exemple suivant définit la variable AUTOSTART sur off :

Cette opération peut également être effectuée à l'aide de la commande root si le nom de l'instance est ajouté en tant qu'argument :

L'affectation actuelle de toutes les variables s'affiche sous la forme root pour l'instruction omd config mysite show et sous la forme omd config show pour l'utilisateur de l'instance :

La sortie ci-dessus est abrégée pour plus de clarté et n'affiche que les premières entrées.

omd config comporte de nombreux paramètres. Les plus importants sont les suivants :

Remarque : vous pouvez également voir ces variables sous les mêmes noms en mode interactif.

Il est parfois utile de créer une copie d’une instance à des fins de test ou lors de la préparation d’une mise à jour. Bien sûr, on pourrait simplement copier le répertoire /omd/sites/mysite_old vers /omd/sites/mysite_new. Cela ne fonctionnera toutefois pas comme prévu, car :

Pour simplifier la copie d’une instance, il existe à la place l’instruction omd cp, qui prend tout cela en compte. Exécutez l’instruction en tant que root et entrez simplement le nom de l’instance existante suivi du nom de la nouvelle. Par exemple :

La copie ne peut fonctionner que si :

Ces deux conditions garantissent que l’instance est dans un état cohérent au moment de la copie et qu’elle ne change pas pendant l’opération.

À l'origine, OMD ne pouvait traiter que les fichiers créés lors de la création du site à l'aide de l'instruction « omd create », et qui contenaient également l'identifiant du site ($OMD_SITE). Ces fichiers se trouvent dans le répertoire d'instances ~/etc à l'aide de cette instruction :

Auparavant, OMD ne pouvait rien faire avec les fichiers de configuration créés ultérieurement lors de l’utilisation du site Checkmk (les configurations d’ordinateurs hôtes ajoutés à une date ultérieure, par exemple). D’un point de vue purement technique, ce comportement correspond exactement au champ d’application d’OMD. Cependant, la plupart des utilisateurs s’attendent à ce qu’une « omd cp » crée une instance entièrement nouvelle pouvant continuer à être utilisée de manière productive — y compris sa propre configuration de supervision.

À partir de la version 2.1.0 de Checkmk, OMD peut désormais également personnaliser les éléments les plus importants de la configuration Checkmk. Soit dit en passant, vous n’avez rien à faire, l’ensemble de la migration décrite ci-dessous s’effectue automatiquement.

Exemple typique : Dans les propriétés d’un ordinateur hôte, vous pouvez utiliser l’attribut « Monitored on site » pour spécifier manuellement sur quelle instance cet ordinateur hôte doit être soumis à la supervision, par exemple mysite_old. Après une omd cp mysite_old mysite_new, la valeur passera en conséquence à mysite_new. (Auparavant, cette procédure aurait donné lieu à l’entrée Unknown site (mysite_old)).

La mise en œuvre technique concrète de cette migration est la suivante : OMD détecte les modifications apportées à l'ID de l'instance, puis exécute l'instruction post-rename-site -v -o mysite_new. Les différentes étapes de la migration sont ensuite traitées de manière entièrement automatique via les plugins dits « rename actions », que vous pouvez trouver à l'adresse cmk/post_rename_site/plugins/actions dans le dépôt Git.

La migration comprend également la notification de tout élément ne pouvant pas être migré automatiquement.

Voici un exemple concret : vous utilisez la supervision distribuée et renommez à la fois l’instance centrale et une instance distante.

Instance centrale : le plugin sites.py détecte qu’il s’agit d’une instance centrale et met à jour, entre autres, la valeur URL prefix, qui se trouve dans les paramètres de connexion de l’instance locale sous Setup > General > Distributed Monitoring.

Instance distante : le plugin warn_remote_site.py reconnaît qu’il s’agit d’une instance distante et indique en conséquence que l’instance centrale doit être vérifiée et personnalisée manuellement si nécessaire. Cela signifie donc que, dans les paramètres de supervision distribuée de l’instance centrale, le nouveau nom de l’instance distante doit être saisi dans les paramètres de connexion vers l’instance distante renommée — OMD ne peut bien sûr pas effectuer cette opération à partir d’un ordinateur distant.

OMD vous informe en détail de l’ensemble du processus dans le terminal. Vous trouverez ici un exemple des messages de migration issus de la sortie d’omd cp lors du changement de nom d’une instance centrale — séparés en messages de réussite et d’avertissement. Les tâches de migration traitées sont numérotées individuellement. Tout d’abord, la sortie des tâches de migration effectuées automatiquement (abrégée ici) :

La deuxième partie de la sortie contient désormais des conseils concernant les paramètres que vous devrez peut-être configurer manuellement (fortement abrégés ici) :

L'élément « Warn about configurations to review…​ » comprend des remarques générales sur des aspects particuliers qui devront généralement être vérifiés manuellement lors d'une migration, tels que les filtres codés en dur pour les vues de la table :

Voici un aperçu des six plugins actuellement actifs — l'ordre indiqué ici correspond à la numérotation de la sortie ci-dessus :

Si vous effectuez la supervision d'un grand nombre d'ordinateurs hôtes avec le site, le volume de données à copier peut être assez important. La majeure partie de ce volume provient des valeurs mesurées stockées dans les bases de données tourniquet (RRD). Mais les fichiers journaux contenant les événements historiques peuvent également générer des volumes de données plus importants.

Si l'historique n'est pas nécessaire (par exemple, parce que vous souhaitez simplement effectuer un test rapide), ceux-ci peuvent être omis de la copie. Dans ce cas, les options suivantes peuvent être ajoutées à omd cp :

L'ordre des options est important :

Le renommage d'une instance s'effectue à l'aide de l'instruction `omd mv`. Cette opération s'effectue de la même manière que la copie d'une instance, requiert les mêmes conditions préalables et inclut également la migration de la configuration. Les options permettant de limiter le volume de données ne sont pas disponibles, car les données sont simplement déplacées vers un autre répertoire et ne sont pas dupliquées.

Exemple :

Lors du renommage d’une instance à l’aide de l’instruction `omd mv`, le nom de l’instance sera modifié, mais certains attributs de l’instance ne le seront pas, notamment l’ID de l’instance. Cette instruction n’est donc pas adaptée à l’exploitation d’une instance qui a été dupliquée, par une sauvegarde par exemple, simultanément avec sa version d’origine dans une supervision distribuée — même si les instances concernées portent des noms différents après l’exécution de l’instruction `omd mv`.

Tout comme pour la création d’une instance, les instructions de copie et de renommage créent chacune un nouvel utilisateur Linux. Par conséquent, les instructions omd cp et omd mv disposent également de certaines options communes avec l’instruction omd create, par exemple pour spécifier les identifiants d’utilisateur et de groupe. Pour plus d’informations, utilisez les instructions omd cp --help et omd mv --help.

La gestion des instances dans Checkmk dispose d’un mécanisme intégré permettant de sauvegarder et de restaurer les instances Checkmk. Les instructions omd backup et omd restore constituent les instructions de base permettant respectivement de compresser toutes les données de l’instance dans une archive tar et d’extraire ces données en vue d’une restauration.

Remarque : Checkmk offre également la possibilité d'effectuer des sauvegardes et des restaurations sans utiliser la ligne de commande, via l'interface graphique sous Setup > Maintenance > Backups. Vous pouvez également y créer des sauvegardes chiffrées et planifier des tâches de sauvegarde. Consultez l'article Sauvegardes pour savoir comment procéder.

La sauvegarde d’une instance via omd backup ne nécessite pas d’autorisations pour root. Un utilisateur de l'instance peut effectuer cette opération. Il suffit d’entrer en argument le nom du fichier de sauvegarde à créer :

Remarque :

Si le répertoire de destination de la sauvegarde n'est pas accessible en écriture pour un utilisateur de l'instance, vous pouvez également effectuer la sauvegarde en tant qu'root. Dans ce cas, un argument supplémentaire est requis, comme toujours, pour spécifier le nom de l'instance à sauvegarder :

La sauvegarde contient toutes les données de l'instance, à l'exception des données volatiles situées sous ~/tmp/. L'instruction « tar tzf » permet de consulter facilement le contenu du fichier :

La majeure partie des données à déplacer lors d’une sauvegarde de site est constituée des valeurs mesurées stockées dans les bases de données Round Robin (RRD) et des fichiers journaux contenant l’historique des événements. Une autre partie importante des données à déplacer lors d’une sauvegarde de site est constituée des paquets d’agents, qui sont stockés par la boulangerie d’agents dans le répertoire ~/var/check_mk/agents, mais ceux-ci peuvent être facilement recréés si nécessaire.

omd backup offre les mêmes options que omd cp lors de la copie pour exclure ces données. Dans l'exemple suivant, la sauvegarde est créée entièrement sans ces données :

Lors de la sauvegarde, vous pouvez également spécifier quelles données parmi celles ci-dessus vous souhaitez exclure. Utilisez omd backup --help pour afficher les options disponibles.

Une sauvegarde peut également être créée à partir d'une instance en cours d'exécution. Afin de garantir la cohérence des fichiers RRD utilisés pour l'enregistrement des données de mesure, l'instruction omd backup modifie automatiquement le cache Round Robin pour le faire passer en un mode dans lequel les mises à jour en cours sont écrites uniquement dans le journal, et non plus dans les fichiers RRD. Les fichiers journaux sont les derniers à être sauvegardés — cela permet ainsi d'inclure dans la sauvegarde autant que possible les données de mesure générées pendant la sauvegarde.

La restauration d’une sauvegarde est aussi simple que la création d’une sauvegarde. L’instruction omd restore restaure une instance à partir d’une sauvegarde — dans la version de Checkmk qui a été utilisée pour sauvegarder l’instance. Par conséquent, pour que la restauration fonctionne, cette même version doit être installée sur le serveur.

L'instance est entièrement vidée puis réinitialisée. Avant la restauration (omd restore), l'instance doit être arrêtée, puis redémarrée après la restauration :

Une restauration peut également être effectuée par un utilisateur « root ». Contrairement à ce qui se passe lorsque la commande est appelée par l'utilisateur de l'instance, l'instance sera recréée à partir de la sauvegarde.

Ainsi, s’il existe déjà une instance portant le même nom, vous devrez la supprimer avant la restauration. Cette opération peut être effectuée soit via l’omd rm, soit en incluant simplement l’option --reuse avec l’instruction omd restore. L’instruction --kill garantit en outre que l’instance existante est arrêtée avant que la restauration ne commence. Vous n’avez pas besoin de spécifier le nom de l’instance dans l’instruction, car il est contenu dans la sauvegarde :

En tant qu'root, vous pouvez également restaurer une instance sous un nom différent de celui figurant dans la sauvegarde. Pour ce faire, indiquez le nom souhaité en tant qu'argument après le mot « restore » :

La longue liste de conversions qui s'effectuent ici a la même fonction que pour la copie et le renommage d'instances décrits précédemment. Le nom de l'instance figure dans de nombreux fichiers de configuration, et grâce à cette procédure, toutes ces occurrences seront automatiquement remplacées par le nouveau nom.

Les instructions omd backup et omd restore peuvent — dans la bonne vieille tradition Unix — également fonctionner via l’entrée/sortie standard au lieu de fichiers. Au lieu d’un chemin d’accès au fichier tar, entrez simplement un tiret (-).

De cette manière, un tuyau peut être créé et les données « transmises en continu » directement vers un autre ordinateur sans nécessiter de fichiers intermédiaires. Plus la sauvegarde est volumineuse, plus cette méthode sera avantageuse, car aucun espace temporaire ne sera nécessaire dans le système de fichiers du serveur sauvegardé.

L'instruction suivante sauvegarde une instance sur un autre ordinateur à l'aide de SSH :

Si vous souhaitez inverser l'accès SSH, c'est-à-dire si vous préférez vous connecter depuis le serveur de sauvegarde vers l'instance Checkmk, cela est également possible, comme le montre l'exemple suivant. Pour cela, il faut d'abord autoriser un login SSH en tant qu'utilisateur de l'instance.

Si vous êtes astucieux et que vous combinez ce qui précède avec une commande « omd restore » qui lit les données à partir de l'entrée standard, vous pouvez copier une instance complète et en cours d'exécution d'un serveur à un autre — sans avoir besoin d' espace supplémentaire pour un fichier de sauvegarde :

Et maintenant, recommençons tout cela avec un accès SSH inversé — cette fois-ci, du système source vers le système cible :