Dépannage du partionnement Centreon
02/11/19 22:55 Classé dans: Techniques
Il y a quelques jours, une de mes machines virtuelles utilisées pour mes maquettes Centreon provoquait des alertes de CPU et Load à tout va sans que je trouve la cause. Au début, j'ai pensé à une mise à jour Centreon que je n'avais pas fait (c'est une version 18.10). La mise à jour réalisée, les alertes disparaissaient, je pensais avoir trouvé.
Malheureusement, le lendemain, patatras ! De nouveaux des alertes de cpu et de charge processeur ! Bon, il faut reconnaître que la machine me sert qu'à des fins de tests et que je ne m'en occupe pas tous les jours. Cette machine Après quelques recherches sur l'IHM de Centreon, je découvre le graphe suivant.
Je constate que le cpu s'affole à 2 H 00 du matin correspondant au cron de purge des logs et data-bin de la base centreon_storage. Le constat est sans appel, il s'agit d'un problème de base de données et plus précisément du partitionnement. La copie d'écran ci-dessous me confirme mon raisonnement.
Les partitions de la table logs ont une date périmée (1987), il devrait avoir des partitions avec une date plus récente avec 10 jours d'avance sur la date du jour. Bilan : les tables logs, log_archive_host et log_archive_service ne sont pas à jour en termes de partitionnement.
Pour corriger ce dysfonctionnement, une solution : refaire le partitionnement des tables incriminées. Mais attention, pour réaliser cette opération, assurez-vous d'avoir suffisamment d'espace disque pour MySQL ou MariaDB. En effet il faut un espace libre équivalent à deux fois et demie de la table existante.
Voici la procédure à appliquer pour chaque table, nous prenons pour exemple la table logs :
Supprimez les partitions de la table logs, attention cela peut prendre du temps surtout avec des tables importantes.
exemple du résultat de la fin d'un partitionnement
MariaDB a enlevé les partitions de la table logs.
Maintenant, il faut refaire le partitionnement de cette table, nous allons reprendre le script suivant suivant la distribution.
Debian et Ubuntu
CentOS 7
vous devriez avoir ce résultat
Ensuite, supprimez la table logs_old créé lors du partionnement de la table logs.
Répétez ces opérations pour les tables impactées. Point d'attention, l'espace utilisé pour supprimer les anciennes partitions ne sera pas récupéré.
Et ma supervision Centreon est repartie de plus belle
Malheureusement, le lendemain, patatras ! De nouveaux des alertes de cpu et de charge processeur ! Bon, il faut reconnaître que la machine me sert qu'à des fins de tests et que je ne m'en occupe pas tous les jours. Cette machine Après quelques recherches sur l'IHM de Centreon, je découvre le graphe suivant.
Je constate que le cpu s'affole à 2 H 00 du matin correspondant au cron de purge des logs et data-bin de la base centreon_storage. Le constat est sans appel, il s'agit d'un problème de base de données et plus précisément du partitionnement. La copie d'écran ci-dessous me confirme mon raisonnement.
Les partitions de la table logs ont une date périmée (1987), il devrait avoir des partitions avec une date plus récente avec 10 jours d'avance sur la date du jour. Bilan : les tables logs, log_archive_host et log_archive_service ne sont pas à jour en termes de partitionnement.
Pour corriger ce dysfonctionnement, une solution : refaire le partitionnement des tables incriminées. Mais attention, pour réaliser cette opération, assurez-vous d'avoir suffisamment d'espace disque pour MySQL ou MariaDB. En effet il faut un espace libre équivalent à deux fois et demie de la table existante.
Voici la procédure à appliquer pour chaque table, nous prenons pour exemple la table logs :
Supprimez les partitions de la table logs, attention cela peut prendre du temps surtout avec des tables importantes.
mysql -u centreon -p centreon_storage
MariaDB [centreon_storage]> ALTER TABLE logs REMOVE PARTITIONING;
exemple du résultat de la fin d'un partitionnement
Query OK, 832 rows affected (48 min 21.14 sec)
Records: 832 Duplicates: 0 Warnings: 0
MariaDB a enlevé les partitions de la table logs.
Maintenant, il faut refaire le partitionnement de cette table, nous allons reprendre le script suivant suivant la distribution.
Debian et Ubuntu
/usr/bin/php /usr/share/centreon/bin/centreon-partitioning.php -m logs
CentOS 7
/opt/rh/rh-php72/root/usr/bin/php /usr/share/centreon/bin/centreon-partitioning.php -m logs
vous devriez avoir ce résultat
[Sat, 20 Feb 21 09:42:39 +0100] PARTITIONING STARTED
[Sat, 20 Feb 21 09:42:39 +0100][migrate] Renaming table centreon_storage.logs TO centreon_storage.logs_old
[Sat, 20 Feb 21 09:42:39 +0100][migrate] Creating parts for new table centreon_storage.logs
[Sat, 20 Feb 21 09:47:37 +0100][migrate] Insert data from centreon_storage.logs_old to new table
[Sat, 20 Feb 21 09:47:38 +0100] PARTITIONING COMPLETED
Ensuite, supprimez la table logs_old créé lors du partionnement de la table logs.
mysql -u centreon -p centreon_storage
MariaDB [centreon_storage]> drop table logs_old;
Répétez ces opérations pour les tables impactées. Point d'attention, l'espace utilisé pour supprimer les anciennes partitions ne sera pas récupéré.
Et ma supervision Centreon est repartie de plus belle
blog comments powered by Disqus