Valeurs mesurées et graphiques

Le concepteur de graphiques est divisé en quatre sections :

Vous pouvez ici voir le graphique exactement tel qu’il apparaîtra en ligne. Vous pouvez également utiliser toutes ses fonctions interactives.

Les courbes incluses dans les graphiques peuvent être modifiées directement ici. La modification du titre d’une courbe dans ce champ est validée à l’aide de la touche «Enter». L’option «Style» définit la manière dont les valeurs sont affichées dans les graphiques. Voici les options disponibles :

Les trois autres options — Mirrored Line, Mirrored Area et Mirrored Stacked — sont similaires, à l’exception du fait que les courbes sont tracées vers le bas à partir de la ligne zéro. Cela permet d’obtenir un style de graphique tel que celui généralement utilisé par Checkmk dans les graphiques d’entrée/sortie pour ce qui suit :

Dans la colonne « Actions », vous trouverez un bouton « » permettant de cloner chaque métrique que vous avez créée. Grâce à cela, vous pouvez rapidement copier des courbes et simplement remplacer le nom de domaine, par exemple.

La boîte de dialogue « Metrics » vous permet d’ajouter de nouvelles métriques aux graphiques. Dès que vous saisissez un nom de domaine valide dans le premier champ, le deuxième champ s’affiche avec une liste des services de l’ordinateur hôte. En effectuant une sélection dans cette liste, le troisième champ s’affiche avec une liste des métriques de ce service. Dans le quatrième et dernier champ, sélectionnez la fonction de consolidation. Les options disponibles sont « Minimum », « Maximum» et « Average ». Ces fonctions sont utilisées lorsque les données stockées dans les RRD pour la période spécifiée ont déjà été compressées. Dans une période où, par exemple, une seule valeur par demi-heure est disponible, vous pouvez choisir de tracer la valeur mesurée d’origine minimale, maximale ou moyenne pour cette période.

De la même manière, vous pouvez utiliser la fonction Add new scalar pour afficher les valeurs d'un service pour l'WARN, l'CRIT, le maximum et le minimum sous forme de lignes horizontales.

Vous pouvez également ajouter une constante au graphique. Celle-ci sera initialement représentée sous la forme d’ une ligne horizontale. Les constantes sont parfois nécessaires pour générer des formules de calcul. Nous y reviendrons plus tard.

Vous trouverez ici les options qui affectent l'ensemble des graphiques.

Unit influence les étiquettes des axes et des légendes. La valeur par défaut « First entry with unit » spécifie que la première entrée du graphique défini par l'utilisateur dont l’unité est connue est utilisée comme unité. Cela signifie que l’unité des métriques et des scalaires est toujours connue, mais pas celle des constantes. Si aucune entrée ne possède d’unité connue, le graphique s’affiche sans symbole d’unité. Si vous sélectionnez plutôt « Custom », des paramètres supplémentaires s’afficheront, vous permettant de définir vous-même l’unité. Notez qu’il est possible, mais déconseillé, d’ajouter deux métriques avec des unités différentes à un même graphique.

Avec « Explicit vertical range », vous pouvez prédéfinir l’axe vertical d’un graphique. L’ axe Y est normalement mis à l’échelle de manière à ce que toutes les valeurs mesurées dans la période choisie s’inscrivent exactement dans le graphique. Si vous créez un graphique pour des valeurs en pourcentage, par exemple, vous pouvez choisir d’afficher systématiquement les valeurs de 0 à 100. Notez toutefois que les utilisateurs (et vous-même) peuvent dans tous les cas mettre un graphique à l’échelle à l’aide de la souris, rendant ainsi le positionnement inefficace.

Le concepteur de graphiques vous permet de combiner les courbes individuelles à l’aide de calculs. L’exemple suivant montre un graphique comportant deux courbes : l’ utilisation du processeur, pour User et System.

Supposons que, pour ce graphique, vous ne soyez intéressé que par la somme des deux courbes. Pour cela, checkez les cases de sélection des deux courbes. Une fois cette opération effectuée, dans le panneauMetrics , sur la ligneOperation on selected metrics , quelques nouveaux boutons seront apparus pour toutes les opérations éligibles :

En cliquant sur « Sum », vous combinerez les deux courbes en une nouvelle courbe. La couleur de cette nouvelle courbe sera automatiquement un mélange des couleurs des deux courbes d’origine. La nouvelle courbe sera intitulée « Sum of User, System ». La formule utilisée pour le calcul s’affichera dans la colonne « Formula ». De plus, un nouveau symbole « » apparaîtra :

Cliquer sur « » (Annuler la fusion) revient à « annuler » l’opération, ce qui permet d’afficher à nouveau les courbes individuelles d’origine. Autres conseils pour les opérations de calcul :

Lorsque vous consultez les valeurs mesurées par le passé, vous n'êtes parfois pas intéressé par les détails exacts de leur évolution sur une période de temps donnée. Un simple résumé approximatif peut s'avérer plus utile, par exemple l'utilisation du processeur au cours des 7 derniers jours. Dans cet exemple, le résultat serait simplement un chiffre exprimé en pourcentage, tel que 88 %.

Dans un tableau d'hôtes ou de services, vous pouvez ajouter des colonnes représentant la moyenne, le minimum, le maximum ou d'autres résumés d'une métrique sur une période de temps donnée. Cette fonctionnalité vous permet également de créer des rapports triés selon ces colonnes, par exemple pour afficher la liste des hôtes ESXi ayant présenté l'utilisation la plus faible au cours de la période de temps sélectionnée.

Pour afficher ces valeurs mesurées dans une vue de la table, procédez comme suit :

Vous devez d’abord disposer d’une vue à laquelle vous souhaitez ajouter des colonnes. Il peut s’agir d’une vue des ordinateurs hôtes ou des services. Pour plus de détails sur la création ou l’édition des vues de la table, consultez l’article consacré aux vues.

Pour l'exemple suivant, nous choisissons la vue de la table « All hosts », que vous pouvez ouvrir via Monitor > Hosts > All hosts. Dans le menu, sélectionnez « Display > Customize view ». Vous accédez alors à la page « Clone view », où vous pouvez personnaliser la vue à votre guise.

Afin que la vue d'origine All hosts ne soit pas masquée par la copie, choisissez un nouvel identifiant ainsi qu'un nouveau titre sous lequel la vue s'affichera ultérieurement dans le menu Monitor.

Ensuite (facultatif), supprimez toutes les colonnes indiquant le nombre de services dans les différents États.

Ajoutez maintenant une colonne de type « Services: Metric History ». Comme il s’agit d’une colonne de services, dans le cas d’une vue de l’ordinateur hôte, vous devez sélectionner le type de colonne « Joined column » en premier, ce qui permet l’affichage d’une colonne de service dans un tableau d’ordinateur hôte. Avec une vue de service, il suffit d’ajouter une nouvelle « Column ».

Dans « Metric », sélectionnez le nom de la métrique à évaluer historiquement. Si vous n’êtes pas sûr du nom de la métrique, vous pouvez le trouver dans les détails du service, à l’entrée « Service Metrics » :

Dans l'exemple, nous choisissons la métrique « CPU utilization », qui correspond d'ailleurs au nom du service.

Avec RRD consolidation, il est préférable de choisir la même valeur que celle utilisée ci-dessous dans Aggregation function, car il serait peu pertinent de calculer des valeurs telles que « le minimum du maximum ». Vous découvrirez en quoi consiste l'option de sélection pour les RRD dans le chapitre suivant consacré à l'organisation des données RRD.

L'option « Time range » correspond à la période de temps passée que vous souhaitez analyser. Dans l'exemple, il s'agit des sept derniers jours, soit exactement 168 heures.

Dans l'exemple, nous choisissons « Util @ 7 days » comme « Column title ». Ne soyez pas surpris si un champ intitulé « Title » apparaît plus tard — vous ne le verrez que si un « Joined column » est utilisé ici, ce qui permet toujours de spécifier un titre. Laissez simplement le deuxième titre vide.

Enfin, dans le champ « Of Service », saisissez le nom du service auquel appartient la métrique sélectionnée ci-dessus. Veillez à respecter l'orthographe exacte du service, y compris les majuscules et les minuscules.

Une fois l'enregistrement effectué, vous obtiendrez une nouvelle vue de la table avec une colonne supplémentaire indiquant le pourcentage de charge de travail du processeur au cours des sept derniers jours.

Remarques

Par défaut, Checkmk est configuré de manière à ce que l'évolution de chaque métrique soit enregistrée sur une période de quatre ans. La résolution de base utilisée est d'une minute. Cela est logique, car l'intervalle de vérification est préréglé sur une minute, de sorte que de nouvelles données mesurées sont reçues exactement une fois par minute de chaque service.

Évidemment, le stockage d’une valeur par minute sur une période de quatre ans nécessitera un espace disque considérable (bien que les RRD ne nécessitent que 8 octets par valeur mesurée). C’est pourquoi, au fil du temps, les données sont compressées. La première compression intervient au bout de 48 heures. À partir de ce moment, une seule valeur sera stockée toutes les cinq minutes. D’autres étapes sont mises en œuvre après 10 jours et 90 jours :

La question qui se pose naturellement est la suivante : comment regrouper au mieux cinq valeurs de manière pertinente en une seule ? Pour cela, les fonctions de regroupement — maximum, minimum et moyenne — sont disponibles. Ce qui est pertinent dans la pratique dépend de l'application ou de la vue de la table. Si, par exemple, vous souhaitez effectuer la supervision des fluctuations de température dans un centre de données sur une période de quatre ans, la température maximale enregistrée est probablement la plus intéressante. Pour les taux d’accès d’une application, une moyenne pourrait présenter davantage d’intérêt.

Afin d’obtenir une flexibilité maximale pour les calculs ultérieurs, les RRD de Checkmk sont simplement préréglés pour stocker les trois valeurs à la fois — minimum, maximum et moyenne. Pour chaque niveau de compression et chaque fonction de consolidation, le RRD comprend un mode de stockage de type « anneau » — ce qu’on appelle une archive Round Robin (RRA). Dans la structure standard, il y a 12 RRA. La structure standard de Checkmk nécessite donc 384 952 octets par métrique. Ce chiffre est obtenu en additionnant : 2 880 + 2 880 + 4 320 + 5 840 points de mesure, multipliés par trois fonctions de consolidation, multipliés par 8 octets par valeur mesurée — ce qui donne un total de 382 080 octets exactement. En ajoutant l’en-tête de fichier de 2 872 octets, on obtient la taille finale de 384 952 octets mentionnée ci-dessus.

Une alternative intéressante consisterait, par exemple, à stocker une valeur par minute pendant une année entière. Cette méthode présenterait un petit avantage : les RRD auraient à tout moment la résolution optimale et pourraient ainsi se passer de consolidation, pour ne générer par exemple que des valeurs moyennes. En calculant 365 x 24 x 60 valeurs mesurées, multipliées par 8 octets, on obtient un total de près de 4 Mo exactement par métrique. De cette manière, bien que les RRD aient un besoin de stockage dix fois supérieur, les « E/S disque » sont en réalité réduites ! La raison en est qu’il n’est plus nécessaire de stocker et de mettre à jour douze RRA distincts ; un seul suffit.

Si le schéma de stockage prédéfini ne vous convient pas, il peut être modifié via des jeux de règles (et il est même possible d’avoir des versions différentes par ordinateur hôte ou par service). Le jeu de règles requis se trouve très facilement via la recherche de règles — c’est-à-dire le menu «Setup » — et une fois là, il suffit de saisir «RRD ». Vous y trouverez le jeu de règles « Configuration of RRD databases of services ». Il existe également un jeu de règles similaire pour les ordinateurs hôtes, mais les ordinateurs hôtes ne disposent de valeurs mesurées que dans des cas exceptionnels. L'image ci-dessous montre la règle RRD avec ses paramètres par défaut :

Sous « Consolidation functions » et « RRA configuration », vous pouvez définir et configurer le nombre et la taille des phases de compression prêtes à être utilisées par les consolidations. Le champ « Step (precision) » définit la résolution en secondes, et en règle générale, elle est de 60 secondes (une minute). Pour les services dont l’intervalle de vérification est inférieur à une minute, il peut être judicieux de réduire cette valeur. Notez toutefois que la valeur du champ « Number of steps aggregated into one data point » ne représentera plus des minutes, mais l’intervalle de temps défini dans « Step (precision) ».

Toute modification apportée à la structure des RRD n’affecte initialement que les RRD nouvellement créés, c’est-à-dire les ordinateurs hôtes ou les services récemment intégrés à la supervision. Vous pouvez également autoriser Checkmk à restructurer les RRD existants. Cette opération s’effectue à l’aide de l’instruction cmk-convert-rrds, pour laquelle l’option -v (verbose) est toujours disponible. Checkmk inspectera alors tous les RRD existants et les restructurera si nécessaire selon le format cible défini.

L'instruction est suffisamment intelligente pour reconnaître les fichiers RRD qui possèdent déjà la structure souhaitée :

Si le nouveau format présente une résolution plus élevée ou des fonctions de consolidation supplémentaires, les données existantes seront interpolées du mieux possible afin que les RRD contiennent les valeurs les plus significatives possibles. Il est toutefois évident que si, par exemple, au lieu de 2 jours, vous avez désormais besoin de 5 jours avec des valeurs à intervalles d'une minute, la précision des données existantes ne peut pas être augmentée rétroactivement.

La règle décrite ci-dessus comporte un paramètre supplémentaire : « RRD storage format ». Celui-ci vous permet de choisir entre deux méthodes que Checkmk peut utiliser lors de la création des RRD. Le format « One RRD per host/service » (format Checkmk, en abrégé) stocke toutes les métriques d’un ordinateur hôte ou d’un service dans un seul fichier RRD. Cela permet une écriture plus efficace des données sur un disque, de sorte qu’un ensemble complet de métriques puisse toujours être écrit en une seule opération. Ces métriques se trouvent alors dans des blocs de stockage adjacents, ce qui réduit le nombre de blocs devant être écrits sur le disque.

Si vos instances Checkmk ont été créées avec une édition commerciale dans une version antérieure à 1.2.8, vous souhaiterez peut-être vérifier si vos données mesurées ont déjà été converties au format actuel, bien plus efficace. Si les données sont toujours stockées au format PNP, vous pouvez les convertir au format Checkmk en appliquant une règle comme indiqué dans le jeu de règles ci-dessus.

Ici aussi, vous aurez besoin de l'instruction cmk-convert-rrds, et, encore une fois, arrêtez toujours votre instance avant de convertir les RRD existants.

Comme l'indique l'avertissement, Checkmk laisse dans un premier temps les fichiers existants inchangés. Cela vous permet, en cas de doute, de revenir au format de données d'origine, car une conversion dans le sens inverse n'est pas possible. L'option --delete-rrds garantit que cette copie n'est pas créée ou qu'elle est supprimée ultérieurement. Vous pouvez facilement effectuer la suppression manuellement par la suite en utilisant à nouveau l' instruction :

Afin de réduire (considérablement) le nombre d’accès en écriture à un disque dur, un service auxiliaire peut être utilisé : le daemon de cache RRD (rrdcached). Il s’agit de l’un des services de l’instance démarrés automatiquement.

Toutes les nouvelles valeurs mesurées pour les RRD sont envoyées depuis le Checkmk Micro Core (éditions commerciales) ou depuis le NPCD (Checkmk Community) vers le rrdcached. Celui-ci n’écrit pas les données directement dans les RRD, mais les conserve plutôt en mémoire principale pour les écrire ultérieurement sous forme de collection dans le RRD correspondant. De cette manière, le nombre d’accès en écriture au disque dur (ou au SAN !) est sensiblement réduit.

Afin qu’aucune donnée ne soit perdue en cas de redémarrage, les mises à jour sont en outre enregistrées dans des fichiers journaux. Il s’agit également d’accès en écriture, mais comme les données sont organisées de manière séquentielle, ils génèrent peu d’E/S.

Pour que le daemon de cache RRD puisse fonctionner efficacement, il a besoin de beaucoup de mémoire principale. La quantité requise dépend du nombre de RRD et de la durée pendant laquelle les données doivent être mises en cache. Ce dernier paramètre peut être défini dans le fichier ~/etc/rrdcached.conf. Le réglage par défaut est un stockage de 7 200 secondes (deux heures) — cette valeur peut être personnalisée par l’utilisateur — plus une plage aléatoire comprise entre 0 et 1 800 secondes. Ce délai aléatoire par RRD évite les écritures « pulsées » et garantit une répartition régulière des E/S dans le temps :

Appliquez les modifications apportées aux paramètres de ce fichier à l’aide de :

Voici un aperçu des fichiers et répertoires les plus importants associés aux valeurs mesurées et aux RRD (tous ceux liés au répertoire personnel du site) :