Mises à jour et mises à niveau

Lorsque vous effectuez une mise à jour vers une version majeure supérieure, vous devez toujours passer à la version majeure suivante, sans sauter de versions majeures intermédiaires. Si vous souhaitez passer de la version 2.2.0 à la version 2.4.0, effectuez d'abord la mise à jour vers la version 2.3.0. La raison de cette procédure est simple : il y a parfois tellement de changements entre deux versions majeures que le fait d'en sauter une entraînerait des problèmes. Utilisez toujours la version de correctif la plus récente lors de la mise à jour.

Cela s'applique également à la version source. Une mise à jour de la version 2.2.0p1 vers la version 2.4.0p24 suit donc le chemin d'accès suivant :

2.2.0p1 2.2.0p47 2.3.0p45 2.4.0p24

L'instruction omd update permet également une « mise à jour » vers une version antérieure. Cette procédure est uniquement destinée aux régressions.

Votre système de supervision peut être étendu assez facilement et commodément à l’aide des paquets d’extension Checkmk (MKP). D’une part, il est possible que certains MKP plus anciens ne soient plus maintenus et ne soient donc plus compatibles avec les versions plus récentes de Checkmk. D’autre part, nous continuons d’ajouter de nouveaux plugins et des extensions fonctionnelles à Checkmk, ce qui explique pourquoi les MKP deviennent parfois obsolètes. Les fonctionnalités de ces plugins et extensions sont simplement fournies par Checkmk lui-même en standard.

C'est pourquoi, lorsque vous vous préparez à une mise à jour, il est fortement recommandé de passer en revue tous les MKP installés. Cela permettra d'éviter que des paquets incompatibles n'interfèrent avec la mise à jour, ou n'entraînent la duplication ou, à tout le moins, la présence de services très similaires après la mise à jour.

Pour ce faire, comparez vos MKP installés à notre catalogue de plugins de supervision et supprimez tous les paquets contenant des fonctions désormais fournies en natif par Checkmk. Vous pouvez également profiter de cette occasion pour supprimer les MKP qui n’auraient été installés que pour un test. Vous trouverez une liste dans le menu «Setup » sous «Maintenance > Extension packages». En ligne de commande, vous pouvez afficher les extensions installées à l'aide de l'instruction «mkp list». Vérifiez la sortie de cette instruction pour repérer les extensions qui ne sont plus nécessaires ou que vous ne pouvez même pas identifier.

Checkmk prend en charge l'installation de MKP pour une version plus récente que celle actuellement en cours d'exécution, en prévision de futures mises à jour. Lors d'une mise à jour, le paquet correspondant à la version antérieure de Checkmk est alors désactivé et celui correspondant à la version supérieure est activé. Les détails sont expliqués dans l'article consacré à l'utilisation des MKP.

Attention : si vous avez apporté des modifications locales à des fichiers provenant à l'origine de MKP, recompilez le MKP après avoir augmenté le numéro de version. Lors d'une mise à jour, les fichiers qui ont été modifiés d'une autre manière seront écrasés par ceux contenus dans le MKP.

Les fichiers locaux vous permettent de personnaliser et d'étendre les fonctionnalités fournies par Checkmk. Ces fichiers se trouvent dans la partie locale du répertoire d'instances, c'est-à-dire dans ~/local. Les fichiers locaux peuvent poser des problèmes lors de la mise à jour, car ils risquent de ne plus correspondre à la nouvelle version de Checkmk.

Comme Checkmk ne peut pas intercepter et gérer les personnalisations locales ni les extensions tierces lors d'une mise à jour, vous devez vérifier votre instance Checkmk avant une mise à jour pour voir si vous utilisez des fichiers locaux et, le cas échéant, lesquels.

Obtenez un aperçu des fichiers locaux de votre instance Checkmk en exécutant l'instruction suivante en tant que utilisateur de l'instance (l'option -L garantit que les liens symboliques sont également suivis) :

Dans une nouvelle installation de Checkmk, vous ne verrez actuellement qu'un fichier nommé « README.TXT » dans la liste. Tout autre élément devrait figurer en tête de votre liste de dépannage si vous rencontrez des problèmes lors de la mise à jour.

Idéalement, les fichiers locaux sont déjà entièrement packagés dans des MKP. Utilisez mkp find pour identifier les fichiers non packagés. Pour plus de détails sur la création de paquets, consultez notre article sur les paquets d'extension Checkmk. Une fois packagée, chaque extension peut être désactivée ou réactivée en tant qu'élément complet.

Nous n’avons pas besoin de vous rappeler l’importance de créer une sauvegarde immédiatement avant toute mise à jour, afin de ne pas risquer de perdre une trop grande partie de votre historique de supervision en cas d’échec pendant la mise à jour. Ce qui est pertinent à ce stade, c’est qu’une sauvegarde régulière peut également vous être utile pour tester une mise à jour en attente. Cette pratique vous permet de restaurer la sauvegarde sous un autre nom, puis d’utiliser l’instance newsite pour tester la mise à jour avant sa mise en production :

Vous pouvez également copier votre instance via omd cp. Pour cela, il faut toutefois arrêter l’instance en production pendant un court instant :

Exécutez ensuite la mise à jour sur cette nouvelle instance clonée, par exemple pour vérifier que les modifications locales mentionnées ci-dessus ont bien été effectuées dans le nouvel environnement. Si les tests sur l'instance clonée se sont avérés concluants, vous souhaiterez généralement la supprimer ou au moins l'arrêter avant la mise à jour effective de l'instance de production, pour des raisons d'espace et de performances.

Comme décrit dans l'introduction, la première étape d'une mise à jour consiste à installer la nouvelle version souhaitée de Checkmk. Cette opération s'effectue exactement de la même manière que lors de l'installation initiale — elle sera toutefois un peu plus rapide, car la plupart des paquets requis ont déjà été installés. Dans l'exemple suivant, nous installons un paquet pour Ubuntu 24.04 (Noble Numbat) :

Remarque : lors de l'installation d'un paquet local via apt install, vous devez indiquer le chemin d'accès au fichier .deb.

Une liste de vos versions de Checkmk installées peut être affichée à tout moment à l'aide de l'instruction omd versions :

L'une des versions de la liste est marquée d'un (default). Cette version par défaut sera utilisée automatiquement lors de la création de nouvelles instances, tant qu'aucune autre version n'est spécifiée avec omd -V myversion create .... La version par défaut actuelle peut être consultée avec omd version, et elle peut être modifiée avec omd setversion :

La version par défaut ne joue aucun rôle lors de la gestion des instances existantes. L'instruction omd démarre toujours avec la version appropriée à l'instance pour laquelle l'instruction est appelée.

L'instruction omd sites fournit une liste des instances actuelles et des versions qu'elles utilisent :

Une fois la nouvelle version souhaitée installée, le site peut être mis à jour. Aucune autorisation « root » n’est requise pour cela. La meilleure façon de procéder est d’utiliser un utilisateur de l'instance :

Assurez-vous que l'instance a été arrêtée :

La mise à jour — qui consiste en fait à passer à une version différente — peut désormais être effectuée simplement à l'aide de l'instruction « omd update » :

Si plusieurs versions cibles sont disponibles, une liste de sélection s'ouvrira :

Dans le dialogue suivant, confirmez la mise à jour sélectionnée vers la nouvelle version :

Par mesure de sécurité, lorsque vous effectuez une mise à niveau d'édition depuis une édition Checkmk Community vers l'une des éditions commerciales en même temps que la mise à jour de version, ce fait vous sera à nouveau rappelé :

Une partie importante de la mise à jour consiste à actualiser les fichiers de configuration fournis à l'origine. Ici, les modifications éventuellement apportées à ces fichiers par l'utilisateur ne seront pas simplement ignorées, mais fusionnées. Ce processus fonctionne de manière très similaire aux systèmes de contrôle de version qui tentent de fusionner les modifications apportées à un même fichier simultanément par plusieurs développeurs.

Il arrive parfois — lorsque les modifications affectent le même emplacement dans le fichier — que cela ne fonctionne pas et qu’un conflit survienne. La manière de résoudre ces conflits sera expliquée plus loin.

La mise à jour fournit une liste de tous les fichiers et répertoires modifiés (abrégée dans l'exemple suivant) :

Si la ligne Completed verifying site configuration mise en évidence dans la sortie ci-dessus s'affiche, l'instance a été basculée vers la nouvelle version :

… et peut ensuite être lancée :

Le développement du logiciel implique bien sûr des modifications. Comme nous nous efforçons constamment de maintenir Checkmk à la pointe de la technologie, il est parfois inévitable de supprimer des éléments obsolètes et d'apporter des modifications qui s'avèrent incompatibles. Cela signifie que lors d'une mise à jour, il peut être nécessaire d'adapter votre configuration, ou du moins de la vérifier.

Un exemple typique d'une telle situation concerne les nouveaux plugins de supervision qui remplacent des plugins existants. Si vous utilisez l'un des plugins concernés, une nouvelle reconnaissance du service sera nécessaire sur l'ordinateur hôte concerné.

Vous trouverez en ligne, dans notre Werks, un aperçu de toutes les modifications apportées à Checkmk, ainsi qu'une fonction de recherche.

La fonction de recherche intégrée à Checkmk est toutefois encore plus pratique. Une fois connecté à l’instance, vous trouverez un lien surligné en rouge en haut du menu « Help » (Configuration) indiquant le nombre de modifications incompatibles et non encore confirmées :

Checkmk répertorie les modifications incompatibles survenues lors de la mise à jour vers la version actuelle et vous invite à les examiner puis à les confirmer :

Si vous ouvrez cette page via le lien rouge dans le menu « Help », vous ne verrez que les « Werk » (c'est-à-dire les modifications) pour lesquelles une action est requise et qui sont donc signalées par la mention « Incompatible - TODO ». Vous pouvez ouvrir chaque Werk individuellement, le consulter, le valider d'un simple clic de souris — et ainsi réduire progressivement le nombre de modifications incompatibles en attente. De plus, l'entrée « Help > Change log (works) » vous donne accès à l'historique complet des modifications de la version majeure actuelle.

Êtes-vous curieux de savoir ce qui se passe exactement « en coulisses » lors d’une mise à jour ? Ou des conflits de données sont-ils apparus lors de l’exécution de l’omd update ? Si tel est le cas, voici quelques informations complémentaires.

Trois actions ont lieu pendant l’exécution de « omd update » :

Souhaitez-vous automatiser les mises à jour du logiciel de Checkmk ? Vous pourriez rencontrer des difficultés au début avec les réponses interactives de l’instruction « omd update ». Il existe une solution simple pour ce cas de figure. L’instruction dispose d’options spécialement conçues pour être utilisées dans des scripts :

Les valeurs possibles pour --conflict= sont les suivantes :

Vous trouverez ci-dessous un exemple d'instruction complète pour une mise à jour automatisée vers la version 2.4.0p24.cre de mysite :

Grâce à l'option && précédant omd start, le redémarrage de l'instance sera empêché si l'omd update est interrompue par une erreur. Remplacez l'&& par un point-virgule (;) si un démarrage doit absolument être tenté même dans une telle situation.

Si vous êtes certain qu'une seule instance Checkmk est en cours d'exécution sur le serveur, le nom à utiliser dans un script shell peut simplement être stocké dans une variable :

Cela permet à la ligne ci-dessus d'être indépendante du nom de l'instance. Par exemple, un petit script shell pourrait ressembler à ceci :

La raison technique de l'approche de mise à jour décrite ci-dessus réside dans les protocoles utilisés : L'instance centrale accède aux données des instances distantes principalement en lecture via Livestatus, et dans le cas d'une configuration centrale, avec un accès en écriture supplémentaire via une API HTTP non publique. Dans les deux cas, les nouvelles versions introduisent de véritables sur-ensembles des protocoles utilisés. Ainsi, une instance centrale plus ancienne n’utilise qu’un sous-ensemble des fonctionnalités des instances distantes plus récentes. Si l’instance centrale était mise à jour en premier, elle pourrait émettre des appels API ou des requêtes Livestatus vers les instances distantes que celles-ci ne « comprennent » pas encore.

La différence de version maximale d'une version majeure résulte à nouveau du fait que la suppression d'interfaces s'accompagne d'une période de grâce d'exactement une version.

Afin de faciliter ces mises à jour par étapes, Checkmk offre la possibilité de stocker des paquets d’extension portant le même nom dans différentes versions — l’une correspondant à l’instance centrale plus ancienne, l’autre aux instances distantes plus récentes — par exemple. La version appropriée sera activée pour chaque instance. Les détails sont décrits dans l’article sur les paquets d’extension (MKP).

Avec l’extension des instances de la visionneuse, ces dernières ne peuvent être mises à jour qu’après les instances distantes dont elles affichent les données. Si une instance de la visionneuse n’affiche que les données des instances distantes, elle peut être mise à jour dès que celles-ci le sont. Si, en revanche, elle affiche également les données de l’instance centrale, la mise à jour de l’instance de la visionneuse ne peut avoir lieu qu’en dernier.

Ce chapitre traite principalement de la mise à niveau vers Checkmk Pro ou Checkmk Community. Vous pouvez également effectuer une mise à niveau vers Checkmk Ultimate en une seule étape, mais dans ce cas, veuillez également vous reporter aux remarques de la section suivante.

Étant donné que les éditions commerciales comportent un certain nombre de modules et de fonctionnalités supplémentaires, il convient de garder à l'esprit quelques points après toute mise à niveau. Le point crucial est que lors de la création de nouvelles instances dans Checkmk Community ou dans l'une des éditions commerciales, des paramètres par défaut différents sont définis.

En ce qui concerne le noyau de supervision et le système de notification, il n’y a aucune différence entre Checkmk Pro et Checkmk Ultimate. Selon l’objectif du déploiement, vous n’utiliserez souvent l’ensemble de fonctionnalités plus étendu que lors de l’ajout de nouveaux ordinateurs hôtes. À certains égards, il est toutefois recommandé de revoir les paramètres existants.

Pour un aperçu complet des fonctionnalités supplémentaires, consultez l'article sur Checkmk Ultimate.

Veuillez noter que dans les environnements distribués, la mise à jour de version doit toujours être effectuée avant que la mise à niveau d’édition puisse suivre. Une séquence différente ou un crossgrade (mise à jour de la version et mise à niveau de l’édition en une seule opération) n’est pas pris en charge. En règle générale, nous recommandons la mise à niveau hors ligne, qui vous permet de passer de n’importe quelle édition inférieure à n’importe quelle édition supérieure.

Pour deux scénarios de mise à niveau fréquemment demandés (de Checkmk Community vers Checkmk Pro et de Checkmk Pro vers Checkmk Ultimate), un fonctionnement mixte est possible pendant une période de temps limitée.

En vue de la rétrogradation de Checkmk Ultimate vers Checkmk Pro, vous devez effectuer au moins les modifications suivantes :

De plus, certains services cloud et tableaux de bord ne seront plus disponibles. Vous devrez donc supprimer les services qui ont disparu.

Si, sous Checkmk Ultimate, vous utilisiez le plugin Grafana provenant du « Grafana Store », vous devrez le remplacer par celui installé à partir de l'archive zip.

L'article sur Checkmk Ultimate fournit un aperçu des différences entre Checkmk Ultimate et Checkmk Pro.

En vue de la rétrogradation de Checkmk Pro vers Checkmk Community, vous devrez effectuer au moins les modifications suivantes :

De plus, certains tableaux de bord, paramètres de graphiques, plugins de notification et agents spéciaux ne sont plus disponibles. L'article Checkmk Pro vous permet de déterminer quelles fonctionnalités de Checkmk Pro seront perdues en cas de passage à Checkmk Community et où vous devrez peut-être procéder à des ajustements supplémentaires.

Les scénarios de rétrogradation présentés dans les deux sections précédentes peuvent également être mis en œuvre dans des environnements distribués. Notez que dans les environnements distribués, la mise à jour de version doit toujours être effectuée avant que la rétrogradation d’édition puisse suivre. Une séquence différente ou une mise à niveau croisée (mise à jour de la version et rétrogradation de l’édition en une seule opération) n’est pas prise en charge.

Il n'existe aucun scénario de rétrogradation dans lequel Checkmk prend en charge une opération mixte entre des éditions différentes. C'est pourquoi nous vous recommandons vivement d'effectuer la rétrogradation d'édition hors ligne. Pour ce faire, procédez comme suit :

Bien entendu, vous pouvez attendre que toutes les instances aient été rétrogradées avant de les redémarrer, ce qui réduira quelque peu le nombre de notifications générées.

La désinstallation des versions de Checkmk qui ne sont plus nécessaires s'effectue à l'aide du gestionnaire de packs du système d'exploitation. Pour ce faire, saisissez le nom du paquet installé – et non le nom du fichier RPM/DEB d'origine.
Important : ne supprimez que les versions de Checkmk qui ne sont plus utilisées par aucune instance !

Les instances Checkmk qui ne sont plus nécessaires peuvent être simplement supprimées à l'aide de la commande « omd rm » (ce qui effacera également toutes les données !) :

Utilisez la commande ci-dessous pour identifier les paquets installés :

La désinstallation s'effectue à l'aide de la commande « dpkg --purge » :

Voici comment identifier les paquets Checkmk utilisés dans les systèmes basés sur RPM :

La suppression s'effectue à l'aide de la commande « rpm -e » :