A integridade da Instância de Splunk está mostrando VERMELHO para o componente Bucket

Aplicabilidade

Empresa Splunk

Descrição

A porcentagem de pequenos buckets criados (100) durante a última hora é muito alta e excedeu os limites vermelhos (50) para index=<index name> e, possivelmente, mais índices, neste indexador.

Mensagens de ERRO na guia Verificação de integridade:

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 

Últimas 50 mensagens relacionadas: 

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

 

Investigação

A mensagem acima está dizendo que 100% dos buckets criados para as últimas 24 horas é menos de 10% de maxDataSize. Isso não causará nenhum problema de desempenho. Para corrigir esse aviso, você pode aumentar o limite de 50 para 150, como mostrado abaixo.

A configuração padrão está no local $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

 

Além disso, a mesma mensagem de aviso de integridade acima é mostrada quando o número de hot buckets criados para indexar os dados em uma hora/dia específica ultrapassa ou atinge o limite definido em system/health.conf.
 

A razão por trás da criação de muitos hot buckets
 

O Splunk usa buckets como um diretório de índice para indexar os dados. Agora, quando um evento chega ao Splunk para indexação, o novo hot bucket será criado para esse evento ou o evento será indexado ao existente um dos hot buckets de acordo com o carimbo de data/hora e as restrições do evento no índice.

Consulte os parâmetros maxHotBuckets, maxHotSpanSecs e quarantinePastSecs de indexes.conf
 

Portanto, se o evento estiver tendo o timestamp mais antigo/estranho do que o aceitável para os buckets existentes, o Splunk criará um novo hot bucket para indexar esse evento. Assim, o número de hot buckets criados pode atingir ou ultrapassar o limite.
 

Quando o parâmetro DATETIME_CONFIG de props.conf não estiver definido explicitamente, o Splunk tentará localizar o carimbo de data/hora em um evento em si.


Assim, ao extrair o timestamp dos eventos, se o Splunk encontrar o valor que corresponde ao formato de timestamp válido, ele analisará o mesmo valor que o tempo do evento e o indexará usando apenas esse timestamp, o que pode fazer com que o Splunk crie um novo hot bucket, já que o timestamp não foi extraído corretamente.

Considere adicionar atributos de timestamp em props.conf para fazer com que o timestamp de extração de Splunk seja corretamente. Configure o reconhecimento de timestamp
 

Problema de carimbo de data/hora:

Além disso, eu encontrei as mensagens abaixo no splunkd.log sobre o timestamp também corrigi-los aplicando as configurações corretas depende do formato de 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

 

Resolução

1. Navegue até $SPLUNK_HOME/etc/system/local/health.conf e anexe a estrofe abaixo
 

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

2. Reinicie o Splunk para que as alterações tenham efeito.

Se for um problema de carimbo de data/hora ou DATETIME_CONFIG, escreva um regex apropriado para identificar a data e a hora do evento corretamente e retificar o problema.

Links relacionados

Documentação do Splunk
Configurar reconhecimento de carimbo de data/hora 


Respostas de Splunk
Status de Integridade: A porcentagem de pequenos buckets criados 

Histórico de revisões

Revisão	Data de publicação	Comentários
1.0	28-Sep-2026	Versão inicial