Économiser des CPUs en identifiant les sondes les plus consommatrices

Une fois que l'on a un parc supervisé, on peut souhaiter de temps en temps procéder à des optimisations sur sa consommation, et tout particulièrement sur sa consommation CPU car elle a un coût non négligeable. Une fois les sondes les plus consommatrices de CPU identifiées, une optimisation de ces dernières sera la méthode la plus efficace afin de consommer moins de CPUs, et possiblement avoir des serveurs plus petits, ou moins de serveurs.

Pour cela, nous allons extraire des informations issues de la commande shinken-scheduler-export-data afin d'avoir:

• le nombre de CPUs utilisés par chaque commande sur l'ensemble des royaumes

Pour cela, nous allons avoir besoin d'un dump de données avec en option une prévision de la charge sur une période, disons par exemple 1 heure. Il suffit alors de lancer la commande comme ceci:

shinken-scheduler-export-data --full --simulation-extra-period=3600

L'importation du fichier .csv généré est décrit dans shinken-scheduler-export-data : export des données du Scheduler

Création du tableau récapitulatif sur la consommation totale des temps CPU des royaumes respectifs

Consolidation des données: utilisation d'un tableau croisé dynamique

A partir des nombreuses données de checks que nous avons, nous allons devoir procéder à une consolidation afin d'avoir notre résultat facilement exploitable. Pour cela nous allons utiliser un tableau croisé dynamique.

Un tableau croisé dynamique dans un tableur est un outil d'analyse de données qui vous permet de créer une vue synthétique et facile à lire d'une grande quantité de données ( ici nos exécutions de checks ). On y choisit les données à inclure, comment les organiser et comment les synthétiser, filtrer, classer et totaliser les données en fonction de nos besoins.

Afin de pouvoir faire une analyse complète, notre objectif sera ici d'obtenir:

• la consommation CPU totale par check,
• la répartition de la consommation CPU par check,
• et enfin la consommation CPU moyenne pour une exécution pour chaque check

Création du tableau croisé dynamique

La création du tableau récapitulatif passe par la création d'un Tableau croisé dynamique. Depuis votre Feuille d'importation des données, il faut cliquer sur Insertion→ Tableau croisé dynamique, et valider:

Sélection des commandes en tant que lignes de notre tableau

Arrivé sur la nouvelle feuille, Excel demande quelles lignes sélectionner, dans le bloc de droite nommé "Champs de tableau croisé dynamique".

Dans notre cas, il faut faire glisser le champ command_name ( ou bien command_name_anonymous_hash si on a une version anonyme de l'export ) vers le bloc "Lignes":

Ceci permet de définir nos lignes dans la colonne A avec l'ensemble de nos commandes.

Obtenir la consommation CPU totale par check

A chaque commande, il faut lui assigner une ( ou plusieurs ) "Valeurs". Pour cela, on fait glisser le champ "cpu_time" vers le bloc "Valeurs" afin d'avoir pour chaque royaume son champs cpu_time associé:

A noter que, par défaut, Excel prends le nombre d’occurrences du champ cpu_time comme "Valeur", ce qui n'est pas ce qui est souhaité ( "Nombre de cpu_time" ).

Passer du nombres de lignes avec "cpu_time" à une vraie somme des temps CPU

Une modification des "Paramètres des champs de valeurs" est nécessaire sur "Nombre de cpu_time" qu'il faut changer en Somme pour donner au final "Somme de cpu_time":

On obtient alors la somme en temps ( secondes ) consommée par chaque commande.

Rendre le titre de la colonne explicite

Le titre de la colonne n'étant pas des plus lisible pour notre analyse, on le changer en double cliquant dessus. On le renomme alors "Consommation CPU totale par check (en s)":

Notre première valeur est obtenue.

Obtenir la répartition de la consommation CPU par check

S'il est possible de trier par rapport au temps absolu consommé par un check et donc avoir les plus consommateurs, il peut être également très intéressant d'avoir leur pourcentage par rapport à la consommation totale.

Ceci en facilitera grandement la lecture, et il sera ainsi possible de savoir de quel ordre de grandeur une optimisation sera bénéfique pour la consommation.

Il faut rajouter une seconde fois le champ "cpu_time" dans les valeurs, ce qui rajoute une nouvelle colonne:

Passer la seconde colonne en somme de temps, comme la première

Passer du nombre total de temps CPU consommé à la répartition de la consommation CPU par check

Le changement dans cette étape consiste à changer l'affichage dans le menu "Afficher les valeurs" en choisissant "% du total général" pour obtenir la Répartition de la consommation CPU par check:

Rendre le titre de la colonne explicite

Comme précédemment, on change le titre par défaut en double cliquant dessus. On le renomme alors "Consommation CPU totale par check (en s)":

Ces deux premières colonnes nous permettent de trier rapidement les checks les plus consommateurs.

La suivante, et dernière, va nous permettre d'affiner l'analyse en calculant le temps moyen de CPU par exécution de check.

Obtenir la répartition de la consommation CPU moyenne pour une exécution (en s)

La dernière statistique qui va nous intéresser pour prioriser nos actions d'optimisation va être d'obtenir la consommation CPU moyenne pour une exécution de check.

Pour cela, il faut rajouter une dernière fois le champ "cpu_time" dans les valeurs, exactement comme pour les deux précédentes colonnes:

Passer du nombre total de temps CPU consommé à la consommation CPU moyenne pour une exécution de check

Pour cette colonne, il faut changer le calcul de Nombre à un calcul en "Moyenne de cpu_time":

Rendre le titre de la colonne explicite

Comme pour les deux colonnes précédentes, on change le titre de la colonne en change en double cliquant dessus. On le renomme alors "Consommation CPU moyenne pour une exécution (en s)":

Analyse des résultats

On obtient alors le tableau final que l'on peut analyser afin d'identifier de la manière la plus efficace possible la ou les checks les plus consommateurs. Il est ainsi possible de se concentrer sur l'optimisation des checks qui auront un véritable impact sur les performances de la plateforme.

Analyse du cas présenté: quel check doit être optimisé en priorité pour économiser du CPU?

Quel check est le plus consommateur?

Faisons l’exercice avec notre exemple. Nous avons 3 checks ( leur temps d’exécution est extrait de la colonne "Consommation CPU moyenne pour une exécution (en s)" ):

• check-host-alive:
  • check par défaut pour la vérification des hôtes, seulement 0.006s ( 6ms ) de temps moyen d’exécution, très peu couteux car il lance principalement un simple ping
• dump-check-example-1:
  • check d'exemple qui consomme en moyenne 5s de temps CPU par exécution, ce qui est très élevé pour un check
• dump-check-exemple-2:
  • second check d'exemple qui consomme 0.2s ( 200ms ) de temps CPU par exécution, ce qui est légèrement élevé pour un check

En ne regardant que cette statistique, et en ne se basant que sur notre intuition, on serait tenté de se dire que le check le plus consommateur est dump-check-example-1 avec ses 5s de temps d’exécution par check. C'est en effet un temps anormal pour un check de supervision.

Mais si on regarde mieux notre tableau on s’aperçoit que ce check ne représente qu'environ 25% du temps CPU total consommé ( 23,91%, colonne "Répartition de la consommation CPU par check" ). Il n'est ainsi pas le plus consommateur/prioritaire.

Contrairement à notre première intuition, le check le plus consommateur est dump-check-example-2, avec ses plus de 75% de temps CPU total consommé ( 75,93% ). Il est donc intéressant de voir les gains que l'on peut faire sur ce dernier, surtout qu'avec ses 200ms de temps d’exécution, il n'est pas léger, et donc des optimisations doivent être possibles.

Quel check optimiser afin de limiter la consommation CPU à un seul CPU?

Dans notre cas, nous avions pris un temps de 3600s=1h pour notre récupération d’ordonnancement. La somme totale des temps d'exécutions de toutes les checks est de 5445s, soit moins de 2h de temps de calcul ( 7200s ).

L'ensemble des checks consomment ainsi actuellement moins de 2 CPUs ( 5445/3600=1.5 CPUs ).

Si l'on souhaite ne consommer qu'un seul CPU sur cette plateforme, il faut ainsi gagner 5445-3600=1845s de temps de traitement:

• si on se limite à optimiser le check dump-check-example-1, l'objectif de se limiter à 1CPU est impossible, car il ne consomme au total que 1300s ( 1302 ), ce qui est moins que le gain nécessaire de 1845s,
• si on se concentre sur le check dump-check-example-2, le plus consommateur, ceci demande une optimisation de 1845/4135=45% de son temps d’exécution, et ainsi passer sous les 110ms de temps d’exécution moyen.