No Splunk, é muito comum que uma mesma pergunta possa ser respondida de várias maneiras usando o Search Processing Language (SPL). No entanto, enquanto uma query pode rodar em 2 segundos, outra com a mesma finalidade pode levar minutos e esgotar os limites de CPU do seu Search Head.

Abaixo, listamos as regras de ouro para escrever pesquisas performáticas em ambientes de missão crítica.

1. Filtre cedo e filtre sempre

A regra número um de performance no Splunk é limitar a quantidade de dados recuperados do disco antes de aplicar qualquer processamento em memória. A primeira linha da sua busca deve ser o mais restritiva possível.

• Sempre use o Time Picker: Nunca faça buscas em “All time”.
• Especifique o Index e Sourcetype: Evite buscas genéricas que forçam o Splunk a ler todos os buckets.

// Ruim: Varre vários indexes e extrai tudo para depois filtrar
* "Failed password" | stats count by user

// Excelente: Filtra no momento da leitura do disco
index=security sourcetype=linux_secure "Failed password" 
| stats count by user

2. Prefira STATS no lugar de TRANSACTION O comando transaction é útil para agrupar eventos baseados em tempo ou condições complexas de início e fim. Porém, ele é extremamente pesado porque não pode ser distribuído para os Indexadores (ele roda primariamente na memória do Search Head).

Em 90% dos casos, você pode obter o mesmo resultado usando stats, que é um comando “streaming” e pode ser processado de forma paralela nos Indexadores.

// Ruim e Lento (Usa muita memória)
index=web | transaction session_id | search duration > 5

//Excelente e Rápido (Distribuído)

index=web 
| stats min(_time) as first_event max(_time) as last_event by session_id 
| eval duration = last_event - first_event 
| where duration > 5

3. Utilize o comando FIELDS Se a sua busca retornar eventos contendo dezenas de campos complexos e regexes longos, limite a extração. O comando fields diz ao Splunk para focar apenas nas colunas que você vai realmente usar no próximo passo do pipeline.

index=firewall action=blocked 
| fields src_ip, dest_ip, action 
| stats count by src_ip

4. O poder do TSTATS (Data Models) Se você tem modelos de dados (Data Models) ativados e acelerados no seu ambiente (como o CIM), pare de usar buscas regulares. O comando tstats faz consultas puramente em metadados (tsidx), resultando em buscas que retornam em frações de segundo, mesmo olhando para bilhões de eventos ao longo de meses.

| tstats count from datamodel=Network_Traffic 
where nodename=All_Traffic.Traffic_By_Action 
by All_Traffic.src_ip

Conclusão

Otimizar consultas SPL não é apenas uma questão de conveniência, mas de economia de infraestrutura. Utilize o Job Inspector (atalho: Cmd/Ctrl + Shift + I durante uma busca) para auditar o tempo de execução e entender onde o processamento está sendo gasto.