Der Status der Splunk-Instanz zeigt ROT für die Bucket-Komponente an.

Geltungsbereich

Splunk Enterprise

Beschreibung

Der Prozentsatz kleiner erstellter Buckets (100) in der letzten Stunde ist sehr hoch und hat die roten Schwellenwerte (50) für index=<Indexname> und möglicherweise weitere Indizes auf diesem Indexer überschritten.

FEHLER-Meldungen auf der Registerkarte "Integritätsprüfung":

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 

Letzte 50 verwandte Nachrichten: 

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

 

Untersuchung

Die obige Meldung besagt, dass 100% der für die letzten 24 Stunden erstellten Buckets weniger als 10% von maxDataSize sind. Dies führt zu keinen Leistungsproblemen. Um diese Warnung zu beheben, können Sie den Schwellenwert wie unten beschrieben von 50 auf 150 erhöhen.

Die Standardkonfiguration befindet sich im Verzeichnis $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

 

Ebenfalls aus der obigen Gesundheitswarnmeldung wird angezeigt, wenn die Anzahl der zur Indizierung der Daten erstellten Hot-Buckets pro Stunde und Tag den in system/health.conf definierten Grenzwert überschreitet oder erreicht.
 

Der Grund für die Schaffung zu vieler heißer Eimer
 

Splunk verwendet Buckets als Indexverzeichnis, um die Daten zu indizieren. Wenn jetzt ein Ereignis zur Indizierung an Splunk gesendet wird, wird die neue Hot Bucket für dieses Ereignis erstellt, oder das Ereignis wird entsprechend dem Zeitstempel und den Einschränkungen für das Ereignis für den Index an die vorhandene Hot Bucket indiziert.

Weitere Informationen finden Sie unter den Parametern maxHotBuckets, maxHotSpanSecs und quarantinePastSecs von indexes.conf.
 

Wenn das Ereignis also den älteren/seltsamen Zeitstempel hat, der für die vorhandenen Buckets nicht akzeptabel ist, erstellt Splunk einen neuen Hot Bucket, um dieses Ereignis zu indizieren. Daher kann die Anzahl der erstellten Hot Buckets den Schwellenwert erreichen oder überschreiten.
 

Wenn der Parameter DATETIME_CONFIG von props.conf nicht explizit festgelegt wird, versucht Splunk, den Zeitstempel in einem Ereignis selbst zu finden.


Wenn Splunk also den Wert findet, der dem gültigen Zeitstempelformat entspricht, wird beim Extrahieren des Zeitstempels aus den Ereignissen derselbe Wert wie die Ereigniszeit analysiert und nur mit diesem Zeitstempel indiziert. Dies kann dazu führen, dass Splunk einen neuen heißen Bucket erstellt, da der Zeitstempel nicht ordnungsgemäß extrahiert wird.

Erwägen Sie, Zeitstempelattribute in props.conf hinzuzufügen, damit Splunk den Zeitstempel richtig extrahiert. Konfigurieren Sie die Zeitstempelerkennung.
 

Problem mit dem Stempel:

Außerdem habe ich die folgenden Nachrichten in der splunkd.log in Bezug auf den Zeitstempel auch sie durch die Anwendung der richtigen Einstellungen zu beheben hängt vom Log-Format.
 

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

 

Auflösung

1. Navigieren Sie zu $SPLUNK_HOME/etc/system/local/health.conf und hängen Sie den folgenden Strophen an
 

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

2. Starten Sie den Splunk neu, damit die Änderungen wirksam werden.

Wenn es sich um einen Zeitstempel oder ein DATETIME_CONFIG-Problem handelt, schreiben Sie einen geeigneten regulären Ausdruck, um Datum und Uhrzeit des Ereignisses korrekt zu identifizieren und das Problem zu beheben.

Verwandte Links

Splunk-Dokumentation
Zeitstempelerkennung konfigurieren 


Punktantworten
Gesundheitsstatus: Der Prozentsatz kleiner erstellter Buckets 

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
1.0	28-Sep-2026	Erstveröffentlichung