Descripción del Índice

Durante la ingesta de logs, el registro de log se analiza mediante el analizador, el origen de log, los campos y los campos ampliados, y se extraen las etiquetas. Todos estos valores se almacenan en un índice de eficiencia de consulta. Además, las palabras clave de todo el registro de log también se indexan. Las consultas que utilizan el índice son varias veces más rápidas que las consultas que no utilizan el índice. Si está consultando una gran cantidad de datos, debe asegurarse de que se utiliza el índice.

¿Cuándo no se utiliza el índice?

Un índice no se utiliza cuando una consulta utiliza comodines o cuando un campo se manipula mediante una de las funciones de procesamiento de cadenas. Algunos ejemplos:

• Evitar el uso de comodines en la consulta

  Un caso de uso común es buscar un patrón específico en un campo de la siguiente manera:

  'Error Text' like '%NullPointerException%'

  La consulta anterior no utilizará el índice debido al uso de comodines. Si el campo Texto de error tiene una gran cantidad de datos o si la consulta se ejecuta en un gran número de registros, finalmente se agota el tiempo de espera. Para evitarlo, agregue una condición en el origen de log para detectar este patrón y definir un campo. A continuación, puede utilizar directamente ese campo en la consulta.

  Por ejemplo, puede rellenar un campo denominado Tipo de error en el origen de log en función de varias condiciones y, a continuación, actualizar la consulta para utilizar este campo:

  'Error Type' = NullPointerException

  Si no puede agregar el patrón al origen de log, una alternativa es cambiar a una búsqueda por palabra clave de la siguiente manera:

  NullPointerException

  Esto buscará la palabra NullPointerException en el campo Contenido de log original que representa el registro de log sin formato. Esto resulta útil si no necesita una coincidencia exacta, ya que esta consulta es varias veces más rápida que la consulta anterior mediante comodines.

  Nota
  
  El uso de comodines en un campo que almacena una gran cantidad de campos tiene un rendimiento peor que en un campo pequeño. Pero si el número de registros de log implicados es grande, incluso los comodines contra un campo pequeño son lentos.

• Evitar el uso de costosos operadores de cadena

  No se utiliza un índice en los campos generados mediante operaciones de cadena como substr(), extract y jsonExtract. A continuación se muestran algunos ejemplos en los que se omite el índice:

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

  Si necesita utilizar operadores de cadena con frecuencia, debe considerar moverlos al analizador o al origen de log y crear campos independientes.

Intervalos de tiempo largos

Consultar una gran cantidad de datos durante un largo período también es costoso. Intente reducir el rango temporal o agregue más criterios de búsqueda para reducir la cantidad de datos que se van a procesar.

Uso de Varios Juegos de Log

Si su arrendamiento tiene activada la partición de logs, utilizaría un juego de logs para seleccionar una parte de los datos del log. Los juegos de logs están optimizados para reducir la carga en el sistema. Si realiza una consulta en un único juego de logs, la consulta se mantiene en un juego más pequeño de servidores. Sin embargo, una consulta en un gran número de juegos de logs provoca más transferencia de datos y consultas en un mayor número de servicios. Esto puede provocar que las consultas se ralenticen significativamente.

Evite utilizar más de cinco juegos de logs en una consulta para obtener el mejor rendimiento.

Otras operaciones costosas

A continuación, se muestran algunas de las otras operaciones costosas que pueden ralentizar las consultas en una gran cantidad de datos:

• sort
• Comandos head o tail
• Comandos stats o timestats con campos de cardinalidad alta. Estos son los campos que tienen un gran número de valores distintos. ID de transacción, ECID, etc. son ejemplos de estos campos.