L'état de l'instance de splunk indique ROUGE pour le composant Bucket

Applicabilité

Splunk Enterprise

Description

Le pourcentage de petits groupes créés (100) au cours de la dernière heure est très élevé et a dépassé les seuils rouges (50) pour index=<nom index>, et éventuellement plus d'index, sur cet indexeur.

Messages d'ERREUR dans l'onglet Contrôle d'intégrité :

Buckets 
Root Cause(s): 
The percentage of small of buckets created (100) over the last hour is very high and exceeded the red thresholds (50) for index=mbam, and possibly more indexes, on this indexer 

50 derniers messages associés : 

07-02-2019 02:16:05.989 -0700 INFO HotBucketRoller - finished moving hot to warm bid=_internal~4984~99D2CFA5-1005-45DA-8C68-0E8A5FB0C95C idx=_internal 
from=hot_v1_4984 to=db_1562087584_1562043339_4984 size=1048645632 caller=size_exceeded _maxHotBucketSize=1048576000 (1000MB), bucketSize=1048641536 (1000MB) 
07-02-2019 00:22:57.931 -0700 INFO HotBucketRoller - finished moving hot to warm bid=_introspection~2046~99D2CFA5-1005-45DA-8C68-0E8A5FB0C95C idx=_introspection 
from=hot_v1_2046 to=db_1562027109_1562015374_2046 size=569110528 caller=lru maxHotBuckets=3, count=4 hot buckets,evicting_count=1 LRU hots 
07-02-2019 00:00:22.067 -0700 INFO HotBucketRoller - finished moving hot to warm bid=cloudflare~324~99D2CFA5-1005-45DA-8C68-0E8A5FB0C95C idx=cloudflare 
from=hot_v1_324 to=db_1561885206_1561791602_324 size=394207232 caller=lru maxHotBuckets=3, count=4 hot buckets,evicting_count=1 LRU hots 
07-01-2019 23:03:37.981 -0700 INFO HotBucketRoller - finished moving hot to warm bid=_internal~4983~99D2CFA5-1005-45DA-8C68-0E8A5FB0C95C idx=_internal 
from=hot_v1_4983 to=db_1562076172_1562032683_4983 size=1054523392 caller=size_exceeded _maxHotBucketSize=1048576000 (1000MB), bucketSize=1054404608 (1005MB) 
07-01-2019 22:43:06.030 -0700 INFO HotBucketRoller - finished moving hot to warm bid=clearpass~362~99D2CFA5-1005-45DA-8C68-0E8A5FB0C95C idx=clearpass 
from=hot_v1_362 to=db_1561787045_1561538116_362 size=393191424 caller=lru maxHotBuckets=3, count=4 hot buckets,evicting_count=1 LRU hots

 

Enquête

Le message ci-dessus indique que 100 % des compartiments créés au cours des dernières 24 heures sont inférieurs à 10 % de maxDataSize. Cela n'entraînera aucun problème de performances. Pour corriger cet avertissement, vous pouvez augmenter le seuil de 50 à 150 comme ci-dessous.

La configuration par défaut se trouve à l'emplacement $SPLUNK_HOME/etc/system/default/health.conf

[feature:buckets]
display_name = Buckets
indicator:percent_small_buckets_created_last_24h:description = "This indicator tracks the percentage of small buckets created over the last 24 hours. 
small bucket is defined as less than 10 % of the ‘maxDataSize’ setting in indexes.conf."
indicator:percent_small_buckets_created_last_24h:red = 50
indicator:percent_small_buckets_created_last_24h:yellow = 30

 

Le même message d'avertissement d'intégrité ci-dessus est également affiché lorsque le nombre de compartiments à chaud créés pour indexer les données dans une heure/jour particulière dépasse ou atteint la limite de seuil définie dans system/health.conf.
 

La raison derrière la création d'un trop grand nombre de hot buckets
 

Splunk utilise des buckets comme répertoire d'index pour indexer les données. Maintenant, lorsqu'un événement arrive sur Splunk pour indexation, le nouveau compartiment d'accès à chaud est créé pour cet événement ou l'événement est indexé sur le compartiment existant parmi les compartiments d'accès à chaud selon l'horodatage de l'événement et les contraintes sur l'index.

Référez-vous aux paramètres maxHotBuckets, maxHotSpanSecs et quarantinePastSecs de indexes.conf
 

Ainsi, si l'événement a l'horodatage plus ancien/étrange que acceptable pour les compartiments existants, alors Splunk créera un nouveau compartiment à chaud pour indexer cet événement. Par conséquent, le nombre de compartiments à chaud créés peut atteindre ou dépasser le seuil.
 

Quand le paramètre DATETIME_CONFIG de props.conf n'est pas défini explicitement, Splunk essaiera de trouver l'horodatage dans un événement lui-même.


Ainsi, lors de l'extraction de l'horodatage à partir des événements, si Splunk trouve la valeur qui correspond au format d'horodatage valide, il analysera la même valeur que l'heure de l'événement et l'indexera en utilisant uniquement cet horodatage, ce qui peut amener Splunk à créer un nouveau hot bucket car l'horodatage n'est pas correctement extrait.

Envisagez d'ajouter des attributs d'horodatage dans props.conf pour que Splunk extrait correctement l'horodatage. Configurez la reconnaissance d'horodatage
 

Problème d'horodatage :

En outre, j'ai trouvé les messages ci-dessous dans le splunkd.log concernant l'horodatage aussi les corriger en appliquant les paramètres corrects dépend du format du journal.
 

06-02-2019 22:37:36.976 -0700 WARN DateParserVerbose - Failed to parse timestamp in first MAX_TIMESTAMP_LOOKAHEAD (30) characters of event. 
Defaulting to timestamp of previous event (Mon Jun 3 02:37:35 2019). Context: source=/data/syslogng/asa/richmond-vpn-inside/20190603.log|host=richmond-vpn-inside
|cisco:asa|48952806-21-2019 09:48:48.467 -0700 WARN DateParserVerbose - Failed to parse timestamp in first MAX_TIMESTAMP_LOOKAHEAD (44) characters of event. 
Defaulting to timestamp of previous event (Fri Jun 21 06:48:45 2019). Context: source=/data/syslogng/pan/vcadcl-fw-mgmt/20190621.log|host=vcadcl-fw-mgmt|pan_log|86736606-20-2019 11:29:10.742 -0700 WARN DateParserVerbose - Failed to parse timestamp in first MAX_TIMESTAMP_LOOKAHEAD (128) characters of event. 
Defaulting to timestamp of previous event (Thu Jun 20 11:29:10 2019). Context: source=/scratch/data/syslogng/vlsj-securelog/sj-anliu1/20190620.log|host=sj-anliu1
|linux_secure|526909106-14-2019 12:46:38.301 -0700 WARN DateParserVerbose - Accepted time format has changed ((?i)\s([01]\d)([0123]\d\d)\s), possibly indicating a problem 
in extracting timestamps. Context: source=C:\Windows\debug\netlogon.log|host=DC2SJGLOBAL|MSAD:NT6:Netlogon|4001606-02-2019 16:17:18.106 -0700 WARN DateParserVerbose - Accepted time format has changed ((?i)(?<!\w|\d[:\.\-])(?i)(?<![\d\w])(jan|\x{3127}\x{6708}|feb|\x{4E8C}\x{6708}
|mar|\x{4E09}\x{6708}|apr|\x{56DB}\x{6708}|may|\x{4E94}\x{6708}|jun|\x{516D}\x{6708}|jul|\x{4E03}\x{6708}|aug|\x{516B}\x{6708}|sep|\x{4E5D}\x{6708}|oct|\x{5341}\x{6708}
|nov|\x{5341}\x{3127}\x{6708}|dec|\x{5341}\x{4E8C}\x{6708})[a-z,\.;]*([/\- ]) {0,2}(?i)(0?[1-9]|[12]\d|3[01])(?!:) {0,2}(?:\d\d:\d\d:\d\d(?:[\.\,]\d+)? {0,2}(?i)((?:(?:
UT|UTC|GMT(?![+-])|CET|CEST|CETDST|MET|MEST|METDST|MEZ|MESZ|EET|EEST|EETDST|WET|WEST|WETDST|MSK|MSD|IST|JST|KST|HKT|AST|ADT|EST|EDT|CST|CDT|MST|MDT|PST|PDT|CAST|CADT|EAST
|EADT|WAST|WADT|Z)|(?:GMT)?[+-]\d\d?:?(?:\d\d)?)(?!\w))?)?((?:\2|,) {0,2}(?i)(20\d\d|19\d\d|[901]\d(?!\d)))?(?!/|\w|\.\d)), possibly indicating a problem 
in extracting timestamps. Context: source=C:\Windows\System32\DHCP\DhcpSrvLog-Mon.log|host=srv07-seoul|DhcpSrvLog|286986

 

Résolution

1. Accédez à $SPLUNK_HOME/etc/system/local/health.conf et ajoutez la strophe ci-dessous
 

[feature:buckets]
indicator:percent_small_buckets_created_last_24h:red = 150

2. Redémarrez le Splunk pour que les modifications prennent effet.

S'il s'agit d'un problème d'horodatage ou de DATETIME_CONFIG, écrivez une expression régulière appropriée pour identifier correctement la date et l'heure de l'événement et rectifier le problème.

Liens connexes

Documentation Splunk
Configurer la reconnaissance des horodatages 


Réponses Splunk
État de santé : Pourcentage de petites quantités de compartiments créées 

Historique de révision

Révision	Date de publication	Commentaires
1.0	28-Sep-2026	Première publication