Mise à jour de la version {current-major}

Les mises à jour de Checkmk doivent toujours être effectuées de la dernière version de patch de la version source vers la dernière version de patch de la version cible. Une mise à jour de la version 2.3.0p1 vers la version 2.4.0p24 suit donc le chemin d'accès suivant :

2.3.0p1 2.3.0p45 2.4.0p24

Les versions majeures ne peuvent pas être ignorées. Si vous souhaitez effectuer une mise à jour de la version 2.2.0 vers la version 2.4.0, effectuez d'abord une mise à jour vers la version 2.3.0.

Comme pour toute mise à jour d'un logiciel de production, vous devez vérifier que vos sauvegardes sont à jour avant de procéder à la mise à jour de Checkmk.

Cela vous concerne-t-il ? Oui.

Que devez-vous faire ? Si vous créez vos sauvegardes automatiquement via Setup > Maintenance > Backups, checkez sur ce site que vos sauvegardes sont à jour et que les tâches de sauvegarde les plus récentes se sont déroulées sans erreur.

Pour plus d'informations, consultez les articles sur les sauvegardes et sur la sauvegarde et la restauration d'instances.

L'2.4.0 de Checkmk nécessite des ressources système légèrement supérieures à celles requises par 2.3.0. Il est donc conseillé de vérifier, avant la mise à jour, de quelle capacité disponible disposent encore les serveurs utilisés pour Checkmk.

Cela vous concerne-t-il ? Oui, mais l'ampleur de l'impact dépend fortement de la manière dont vous utilisez Checkmk.

Que devez-vous faire ? Assurez-vous qu’il y a suffisamment de capacité disponible. Pour plus d’informations sur les changements attendus dans l’utilisation des ressources matérielles, veuillez vous reporter au tableau suivant :

Certaines distributions obsolètes ne seront plus prises en charge par la version 2.4.0 de Checkmk.

Cela vous concerne-t-il ? Cela vous concernera si l'une des distributions Linux suivantes — encore prises en charge dans la version 2.3.0 — est installée sur votre serveur Checkmk :

Checkmk 2.4.0 utilise de nouvelles fonctionnalités JavaScript qui ne sont pas disponibles dans les navigateurs plus anciens. Vous trouverez la liste des navigateurs pris en charge et leurs versions respectives dans la section Configuration système requise.

Cela vous concerne-t-il ? En général, les mises à jour automatiques vers la dernière version sont activées sur les systèmes de bureau.

Que devez-vous faire ? Check la version du navigateur que vous utilisez et installez une version plus récente si nécessaire. Si vous utilisez des ordinateurs monocarte, des téléviseurs intelligents ou des solutions d’affichage numérique pour afficher des tableaux de bord et que vous n’avez aucun contrôle sur le navigateur du système, vérifiez que tous les tableaux de bord requis s’affichent correctement avant de procéder à la mise à jour. Si nécessaire, contactez le fabricant du matériel pour obtenir des mises à jour.

Jusqu’à la version Checkmk 2.2.0, chaque utilisateur de l’automatisation pouvait se connecter à l’aide d’un nom d’utilisateur et d’un mot de passe transmis via des paramètres GET. Cette option a été restreinte à partir de la version Checkmk 2.3.0 et sera complètement supprimée dans la version 2.5.0 (Werk #16223). À moyen terme, vous devrez donc faire évoluer vos scripts vers une authentification via les en-têtes HTTP.

Dans un premier temps, 2.3.0 a rendu configurable l'option de connexion via le paramètre GET. Cependant, le paramètre global Enable automation user authentication via HTTP parameters utilisait initialement on comme valeur par défaut. Dans Checkmk 2.4.0, la valeur par défaut passe désormais à off.

Cela vous concerne-t-il ? Ce changement concerne principalement les utilisateurs qui affichent des tableaux de bord à l'aide d'ordinateurs monocarte, de téléviseurs intelligents ou de solutions d'affichage numérique sans clavier connecté.

Que devez-vous faire ? Si vous utilisez le login automatique via des paramètres GET, vous devez modifier le paramètre global Automation user authentication via HTTP parameters en on. Étant donné que la possibilité de se connecter via des paramètres GET sera complètement supprimée avec Checkmk 2.5.0, vous devriez basculer le login de ces tableaux de bord vers Basic Auth (par exemple, via une extension de navigateur).

Checkmk 2.3.0 est la dernière version prenant en charge ntopng dans ses versions 5.x et 6.x (Werk #16483). Avec Checkmk 2.4.0 , la prise en charge de ntopng 5.x est interrompue et seul ntopng 6.x sera pris en charge.

Cela vous concerne-t-il ? Ce changement concerne les utilisateurs des éditions commerciales qui utilisent l'intégration avec ntopng.

Que devez-vous faire ? Mettez à jour vos installations ntopng vers la version 6.x avant de mettre à jour Checkmk vers la version 2.4.0.

Si des agents spéciaux sont configurés pour un ordinateur hôte, dans Checkmk 2.4.0, tous ces agents spéciaux seront exécutés. Dans les versions antérieures, un seul agent spécial était exécuté, à savoir le premier dans l'ordre alphabétique.

Cela vous concerne-t-il ? Ce changement ne concerne que les ordinateurs hôtes dont l'attribut « Checkmk agent / API integrations » est défini sur « API integrations if configured, else Checkmk agent » dans leurs propriétés.

Il est possible que vous ayez créé par inadvertance des règles qui ont attribué plus d’agents spéciaux aux ordinateurs hôtes que nécessaire. Ces règles supplémentaires étaient auparavant ignorées si elles se trouvaient après la première dans l’ordre alphabétique. Exemple : vous avez créé des règles pour agent_acme et des règles pour agent_cyberdyne et avez attribué ces règles aux mêmes ordinateurs hôtes en raison d’un petit oubli. Dans Checkmk 2.4.0, non seulement agent_acme mais aussi agent_cyberdyne seront désormais exécutées pour ces ordinateurs hôtes.

La version 2.4.0 de Checkmk met à jour Python vers la version 3.12.3. Cette mise à jour affecte les modules installés sur une instance Checkmk. Dans de nombreux cas, les modules installés a posteriori sont incompatibles avec Python 3.12.3. Dans le pire des cas, les modules obsolètes écrasent les fonctionnalités des modules fournis par Checkmk.

Cela vous concerne-t-il ? Cela s'applique à vous si des modules Python ont été installés sur votre instance. Cela peut être le cas, par exemple, si vous avez précédemment installé des modules Python pour des agents spéciaux ou des plugins de supervision que vous avez écrits vous-même ou obtenus via l'Exchange.

L'utilisation du contrôle actif check_sql pour la supervision des bases de données Oracle nécessite également une attention particulière : Jusqu'à la version Checkmk 2.3.0 p27, vous deviez installer le module oracledb pour pouvoir utiliser ce contrôle. Depuis la version 2.3.0 p28, ce module est fourni avec Checkmk (Werk #17370).

Pour vérifier si les modules Python ont été installés sur votre instance, recherchez les répertoires dist-info et egg-info :

Si le résultat de la recherche n'est pas une liste vide, vous devrez prendre des mesures.

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, et peuvent être situés dans des paquets d'extension ou simplement « éparpillés ». Les fichiers locaux peuvent poser des problèmes lors d'une mise à jour s'ils ne correspondent plus à la nouvelle version de Checkmk.

Cela vous concerne-t-il ? Étant donné que Checkmk ne peut pas garantir entièrement la compatibilité des adaptations locales lors d’une mise à jour, vous devriez vérifier votre instance Checkmk avant une mise à jour afin de déterminer si des fichiers locaux sont utilisés, lesquels et comment ils sont organisés.

Commencez par utiliser mkp list pour rechercher les paquets d'extension (MKP) présents dans l'instance.

Utilisez également mkp find pour obtenir un aperçu des fichiers locaux non packagés sur votre instance Checkmk.

Si le résultat de l'une de ces instructions, ou des deux, n'est pas vide, vous devrez prendre des mesures.

Dans Checkmk 2.3.0, certaines interfaces de programmation (API) qui avaient été définies de manière ad hoc dans les versions antérieures ont déjà été remplacées par des API versionnées et bien spécifiées. Les anciennes API pouvaient continuer à être utilisées en parallèle. Avec Checkmk 2.4.0, aucune mesure supplémentaire n’est prise pour maintenir la compatibilité avec les anciennes API (Werk #17201). Cela signifie que les plugins utilisant les anciennes API ne fonctionneront plus avec Checkmk 2.4.0.

Cela vous concerne-t-il ? Le thème des API vous concerne si vous avez étendu les plugins de supervision fournis avec Checkmk à l'aide de vos propres plugins développés en interne et/ou si vous utilisez des plugins provenant d'autres sources.

Les ressources obsolètes ou paramètres de l'API REST Checkmk sont signalés dans la documentation de l'API par l'icône .

Cela vous concerne-t-il ? Cela peut vous concerner si vous utilisez l'API REST Checkmk dans vos propres scripts, par exemple.

Que devez-vous faire ? Ouvrez la documentation de l'API REST à l'adresse Help > Developer Resources > REST API documentation. Recherchez Deprecated dans le navigateur sur la page, vérifiez si vous utilisez des éléments obsolètes dans vos scripts et remplacez-les avant de procéder à la mise à jour. Dans la documentation de l'API REST, vous trouverez généralement des instructions sur la manière de remplacer les fonctions qui n'existent plus dans la nouvelle version.

Comme dans chaque version de Checkmk, la version actuelle 2.4.0 comporte également des modifications du logiciel qui peuvent avoir des répercussions sur votre installation Checkmk — chez Checkmk, celles-ci sont répertoriées et documentées dans ce que nous appelons nos Checkmk Werks. Une modification dite « incompatible » nécessite que vous effectuiez des modifications manuelles afin de permettre aux fonctions existantes de continuer à fonctionner comme d’habitude et/ou de pouvoir utiliser de nouvelles fonctions.

Cela vous concerne-t-il ? En général, il y aura des modifications incompatibles qui affecteront également votre installation Checkmk, mais il est toutefois impossible de faire une déclaration générale. Dans cet article, nous avons réalisé une collection des problèmes qui s’appliquent à toutes ou à la plupart des installations Checkmk. Dans tous les cas, il peut y avoir des modifications supplémentaires qui vous concernent, par exemple au niveau des contrôles que vous utilisez dans votre installation.

Que devrez-vous faire ? Après chaque mise à jour — y compris les versions de correctifs — Checkmk vous indiquera le nombre et le contenu des modifications incompatibles et vous demandera de les vérifier et d’en prendre note. Avant d’effectuer la mise à jour, c’est le moment idéal pour vérifier s’il existe des modifications par rapport à la version 2.3.0 qui pourraient avoir un impact sur la mise à jour. Depuis Checkmk 2.3.0 , ces Werks ne sont plus conservés, mais sont supprimés lors de la mise à jour après validation d’un dialogue de confirmation (Werk #15292).

Il est également conseillé de vous faire un aperçu des modifications incompatibles de la version 2.4.0 avant la mise à jour : Ouvrez la liste des Werks sur le site web de Checkmk. Dans la description d’un Werk, vous trouverez des informations sur ce que vous devrez peut-être faire pour rendre la modification compatible.

Une fois la mise à jour effectuée, le nombre et le contenu des modifications incompatibles s’afficheront dans l’interface Checkmk et il vous sera demandé de les vérifier et d’en prendre note. Des liens vous aident à vérifier si, en quelques clics, vous utilisez un composant concerné. S’il est certain qu’un Werk n’a aucun impact ou si vous avez effectué les modifications requises, confirmez le Werk via Acknowledge.

Dans cette section, nous décrivons les bonnes pratiques que nous suivons, même lors de la mise à jour d'environnements Checkmk de grande envergure. Celles-ci ne sont certes pas obligatoires dans tous les environnements, mais elles peuvent vous faciliter le processus de mise à jour.

Il existe deux procédures différentes pour effectuer une mise à jour de toutes les instances incluses dans une supervision distribuée :

En particulier, si vous souhaitez effectuer une mise à jour pendant que le système est en cours d'exécution, veuillez consulter les remarques figurant dans l'article général consacré aux mises à jour et aux mises à niveau.

Rien n'a fondamentalement changé concernant la mise à jour proprement dite du logiciel dans Checkmk 2.4.0 , c'est-à-dire que vous installez la nouvelle version, effectuez la mise à jour de l'instance Checkmk, résolvez les conflits éventuels, puis vérifiez et confirmez les modifications incompatibles.

Effectuez la procédure de mise à jour comme décrit dans l'article sur les mises à jour et les mises à niveau.

L'interface graphique (GUI) de Checkmk, qui a été entièrement repensée avec la version 2.0.0, n'a pas subi de modifications fondamentales dans la version 2.4.0. Les procédures générales, que vous connaissez déjà grâce aux versions 2.0.0 à 2.3.0, peuvent également être utilisées telles quelles dans la version 2.4.0. Toutefois, les menus, les entrées, les icônes et d'autres détails ont été modifiés afin de rendre les nouvelles fonctionnalités disponibles et d'améliorer celles qui existent déjà.

Nous présenterons ces changements dans les articles de ce guide de l'utilisateur — et vous trouverez dans le Guide du débutant une introduction détaillée, comprenant les éléments les plus importants de l’interface utilisateur.

Comme pour chaque version majeure, Checkmk 2.4.0 introduit un tout nouvel ensemble de plugins de supervision. Si vous n’utilisez pas le « contrôle de découverte », c’est-à-dire la mise à jour automatique de la configuration des services via la reconnaissance du service périodique, vous devrez rechercher les services sur un nombre assez important d’ordinateurs hôtes.

Si vos ordinateurs hôtes sont organisés en conséquence (par exemple dans des dossiers), vous pouvez généralement utiliser la fonction « Bulk discovery » à cette fin. Cette fonction se trouve sous « Setup > Hosts > Hosts », puis dans le menu « Hosts > Run bulk service discovery ».

Dans certains cas, des plugins de supervision ont dû être supprimés ou passer à de nouvelles API.

Cela vous concerne-t-il ? Le risque d’être concerné existe si vous effectuez la supervision du matériel ayant un cycle de vie très long, en particulier avec des agents spéciaux. Lors des préparatifs de la mise à jour d’2.3.0 vers 2.4.0, par exemple, nous avons remarqué les agents spéciaux pour de nombreux périphériques NetApp, que nous avons dû faire passer de l’API ZAPI, désormais obsolète, à l’API REST plus moderne (Werk #16767). Pour des raisons de licence, nous avons dû déplacer l'agent pour Dell PowerConnect vers un paquet distinct disponible dans l'Exchange (Werk #15359).

Que devrez-vous faire ? Si des services disparaissent après la mise à jour, recherchez dans les Werks le fabricant des produits sous supervision. Dans la plupart des cas, vous devrez passer à de nouvelles API ou, dans de rares cas, utiliser des paquets de l'Exchange pour effectuer la supervision d'un composant matériel ou logiciel spécifique.

Cela vous concerne-t-il ? Cela ne s'applique à vous que si vous avez explicitement installé des modules Python pour des agents spéciaux ou des plugins de supervision que vous avez écrits vous-même ou obtenus via l'Exchange, et que vous les avez supprimés lors de la préparation de la mise à jour.

Depuis la version 2.3.0, Checkmk intègre déjà un nouveau contrôle actif pour les connexions HTTP et les certificats. L’Check HTTP web service se trouve sous Setup > Services > HTTP, TCP, Email, …​, dans la case « Networking ». Ce nouveau contrôle est nettement plus performant, plus robuste et plus facile à configurer que l’ancien Check HTTP service. De plus, il est désormais possible de surveiller plusieurs éléments à la fois à l’aide d’une seule règle, par exemple le code de réponse HTTP, le temps de réponse et la validité du certificat.

Dans Checkmk 2.4.0, certaines options rarement utilisées de l'ancienne vérification ont été ajoutées à la nouvelle vérification afin de faciliter la migration. De plus, nous fournissons un script de migration qui effectue l'affectation des appels existants et des services résultants dans un rapport de 1:1. Utilisez ce script pour convertir les services de l'ancienne vérification vers la nouvelle vérification active, car avec Checkmk 2.5.0, aucune nouvelle règle ne peut être configurée pour l'ancienne vérification. Celle-ci sera complètement supprimée ultérieurement.

Une fois la migration terminée, vous pouvez obtenir des gains de performances significatifs en fusionnant plusieurs règles, ce qui permet à une seule exécution du check de produire plusieurs résultats, réduisant ainsi le dépassement de la charge CPU. Dans de nombreux cas, vous pouvez également générer plusieurs services à l'aide d'une seule règle dans le nouveau check.

Vous trouverez des informations générales sur le nouveau check dans les deux Werks n° 15514 et n° 15515. Le Werk n° 17725 décrit le script de migration. Un article de blog détaillé explique les possibilités, les limites et les meilleures pratiques pour préparer et assurer le suivi de la migration.

Si vous rencontrez des applications dans lesquelles la nouvelle check ne peut pas remplacer l'ancienne, vous pouvez afficher la ligne de commande utilisée de la même manière que dans la procédure décrite ici. Vous aurez alors la possibilité d'appeler l'ancienne check, ou une check_http installée à l'échelle du système via Setup > Other services > Integrate Nagios plugins.

Le terme « carte de gestion » désigne des cartes plugin distinctes ou des fonctionnalités BIOS étendues (Baseboard Management Controller/BMC, Management Engine/ME, Lights Out Management/LOM) permettant la supervision et la gestion du matériel en plus du système d'exploitation installé.

Jusqu’à la version Checkmk 2.4.0, les cartes de gestion peuvent être configurées de deux manières : En tant que propriété de l’ordinateur hôte ou en tant qu’ordinateur hôte distinct. La configurabilité en tant que propriété de l’ordinateur hôte étant très limitée, cette option ne sera plus disponible à l’avenir.

La prise en charge des cartes de gestion compatibles Redfish a été ajoutée et améliorée au cours du cycle de vie de Checkmk 2.3.0 , initialement sous forme de MKP optionnel (Werk #16589). Dans Checkmk 2.4.0 , la supervision Redfish fait partie intégrante du logiciel (Werk #17404). Nous fournissons des informations complémentaires et présentons les alternatives possibles dans l'article de blog intitulé « Surveillance des cartes de gestion ».