Nettoyage des tables de logs dans GLPI
20 juillet 2018
GLPI est verbeux et c’est tant mieux.
Les logs d’activité de ce logiciel Open Source de ticketing, de helpdesk et d’inventaire de parc sont stockés dans deux tables :
- glpi_crontasklogs,
- glpi_logs.
Il n’y a aucun risque particulier à supprimer le contenu de ces tables. Je pense qu’il est raisonnable d’en conserver les données des trois dernières semaines, à des fins de traçage et d’analyse post-mortem.
Par défaut, GLPI comprend deux actions automatiques afin de nettoyer par une tâche planifiée ces deux fichiers, que vous pouvez paramétrer à partir du menu Configuration > Actions automatiques :
- cleantaskjob,
- logs.
Configuration de l’action automatique cleantaskjob
Cette tâche est activée par défaut. Vous pouvez en régler la fréquence d’exécution pour la régler sur une durée d’une vingtaine de jours.
Configuration de l’action automatique logs
Très curieusement, cette tâche n’est pas activée par défaut. Il y a donc lieu de la planifier afin qu’elle soit exécutée quotidiennement.
La réindexation des tables
A coup de migrations successives et de reprises de base existante, il peut arriver que le vidage de l’une de ces tables ne se réalise plus du fait d’une erreur sur les index. Il y a donc lieu de procéder à la réindexation des tables.
Dans l’exemple ci-dessous, la procédure stockée maintenance est créée dans la base de données glpi. Elle permet de réindexer toutes les tables de l’ensemble des bases MySQL/MariaDB à l’exception de mysql, information_schema, performance_schema.
USE glpi;
DROP PROCEDURE IF EXISTS maintenance;
DELIMITER $$
CREATE PROCEDURE maintenance()
BEGIN
DECLARE done INT DEFAULT FALSE;
DECLARE val_table VARCHAR(255);
DECLARE val_schema VARCHAR(255);
DECLARE val_engine VARCHAR(255);
DECLARE val_sql VARCHAR(255);
DECLARE cur_tables CURSOR FOR
SELECT table_schema, table_name, engine
FROM information_schema.tables
WHERE
table_schema NOT IN ('mysql','information_schema','performance_schema')
and
engine IN ('MyISAM','InnoDB');
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
OPEN cur_tables;
boucle: LOOP
FETCH cur_tables INTO val_schema,val_table,val_engine;
IF done THEN
LEAVE boucle;
END IF;
SET @a=val_schema;
SET @b=val_table;
SET @c=val_engine;
IF @c='MyISAM' THEN
SET @s=CONCAT('REPAIR TABLE `',@a,'`.`',@b,'`');
ELSEIF @c='InnoDB' THEN
SET @s=CONCAT('ALTER TABLE `',@a,'`.`',@b,'` ENGINE=InnoDB');
END IF;
PREPARE stmt FROM @s;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
SET @s=CONCAT('OPTIMIZE TABLE `',@a,'`.`',@b,'`');
PREPARE stmt FROM @s;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
END LOOP;
CLOSE cur_tables;
END $$
DELIMITER ;
Pour exécuter la procédure maintenance, vous pouvez le faire en SQL, après vous être connecté à votre base de données à l’aide de l’utilisateur root de MySQL :
CALL glpi.maintenance;
Vous pouvez aussi le faire en ligne de commandes :
mysql -u root --password='votre_mot_de_passe_root_mysql' -e "CALL glpi.maintenance;"
Nettoyage des tables glpi_logs et glpi_crontasklogs en SQL
Dès lors, le nettoyage de vos tables glpi_logs et glpi_crontasklogs peut se faire aisément en SQL. Dans l’exemple ci-dessous, je nettoie du contenu de ces deux tables les données vieilles de plus de 21 jours :
USE glpi; DELETE FROM glpi_crontasklogs WHERE date < NOW()-INTERVAL 21 DAY; DELETE FROM glpi_logs WHERE date_mod < NOW()-INTERVAL 21 DAY;