Gravar Consultas de Desempenho para Pesquisar e Exportar Logs

Compreendendo o Índice

Durante a ingestão de log, o registro de log é analisado usando o parser, a origem de log, os campos e os campos estendidos e os labels são extraídos. Todos esses valores são armazenados em um índice com eficiência de consulta. Além disso, as palavras-chave em todo o registro de log também são indexadas. As consultas que usam o índice são várias vezes mais rápidas do que as consultas que não usam o índice. Se você estiver consultando um grande volume de dados, deverá garantir que o índice seja usado.

Quando o índice não é usado?

Um índice não é usado quando uma consulta usa curingas ou quando um campo é manipulado usando uma das funções de processamento de string. Estes são alguns exemplos:

• Evite usar curingas na consulta

  Um caso de uso comum é procurar um padrão específico em um campo da seguinte forma:

  'Error Text' like '%NullPointerException%'

  A consulta acima não usará o índice devido ao uso de curingas. Se o campo Texto de Erro tiver uma grande quantidade de dados ou se a consulta for executada em um grande número de registros, o tempo limite será atingido. Para evitar isso, adicione uma condição na origem de log para detectar esse padrão e definir um campo. Em seguida, você pode usar diretamente esse campo na consulta.

  Por exemplo, você pode preencher um campo chamado Tipo de Erro na origem de log, com base em várias condições e, em seguida, atualizar a consulta para usar esse campo:

  'Error Type' = NullPointerException

  Se você não conseguir adicionar o padrão à origem de log, uma alternativa será alterar para uma pesquisa de palavra-chave da seguinte forma:

  NullPointerException

  Isso procurará a palavra NullPointerException no campo Conteúdo do Log Original que representa o registro de log bruto. Isso será útil se você não precisar de uma correspondência exata, pois essa consulta é várias vezes mais rápida do que a consulta anterior usando os curingas.

  Observação
  
  O uso de curingas em um campo que armazena uma grande quantidade de campos tem desempenho pior do que em um campo pequeno. Mas se o número de registros de log envolvidos for grande, mesmo os curingas contra um campo pequeno serão lentos.

• Evite usar operadores de string caros

  Um índice não é usado em campos gerados usando operações de string como substr(), extract e jsonExtract. Veja a seguir alguns exemplos nos quais o índice é ignorado:

  * | eval Prefix = substr('Host Name (Server)', 1, 3) | where Prefix = DBC
  
  * | where indexOf('Host Name (Server)', 'DBC') != -1

  Se você precisar usar com frequência operadores de string, considere movê-los para o parser ou origem de log e criar campos separados.

Intervalos de tempo longo

Consultar uma grande quantidade de dados durante um longo período também é caro. Tente reduzir o intervalo de tempo ou adicione mais critérios de pesquisa para reduzir a quantidade de dados a serem processados.

Usando Vários Conjuntos de Logs

Se sua tenancy tiver o particionamento de log ativado, você estará usando um conjunto de logs para selecionar uma parte dos dados de log. Os conjuntos de logs são otimizados para reduzir a carga no sistema. Se você consultar um único conjunto de logs, a consulta será mantida em um conjunto menor de servidores. Mas uma consulta em um grande número de conjuntos de logs causa mais transferência de dados e consulta em um maior número de serviços. Isso pode fazer com que as consultas diminuam significativamente.

Evite usar mais de cinco conjuntos de logs em uma consulta para obter o melhor desempenho.

Outras operações dispendiosas

Veja a seguir algumas das outras operações caras que podem tornar as consultas lentas em relação a uma grande quantidade de dados:

• sort
• Comandos head ou tail
• Comandos stats ou timestats com campos de alta cardinalidade. Estes são os campos que têm um grande número de valores distintos. ID da transação, ECID, etc. são exemplos desses campos.