Splunk Instance health toont RED voor de component Bucket

toepasbaarheid

Splunk Enterprise

Beschrijving

Het percentage kleine emmers dat het afgelopen uur is gemaakt (100) is zeer hoog en overschrijdt de rode drempels (50) voor index=<indexnaam>, en mogelijk meer indexen, op deze indexeerder.

FOUTMELDINGEN op het tabblad Gezondheidscontrole:

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 

Laatste 50 gerelateerde berichten: 

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

 

onderzoek

Het bovenstaande bericht zegt dat 100% van de emmers die de afgelopen 24 uur zijn gemaakt, minder dan 10% van maxDataSize is. Dit zal geen prestatieproblemen veroorzaken. Om deze waarschuwing te herstellen, kunt u de drempel verhogen van 50 naar 150 zoals hieronder.

De standaardconfiguratie bevindt zich op de locatie $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

 

Ook uit het bovenstaande wordt hetzelfde waarschuwingsbericht weergegeven wanneer het aantal hot buckets dat is gemaakt om de gegevens in een bepaald uur/dag te indexeren, de in system/health.conf gedefinieerde drempelwaarde overschrijdt of bereikt.
 

De reden achter het creëren van te veel hete emmers
 

Splunk gebruikt emmers als indexdirectory om de gegevens te indexeren. Wanneer een gebeurtenis naar Splunk komt voor indexering, wordt de nieuwe hot bucket voor die gebeurtenis gemaakt of wordt de gebeurtenis geïndexeerd aan de bestaande een van de hot buckets volgens de tijdstempel en beperkingen van de gebeurtenis op de index.

Raadpleeg maxHotBuckets, maxHotSpanSecs en quarantainePastSecs parameters van indexes.conf
 

Dus, als de gebeurtenis de oudere / vreemde tijdstempel heeft dan aanvaardbaar is voor de bestaande emmers, dan zal Splunk een nieuwe hot bucket maken om die gebeurtenis te indexeren. Daarom kan het aantal warme emmers dat wordt gemaakt de drempel bereiken of overschrijden.
 

Wanneer de parameter DATETIME_CONFIG van props.conf niet expliciet is ingesteld, probeert Splunk de tijdstempel in een gebeurtenis zelf te vinden.


Dus, terwijl het extraheren van de tijdstempel van de gebeurtenissen, als Splunk vindt de waarde die overeenkomt met de geldige tijdstempel formaat, zou het dezelfde waarde als gebeurtenis tijd parsen en zou het indexeren met behulp van alleen die tijdstempel, die kan leiden Splunk om nieuwe hot bucket te maken als de tijdstempel is niet goed geëxtraheerd.

Overweeg het toevoegen van tijdstempel attributen in props.conf om Splunk extract tijdstempel goed te maken. Tijdstempelherkenning configureren
 

Probleem met tijdstempel:

Ook heb ik de onderstaande berichten in het splunkd.log gevonden met betrekking tot de tijdstempel en los ze ook op door de juiste instellingen toe te passen, afhankelijk van het logformaat.
 

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

 

resolutie

1. Navigeer naar $SPLUNK_HOME/etc/system/local/health.conf en voeg de onderstaande strofe toe
 

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

2. Start de Splunk opnieuw op zodat de wijzigingen worden doorgevoerd.

Als er een timestamp of DATETIME_CONFIG probleem is, schrijf dan een juiste regex om de datum en tijd van de gebeurtenis correct te identificeren en het probleem te verhelpen.

Gerelateerde links

Splunk-documentatie
Tijdstempelherkenning configureren 


Splunk Antwoorden
Gezondheidsstatus: Het percentage kleine emmers dat wordt gemaakt 

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
1.0	28-Sep-2026	Eerste vrijgave