 |
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. Les particularités du Checkmk Micro Core
Les principaux avantages du CMC résident dans ses performances supérieures et ses temps de réponse plus rapides par rapport au noyau de supervision du projet libre Nagios. Il présente d’autres avantages intéressants que vous devriez connaître, dont les plus importants sont les suivants :
Smart Ping — Vérifications intelligentes des ordinateurs hôtes
Processus d'aide Check helper, récupérateur de données Checkmk et Checkmk Checker
Planification initiale
Processus de traitement des données de performance
Certaines fonctions de Nagios ne sont pas utilisées ou sont réalisées selon une procédure différente dans le CMC. Vous trouverez plus de détails à ce sujet dans l’article consacré à la migration vers le CMC.
2. Smart Ping — Vérifications intelligentes des ordinateurs hôtes
Avec Nagios, la disponibilité des ordinateurs hôtes est généralement vérifiée à l’aide d’un ping.
À cette fin, pour chaque ordinateur hôte, un plugin tel que check_ping ou check_icmp est exécuté une fois par intervalle (généralement une fois par minute).
Cela envoie, par exemple, cinq paquets ping et attend leur retour.
La création des processus nécessaires à l’exécution des plugins mobilise de précieuses ressources CPU.
De plus, ceux-ci peuvent s’accumuler pendant un certain temps si un ordinateur hôte est inaccessible, ce qui entraîne de longs timeout.
En revanche, CMC effectue des vérifications d’ordinateurs hôtes — sauf configuration contraire — à l’aide d’une procédure appelée Smart Ping.
Smart Ping s’appuie sur un composant interne appelé icmpsender, qui dispose de sa propre implémentation de ping.
Étant donné que Checkmk avec CMC ne s'appuie pas sur un binaire externe, il n'est pas nécessaire de lancer un nouveau processus pour chaque paquet ping envoyé.
De plus, le comportement par défaut d'icmpsender diffère de celui de son homologue Nagios.
Au lieu d'une série rapide de paquets multiples pour lesquels on attend une réponse, icmpsender n'envoie qu'un seul paquet ICMP par ordinateur hôte toutes les n secondes (la valeur par défaut est de 6 secondes, configurable via le jeu de règles « Normal check interval for host checks »).
Ce comportement réduit considérablement la consommation de ressources et le trafic de données.
Les réponses aux pings ne sont pas explicitement attendues.
Le composant « icmpreceiver » du CMC est chargé de déterminer si l’état d’un ordinateur hôte est « UP » ou « DOWN ».
Le CMC traite les paquets ping entrants provenant d’un ordinateur hôte comme une vérification d’ordinateur hôte réussie et marque donc l’ordinateur hôte comme « UP ».
Si aucun paquet n’est reçu d’un ordinateur hôte dans un délai défini, cet ordinateur hôte sera signalé comme « DOWN ».
Le timeout est préréglé à 15 secondes (2,5 intervalles de temps) et peut être modifié pour chaque ordinateur hôte à l’aide du jeu de règles « Settings for host checks via Smart PING ».
Le composant icmpreceiver écoute également les paquets TCP SYN (synchronisation) et RST (réinitialisation) provenant d’un ordinateur hôte.
Lorsqu’il reçoit de tels paquets, l’ordinateur hôte est considéré comme UP.
Ce mécanisme peut entraîner des états instables des ordinateurs hôtes dans les infrastructures où le trafic ICMP n’est pas autorisé, mais où le trafic TCP l’est.
 |
|
2.1. Pas de vérifications d'ordinateurs hôtes à la demande
Les vérifications d’ordinateur hôte servent non seulement à déclencher des notifications en cas de panne totale d’un ordinateur hôte, mais aussi à supprimer les notifications de problèmes de service pendant une période de maintenance planifiée de l’ordinateur hôte. Des problèmes de service peuvent survenir sans que la responsabilité en incombe au service lui-même, mais plutôt à une condition de défaillance de l’ordinateur hôte. Il peut arriver qu’un ordinateur hôte soit en réalité en état « DOWN » même si son dernier état connu dans Checkmk est « UP », conformément au résultat de la dernière vérification de l’ordinateur hôte. Dans une telle situation, plusieurs vérifications de service pourraient signaler des problèmes dépendant de l’état « DOWN » de l’ordinateur hôte, ce qui entraînerait l’envoi de notifications de service — à tort. En cas de problème de service, il est donc important de déterminer d’abord la condition de l’ordinateur hôte du service.
Le CMC résout ce problème très simplement : si un problème de service survient et que l’ordinateur hôte est dans un état « UP », le CMC attendra la prochaine vérification de l’ordinateur hôte. L’intervalle étant très court (seulement 6 secondes par défaut), le délai avant l’envoi d’une notification est négligeable — si l’ordinateur hôte est toujours « UP » et que la notification doit donc être envoyée pour le service.
Prenons, à titre d’exemple, le cas d’un plugin check_http renvoyant un état « CRIT » (indisponible), car le serveur web interrogé est indisponible.
Dans cette situation, après le début de la vérification du service, un paquet TCP RST (connexion refusée) sera reçu de ce serveur par le composant icmpreceiver.
Le CMC sait donc avec certitude que l’ordinateur hôte lui-même est « UP » (indisponible) et peut ainsi envoyer la notification sans délai.
Le même principe est utilisé lors du calcul des pannes de réseau si des hôtes parents ont été définis. Ici aussi, les notifications seront parfois brièvement retardées afin d’attendre un état vérifié.
2.2. Les avantages
Cette procédure présente plusieurs avantages :
Une charge CPU pratiquement négligeable résultant des checks d’ordinateurs hôtes — même sans matériel particulièrement puissant, des dizaines de milliers d’ordinateurs hôtes peuvent être supervisés.
Aucune perturbation de la supervision due à des blocages lors des checks d'ordinateurs hôtes à la demande si les ordinateurs hôtes sont en mode « DOWN ».
Pas de fausses alertes provenant des services lorsque l'état d'un ordinateur hôte n'est pas à jour.
Il ne faut toutefois pas passer sous silence un inconvénient : les vérifications des ordinateurs hôtes Smart Ping ne génèrent aucune donnée de performance (temps de transit des paquets).
Sur les ordinateurs hôtes où celles-ci sont requises, vous pouvez simplement configurer une check active via ping avec le jeu de règles « Check hosts with PING (ICMP Echo Request) ».
2.3. Ordinateurs hôtes non pingables
Dans la pratique, tous les ordinateurs hôtes ne sont pas vérifiables par ping. Dans ces cas, d'autres méthodes de CMC peuvent également être utilisées pour la vérification de l'ordinateur hôte, par exemple une connexion TCP. Comme il s'agit généralement d'exceptions, elles n'ont pas d'impact négatif sur les performances globales. Le jeu de règles utilisé ici est « Host check command ».
2.4. Problèmes avec les pare-feu
Certains pare-feu répondent aux paquets de connexion TCP destinés à des ordinateurs hôtes inaccessibles par un paquet TCP RST. Le problème est que le pare-feu n’est pas autorisé à s’identifier comme l’expéditeur de ce paquet ; l’adresse IP de l’ordinateur hôte cible doit plutôt être spécifiée. Smart Ping interprète ce paquet comme un signe de vie et suppose à tort que l’ordinateur hôte cible est accessible.
Dans une telle situation (rare), via Global settings > Monitoring core > Tuning of Smart PING, vous avez la possibilité d’activer l’option « Ignore TCP RST packets when determining host state ».
Ou, via check_icmp, vous pouvez sélectionner un ping classique comme check d’ordinateur hôte pour les ordinateurs hôtes concernés.
3. Processus d'aide
L'une des leçons à tirer des mauvaises performances de Nagios dans les environnements de grande envergure est que la création de processus est une opération qui mobilise des ressources et prend du temps. La taille du processus parent est ici le facteur déterminant. À chaque exécution d’une vérification active, le processus Nagios complet doit d’abord être dupliqué (forké) avant d’être remplacé par le nouveau processus — le plugin de supervision. Plus le nombre d’ordinateurs hôtes et de services à superviser est élevé, plus ce processus est volumineux et plus le fork prend du temps. Pendant ce temps, les autres tâches du noyau du processeur doivent attendre — et dans ce cas, 24 cœurs de processeur ne sont pas d’une grande aide.
3.1. Check helper
Afin d’éviter de forker le noyau du processeur, lors du démarrage du programme, le CMC crée un nombre fixe de processus d’aide très légers dont la tâche consiste à lancer les plugins de supervision actifs : les check helpers.
Non seulement ceux-ci se forquent beaucoup plus rapidement, mais le fork s’étend également à tous les cœurs disponibles, car le noyau du processeur lui-même n’est plus bloqué.
De cette manière, l’exécution des checks actifs (par exemple check_http) — dont les durées d’exécution sont en réalité assez courtes — est considérablement accélérée.
3.2. Récupérateur de données Checkmk et Checkmk Checker
Le CMC va toutefois bien plus loin — car dans un environnement Checkmk, les contrôles actifs constituent plutôt une exception. Ici, on utilise principalement des contrôles basés sur Checkmk — pour lesquels un seul processus par ordinateur hôte et par intervalle est nécessaire.
Afin d’optimiser l’exécution de ces contrôles, le CMC gère deux autres types de processus d’aide : les récupérateurs de données Checkmk et les Checkmk Checkers.
Les récupérateurs de données Checkmk
Les récupérateurs de données Checkmk récupèrent les informations requises auprès des ordinateurs hôtes surveillés, c'est-à-dire les données provenant des servicesCheck_MK etCheck_MK Discovery . Les récupérateurs de données prennent ainsi en charge la communication réseau avec les agents Checkmk, les agents SNMP et les agents spéciaux. La collecte de ces informations prend un certain temps, mais comme chaque processus nécessite généralement moins de 50 mégaoctets — ce qui représente relativement peu de mémoire —, il est possible de configurer plusieurs processus sans problème. Gardez à l’esprit que les processus peuvent être partiellement ou pas du tout transférés vers le disque et doivent donc toujours être conservés en mémoire physique. Le facteur limitant ici est la mémoire disponible sur le serveur Checkmk.
|
Les 50 mégaoctets mentionnés ci-dessus constituent une estimation à titre indicatif. La valeur réelle peut être supérieure dans certaines circonstances — par exemple, parce que l'IPMI a été configuré sur la carte de gestion. |
Les Checkmk Checkers
Les Checkmk Checkers analysent et évaluent les informations collectées par les récupérateurs de données Checkmk et génèrent les résultats de vérification pour les services. Les Checkmk Checkers ont besoin de beaucoup de mémoire car ils doivent inclure la configuration Checkmk. Un processus de Checkmk Checker occupe au moins environ 90 mégaoctets — toutefois, un multiple de cette valeur peut être nécessaire, selon la manière dont les vérifications sont configurées. En revanche, les vérificateurs ne génèrent aucune charge réseau et s’exécutent très rapidement. Le nombre de vérificateurs ne doit pas dépasser la capacité de traitement en parallèle de votre serveur Checkmk. En règle générale, ce nombre correspond au nombre de cœurs de votre serveur. Comme les vérificateurs ne sont pas limités par les E/S, ils sont plus efficaces si chaque vérificateur dispose de son propre noyau du processeur.
La répartition des deux tâches distinctes « collecte » et « exécution » entre le récupérateur de données Checkmk et le Checker Checkmk existe depuis la version 2.0.0 de Checkmk. Auparavant, il n’existait qu’un seul type de processus d’aide chargé des deux tâches : les « Checkmk helpers ».
Avec le modèle « fetcher/checker », ces deux tâches sont désormais réparties entre deux pools de processus distincts : la récupération d’informations sur le réseau, assurée par de nombreux petits processus « fetcher », et la vérification, très gourmande en ressources de calcul, assurée par quelques grands processus « checker ». En conséquence, un CMC utilise jusqu’à quatre fois moins de mémoire pour une performance identique (vérifications par seconde) !
3.3. Définir correctement le nombre de processus d'aide
Le nombre d’assistants de vérification (vérifications actives), de récupérateurs de données Checkmk et de Checkmk Checkers lancés par défaut est défini sous « Global settings > Monitoring core » et peut être personnalisé par vos soins :
Pour savoir si et comment vous devez modifier les valeurs par défaut, plusieurs options s’offrent à vous :
Dans la barre latérale, le snap-in « Core statistics » vous indique le pourcentage d'utilisation moyen sur les 10 à 20 dernières secondes :
Pour tous les types de processus d'aide, il doit toujours y avoir suffisamment de processus pour exécuter les contrôles configurés. Si un pool est utilisé à 100 %, les contrôles ne seront pas exécutés à temps, la latence augmentera et les états des services ne seront pas à jour.
La charge de travail ne doit pas dépasser 80 % quelques minutes après le démarrage d'une instance. Pour des pourcentages plus élevés, vous devez augmenter le nombre de processus. Étant donné que le nombre nécessaire de récupérateurs de données Checkmk augmente avec le nombre d’ordinateurs hôtes et de services surveillés, une correction est très probable ici. Veillez toutefois à ne créer que le nombre de processus d’aide réellement nécessaire, car chaque processus occupe des ressources. De plus, tous les processus d’aide sont initialisés en parallèle au démarrage du CMC, ce qui peut entraîner des pics de charge.
Le snap-in logiciel « Core statistics » vous indique non seulement la charge de travail, mais aussi la latence. Pour ces valeurs, la règle est simple : plus elles sont faibles, mieux c’est — et 0 seconde est donc l’idéal.
|
Vous pouvez également afficher les valeurs indiquées dans le snap-in pour votre instance dans les détails du service OMD <site_name> performance. |
Comme alternative au snap-in « Core statistics », vous pouvez également faire analyser votre configuration par Checkmk, à l’aide de l’option « Setup > Maintenance > Analyze configuration ». L’avantage ici est que vous obtenez une évaluation immédiate de l’état des processus d’aide par Checkmk. Il est très pratique de pouvoir, si l’un des processus d’aide n’est pas « OK », ouvrir l’option « Global settings » correspondante à partir du texte d’aide afin de modifier la valeur du processus.
4. Configuration initiale de la planification
Lors de la planification, on définit quelles vérifications doivent être exécutées et à quels moments. Nagios a mis en place de nombreuses procédures visant à garantir que les vérifications soient réparties de manière régulière sur l’intervalle. De même, Nagios s’efforce de répartir uniformément les requêtes à exécuter sur un système cible donné tout au long de l’intervalle de temps.
Le CMC dispose de sa propre procédure, plus simple, à cet effet. Celle-ci tient compte du fait que Checkmk contacte déjà un ordinateur hôte une fois par intervalle. De plus, le CMC garantit que les nouvelles vérifications sont exécutées immédiatement et ne sont pas réparties sur plusieurs minutes. Ceci est très pratique pour l’utilisateur, car un nouvel ordinateur hôte sera interrogé dès que la configuration aura été activée. Afin d’éviter qu’un grand nombre de nouvelles vérifications ne provoque un pic de charge, les nouvelles vérifications dont le nombre dépasse une limite définissable peuvent être réparties sur l’ensemble de l’intervalle. L’option correspondante se trouve sous « Global settings > Monitoring core > Initial scheduling ».
5. Traitement des données de performance
Une fonction importante de Checkmk consiste à traiter les données de mesure, telles que l'utilisation du processeur, et à les conserver pendant une longue période de temps. Dans Checkmk Community, on utilise pour cela PNP4Nagios, qui repose lui-même sur RRDtool.
Le logiciel remplit deux fonctions :
La création et la mise à jour des bases de données Round Robin (RRD).
La représentation graphique des données dans l'interface graphique.
Dans le cadre d’une opération de base de Nagios, la fonction mentionnée au point 1 ci-dessus est un processus assez long.
Selon la méthode utilisée, on a recours à des fichiers spool, à des scripts Perl et à un processus d’aide (npcd) écrit en C.
Enfin, les données partiellement converties sont écrites dans le socket Unix du daemon de cache RRD.
Le CMC raccourcit cette chaîne en écrivant directement dans le daemon de cache RRD — toutes les étapes intermédiaires sont supprimées. L'analyse et la conversion des données au format RRDtool sont effectuées directement en C++. Cette méthode est aujourd'hui possible et judicieuse, car le daemon RRD cache a déjà implémenté son propre système de spooling très efficace ; grâce aux fichiers journaux, cela signifie qu'aucune donnée n'est perdue en cas de plantage du système.
Les avantages :
Réduction des E/S disque et de la charge CPU
Une implémentation plus simple et nettement plus stable
Le CMC crée de nouveaux fichiers RRD à l’aide d’un autre auxiliaire, appelé via cmk-create-rrd.
Cet auxiliaire crée les fichiers soit dans un format compatible avec PNP, soit dans le nouveau format Checkmk (ce qui ne s’applique qu’aux nouvelles installations).
Le passage de Nagios à CMC n’a donc aucun effet sur les fichiers RRD existants.
Ceux-ci continuent d’être gérés de manière transparente.
Dans les éditions commerciales, l’affichage graphique des données dans l’interface graphique est handled directement par l’interface graphique de Checkmk elle-même, de sorte qu’aucun composant PNP4Nagios n’est impliqué.