Escribir consultas eficaces para buscar y exportar logs
Aquí se analizan algunos de los aspectos importantes que debe tener en cuenta al redactar las consultas para buscar y exportar logs.
Temas:
Descripción del Índice
Durante la ingestión de logs, el registro de log se analiza mediante el analizador, el origen de log, los campos, los campos ampliados y las etiquetas se extraen. Todos estos valores se almacenan en un índice de consulta eficiente. 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 realiza consultas sobre 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. A continuación, se muestran algunos ejemplos:
-
Evite utilizar 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, al final se produce un timeout. 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' = NullPointerExceptionSi no puede agregar el patrón al origen de log, una alternativa es cambiar a una búsqueda por palabras clave de la siguiente manera:
NullPointerExceptionDe esta forma, se 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 con comodines.
Nota
El uso de comodines en un campo que almacena una gran cantidad de campos es peor que en un campo pequeño. Pero si el número de registros de log implicados es grande, incluso los comodines en un campo pequeño son lentos. -
Evitar el uso de costosos operadores de cadenas
No se utiliza un índice en los campos generados mediante operaciones de cadena como
substr(),extractyjsonExtract. 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') != -1Si necesita utilizar con frecuencia operadores de cadena, debe considerar moverlos al analizador o al origen de log y crear campos independientes.
Rangos 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 la partición de log activada, debería utilizar un juego de logs para seleccionar una parte de los datos de log. Los juegos de logs se optimizan para reducir la carga en el sistema. Si realiza una consulta en un único juego de logs, la consulta se mantiene en un juego de servidores más pequeño. Sin embargo, una consulta en un gran número de juegos de logs provoca más transferencia de datos y consulta en un mayor número de servicios. Esto puede hacer 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 con una gran cantidad de datos:
sort- Comandos
headotail - Comandos
statsotimestatscon campos de cardinalidad alta. Estos son los campos que tienen un gran número de valores distintos. El ID de transacción, el ECID, etc. son ejemplos de estos campos.