El estado de la instancia de Splunk se muestra en ROJO para el componente Bucket

Aplicabilidad

Splunk Enterprise

Descripción

El porcentaje de pequeños bloques de bloques creados (100) durante la última hora es muy alto y ha superado los umbrales rojos (50) para index=<index name>, y posiblemente más índices, en este indizador.

Mensajes de ERROR en la ficha Comprobación de estado:

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 

Últimos 50 mensajes relacionados: 

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

 

Investigación

El mensaje anterior indica que el 100% de los bloques creados en las últimas 24 horas es inferior al 10% de maxDataSize. Esto no causará ningún problema de rendimiento. Para corregir esta advertencia, puede aumentar el umbral de 50 a 150 como se indica a continuación.

La configuración predeterminada se encuentra en la ubicación $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

 

También del mensaje de advertencia de estado anterior se muestra cuando el número de bloques creados para indexar los datos en una hora/día particular cruza o alcanza el límite de umbral definido en system/health.conf.
 

La razón detrás de la creación de demasiadas cubas calientes
 

Splunk utiliza bloques como directorio de índice para indexar los datos. Ahora, cuando un evento llega a Splunk para indexación, se creará la nueva cubeta de conexión para ese evento o el evento se indexará con la cubeta de conexión existente según la marca de tiempo del evento y las restricciones en el índice.

Consulte los parámetros maxHotBukets, maxHotSpanSecs y quarantinePastSecs de indexes.conf
 

Por lo tanto, si el evento tiene la marca de tiempo más antigua/extraña que la aceptable para los depósitos existentes, Splunk creará un nuevo depósito activo para indexar ese evento. Por lo tanto, el número de bloques activos creados puede alcanzar o cruzar el umbral.
 

Cuando el parámetro DATETIME_CONFIG de props.conf no se establece explícitamente, Splunk intentará encontrar la marca de tiempo en un evento en sí.


Por lo tanto, al extraer la marca de tiempo de los eventos, si Splunk encuentra el valor que coincide con el formato de marca de tiempo válido, analizaría el mismo valor que la hora del evento y lo indexaría usando solo esa marca de tiempo, lo que puede hacer que Splunk cree una nueva cubeta de tiempo, ya que la marca de tiempo no se extrae correctamente.

Considere la posibilidad de agregar atributos de marca de hora en props.conf para que Splunk extraiga la marca de hora correctamente. Configure el reconocimiento de marca de hora
 

Problema de marca de hora:

Además, he encontrado los siguientes mensajes en el splunkd.log con respecto a la marca de tiempo también los corrige aplicando la configuración correcta depende del formato de registro.
 

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

 

Resolución

1. Navegue hasta $SPLUNK_HOME/etc/system/local/health.conf y agregue la siguiente estrofa
 

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

2. Reinicie el Splunk para que los cambios surtan efecto.

Si se trata de un problema de marca de tiempo o DATETIME_CONFIG, escriba un regex adecuado para identificar la fecha y la hora del evento correctamente y rectifique el problema.

Enlaces relacionados

Documentación de Splunk
Configurar el reconocimiento de marca de tiempo 


Respuestas de Splunk
Estado de salud: El porcentaje de pequeños depósitos creados 

Historial de revisiones

Revisión	Fecha de publicación	Comentarios
1.0	28-Sep-2026	Versión inicial