Versions Compared

Old Version 2

changes.mady.by.user Jroy

Saved on

compared with

New Version Current

changes.mady.by.user Soubrié Grégoire

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Make by tools (01.00.01) - action=clean_macro_parameter
Scroll Ignore
scroll-html
scroll-viewporttrue
scroll-pdftrue
scroll-officetrue
scroll-chmtrue
scroll-htmlfalse
scroll-docbooktrue
scroll-eclipsehelptrue
scroll-epubtruefalse
Panel
titleSommaire

Table of Contents
stylenone

Concept

Les données SLA et celles du bac à événements sont conservées pendant plusieurs jours :

  • Par défaut :
    • indéfiniment pour les données SLA,
    • et durant 30 jours pour celles du bac à événements.
  • Ces données représentent ainsi l’essentiel du volume des données en base.
  • Limiter leur durée de conservation permet ainsi de réduire l'espace disque utilisé.

Les SLAs

Le module SLA à la capacité de supprimer quotidiennement les entrées SLAs dépassant un certains nombres certain nombre de jours.

  • Par défaut, cette suppression quotidienne n'est pas
activé
  • activée.

Si le module est configuré avec une valeur trop faible, cela pourrait supprimer de nombreuses entrées et causer un problème de performance.

Limiter le nombre de jours où une archive SLA est conservée en base

Il est

donc possible d'utiliser un script afin de nettoyer les anciennes entrées en limitant l'impact sur les performances

Paramètre du module SLA ⇒ ne garde que X jours en base

possible de configurer le module sla afin de ne conserver les données SLA que pour un nombre limité de jours ( voir la page Module SLA ).

  • Le paramètre nb_stored_days permet de définir le nombre de jours où les données SLA seront gardées en base.
    • Par défaut, toutes les données sont conservées indéfiniment.
    • Après modification de la valeur nb_stored_days, il faudra attendre le nettoyage des données qui a lieu par défaut à 03h02 du matin ( voir le paramètre
Les paramètres nb_stored_days et
    • time_when_delete_old_SLA
qui vous permettront respectivement de définir le
    • ).
    • Le nombre de jours à conserver
et l'heure à laquelle effectuer le nettoyage. Ils sont détaillés dans la page dédié à la configuration du module ( voir Module SLA ).

Exemple:

  • Si le nombre de jours stocké est par exemple de 500 et que vous redémarrer l'Arbiter après avoir réglé le paramètre nb_stored_days à 365 ( pour ne garder qu'un an d'historique ), le module essayera de supprimer les 135 jours de trop au redémarrage.
  • Pour supprimer ces 135 jours d'enregistrement, le module exécute des suppressions par bloc et fait une pause entre deux itérations afin de laisser le temps au module d'enregistrer les nouvelles données et à la base Mongo de pouvoir répondre à d'autres requêtes.
Warning

Selon votre volume déjà en base et le volume des nouvelles données à absorber, cela peut causer des problèmes de performance.

Contacter votre support dédié afin de choisir le meilleur paramétrage possible pour votre installation à l'aide des paramètres daily_clean_batch_size et daily_clean_pause_time décrits ci-dessous.

ParamètreDescriptionValeur par défautdaily_clean_batch_size

Nombre d'enregistrements à supprimer dans une itération
Pour réduire l'impact sur votre supervision, vous pouvez diminuer ce nombre

10000

daily_clean_pause_timeNombre de secondes d'attente entre deux itérations
Pour réduire l'impact sur votre supervision, vous pouvez augmenter ce nombre

2

Utiliser le script shinken-sla-delete-until

Ce script vous permettra d'avoir le même comportement de nettoyage des SLAs qu'en utilisant le paramètre nb_stored_days du module SLA.

Le fonctionnement du script est décrit dans la page suivant : shinken-sla-delete-until - Suppression manuelle des archives SLA par jour

Tip

Si vous réduisez le nombre de jours stockés en utilisant le script, changez le paramètre nb_stored_days du module sla, par défaut dans /etc/shinken/modules/sla.cfg

  • Cela évitera que de nouveaux jours inutiles soit garder en base.
  • Référez-vous à la page de configuration du module SLA pour plus de d'information ( voir Module SLA ).
  • Note : Il n'est nécessaire de redémarrer Shinken maintenant, ce sera fait plus tard dans la procédure.

Le Bac à Événements

Le bac à événements conserve par défaut seulement les 30 derniers jours. Il est possible de modifier ce paramétrage directement dans le module.

    • actuellement configurer est disponible avec le check du Module SLA Writer ( voir la page Broker - $KEY$ - Module SLA Writer ).
    • La suppression des données excédentaires n'a pas d'impact sur les performances de la base ni du traitement des SLA, il est donc possible de changer le paramètre et de supprimer n'import quelles quantités de jour SLA ( il s'agit d'une simple surpression de collection MongoDB ).

Exemple :

  • Si, par exemple, le nombre de jours stockés est de 500 et après avoir mis à jour le paramètre nb_stored_days à 365 ( pour ne conserver qu'un an d'historique ) et redémarrez l'Arbiter, le module supprimera automatiquement les 135 jours les plus anciens lors du nettoyage des données.


Le Bac à Événements

Par défaut, le bac à événements conserve uniquement les évènements sur les 30 derniers jours.

Toutefois, il est possible de modifier ce paramétrage dans la configuration du module.

Limiter le nombre de jours où un évènement est conservé en base

Paramètres du module event-manager-writer ⇒ configuration de la rétention

Il est possible de configurer le module event-manager-writer pour afin de ne conserver les données qu'un certain nombre de jours.

Le paramétrage s'effectue dans le

évènements que pour un nombre limité de jours ( voir la page  Module event-manager-writer ).

  • Le paramètre day_keep_data permet de définir le nombre de jours ou les données seront conservésoù un événement sera gardé en base.
    • La durée par défaut est de 30 jours.
    • Après modification, si la valeur de day_keep_data  est réduite, les collections correspondant aux jours hors de cette nouvelle limite seront automatiquement supprimées.
    • Le nombre de jours à conserver actuellement configurer est disponible avec le check du Module Event Manager Writer ( voir la page Broker - $KEY$ - Module Event Manager Writer ).