L'integrità dell'istanza di Splunk è visualizzata in ROSSO per il componente Bucket

Applicabilità

Splunk Enterprise

Descrizione

La percentuale di bucket di piccole dimensioni creati (100) nell'ultima ora è molto alta e supera le soglie rosse (50) per index=<nome indice>, ed eventualmente altri indici, su questo indicizzatore.

Messaggi di errore nella scheda Controllo stato:

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 

Ultimi 50 messaggi correlati: 

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

 

Indagine

Il messaggio sopra riportato indica che il 100% dei bucket creati nelle ultime 24 ore è inferiore al 10% di maxDataSize. In questo modo non si verificheranno problemi di prestazioni. Per correggere questo avviso, è possibile aumentare la soglia da 50 a 150 come indicato di seguito.

La configurazione predefinita è nel percorso $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

 

Inoltre, lo stesso messaggio di avvertenza sullo stato di salute viene visualizzato quando il numero di hot bucket creati per indicizzare i dati in un particolare giorno/ora supera o raggiunge il limite di soglia definito in system/health.conf.
 

La ragione dietro la creazione di troppi hot bucket
 

Splunk utilizza i bucket come directory di indice per indicizzare i dati. Quando un evento viene inviato a Splunk per l'indicizzazione, il nuovo hot bucket viene creato per tale evento oppure l'evento viene indicizzato in uno degli hot bucket esistenti in base al timestamp dell'evento e ai vincoli dell'indice.

Fare riferimento ai parametri maxHotBucket, maxHotSpanSecs e quarantinePastSecs di indexes.conf
 

Pertanto, se l'evento presenta un timestamp precedente/strano che non è accettabile per i bucket esistenti, Splunk creerà un nuovo hot bucket per indicizzare l'evento. Quindi, il numero di hot bucket creati può raggiungere o superare la soglia.
 

Quando il parametro DATETIME_CONFIG del file props.conf non è impostato in modo esplicito, Splunk tenterà di trovare il timestamp in un evento.


Pertanto, durante l'estrazione del timestamp dagli eventi, se Splunk trova il valore che corrisponde al formato di timestamp valido, analizzerà lo stesso valore dell'ora dell'evento e lo indicizzerà utilizzando solo tale timestamp, il che potrebbe causare la creazione di un nuovo hot bucket da parte di Splunk poiché il timestamp non viene estratto correttamente.

Prendere in considerazione l'aggiunta di attributi timestamp in props.conf per rendere corretto il timestamp di estrazione Splunk. Configurare il riconoscimento timestamp
 

Numero timbro:

Inoltre, ho trovato i messaggi seguenti nel splunkd.log relativi al timestamp correggerli anche applicando le impostazioni corrette dipende dal formato del log.
 

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

 

Risoluzione

1. Passare a $SPLUNK_HOME/etc/system/local/health.conf e aggiungere la stanza seguente
 

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

2. Riavviare lo Splunk per rendere effettive le modifiche.

Se si tratta di un problema di timestamp o DATETIME_CONFIG, scrivere un regex appropriato per identificare correttamente la data e l'ora dell'evento e correggere il problema.

Collegamenti correlati

Documentazione relativa a Splunk
Configura riconoscimento timestamp 


Risposte Splunk
Stato integrità: Percentuale di bucket di piccole dimensioni creati 

Cronologia delle revisioni

Revisione	Data di pubblicazione	Commenti
1.0	28-Sep-2026	Versione iniziale