| Scroll Ignore | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||
|
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 est développé pour à 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é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 performancesParamè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
Les paramètres nb_stored_days et time_when_delete_old_SLA qui vous permettront respectivement de définir le nombre de jours à conserver et l'heure à laquelle effectuer le nettoyage sont détaillés dans la configuration du Module SLA.
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
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.
Selon votre volume déjà en base et le volume des nouvelles données à absorber, cela peut causer des problèmes de performance. Vous avez alors deux possibilités :
- 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.
- Utiliser le script qui permet de supprimer les anciennes entrées.
| Warning |
|---|
Les paramètres daily_clean_batch_size et daily_clean_pause_time peuvent fortement impacté les performances de votre installation. Ne les utilisez pas sans avoir contacté votre support dédié. |
10000
Script de suppression des anciennes entrées ⇒ ne garde que X jours en base
Le script shinken-sla-delete-until de suppression vous permet :
- de nettoyer votre base sans toucher à la configuration de votre module SLA
- de constater le nombre d'enregistrements à supprimer pour atteindre la rétention souhaitée
- de suivre facilement la progression de la suppression des anciennes données
- Pouvoir arrêter la suppression si cela impacte trop les performances, sans avoir à arrêter
- Pouvoir à un ou plusieurs moments
Une fois ces actions réalisées, il est intéressant de configurer le module SLA pour supprimer les anciennes entrées quotidiennement et gérer le volume de données ( paragraphe précédent ).
- 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 time_when_delete_old_SLA ).
- Le nombre de jours à conserver 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
| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
Date limite de conservation des données SLA.
Toutes les données avant cette date seront supprimée
Le format est JJ-MM-AAAA
Ne peut pas être utilisé avec l'option --nb-day
Nombre de jours sui seront conservés
Ne peut pas être utilisé avec l'option --date
Nombre maximum d'enregistrements qui seront supprimé durant une itération du script.
Le script continuera ses itérations jusqu'a suppression complète des données avant le nombre de jours ou la date indiqué en option.
Force la suppression sans demander confirmation.
A chaque éxécution, le script vous indiquera
Utilisation de l'index de mongo en premier plan.
Cette option va bloquer Mongo durant le temps d'indexation mais les opérations seront beaucoup plus rapide
| Info |
|---|
Le script peut être utilisé avec une date ( option --date ) ou un nombre de jours à conserver ( option --nb-day ) mais il n'est pas possible d'utiliser ces deux options conjointement. |
| Warning |
|---|
Les options --size-batch et --pause-batch peuvent fortement impacté les performances de votre installation. Ne les utilisez pas sans avoir contacté votre support dédié. |
| Warning |
|---|
L'option --foreground bloque toute l'installation Mongo. Si cette option est utilisée :
|
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.
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
- où 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 ).