Scrivere query performanti per la ricerca e l'esportazione dei log

Informazioni sull'indice

Durante l'inclusione del log, il record di log viene analizzato utilizzando il parser, l'origine del log, i campi e i campi estesi e le etichette vengono estratti. Tutti questi valori vengono memorizzati in un indice efficiente per le query. Inoltre, vengono indicizzate anche le parole chiave nell'intero record di log. Le query che utilizzano l'indice sono più volte più veloci rispetto alle query che non utilizzano l'indice. Se si esegue una query su una grande quantità di dati, è necessario assicurarsi che venga utilizzato l'indice.

Quando l'indice non viene utilizzato?

Un indice non viene utilizzato quando una query utilizza caratteri jolly o quando un campo viene manipolato utilizzando una delle funzioni di elaborazione delle stringhe. Ecco alcuni esempi:

• Evitare l'uso di caratteri jolly nella query

  Un caso d'uso comune consiste nel cercare un pattern specifico in un campo come indicato di seguito.

  'Error Text' like '%NullPointerException%'

  La query precedente non utilizzerà l'indice a causa dell'uso di caratteri jolly. Se il campo Testo errore contiene una grande quantità di dati o se l'interrogazione viene eseguita su un numero elevato di record, si verificherà il timeout. Per evitare questo problema, aggiungere una condizione nell'origine log per rilevare questo pattern e impostare un campo. Quindi è possibile utilizzare direttamente tale campo nella query.

  Ad esempio, è possibile popolare un campo denominato Tipo di errore nell'origine log, in base a varie condizioni, quindi aggiornare la query per utilizzare questo campo:

  'Error Type' = NullPointerException

  Se non si è in grado di aggiungere il pattern all'origine log, l'alternativa consiste nel passare a una ricerca per parola chiave come indicato di seguito.

  NullPointerException

  Verrà eseguita la ricerca della parola NullPointerException nel campo Contenuto log originale che rappresenta il record di log non elaborato. Ciò è utile se non è necessaria una corrispondenza esatta, poiché questa query è più volte più veloce della query precedente che utilizza i caratteri jolly.

  Nota
  
  L'uso di caratteri jolly in un campo che memorizza grandi quantità di campi ha prestazioni peggiori rispetto a un campo di piccole dimensioni. Ma se il numero di record di log coinvolti è grande, anche i caratteri jolly contro un piccolo campo sono lenti.

• Evitare di utilizzare costosi operatori di stringhe

  Un indice non viene utilizzato nei campi generati utilizzando operazioni stringa quali substr(), extract e jsonExtract. Di seguito sono riportati alcuni esempi in cui l'indice viene saltato.

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

  Se è necessario utilizzare frequentemente gli operatori stringa, è consigliabile spostarli nell'origine parser o log e creare campi separati.

Intervalli di tempo lunghi

Anche eseguire query su una grande quantità di dati su un lungo periodo è costoso. Provare a ridurre l'intervallo di tempo o aggiungere altri criteri di ricerca per ridurre la quantità di dati da elaborare.

Uso di più set di log

Se per la tenancy è abilitato il partizionamento dei log, si utilizzerà un set di log per selezionare una parte dei dati di log. I set di log sono ottimizzati per ridurre il carico sul sistema. Se si esegue una query su un singolo set di log, la query viene mantenuta su un set di server più piccolo. Tuttavia, una query su un numero elevato di set di log causa un maggiore trasferimento di dati ed esegue query su un numero maggiore di servizi. Ciò può causare un significativo rallentamento delle query.

Evitare di utilizzare più di cinque set di log in una query per ottenere le migliori prestazioni.

Altre operazioni costose

Di seguito sono riportate alcune delle altre operazioni costose che possono rallentare le query su una grande quantità di dati:

• sort
• Comandi head o tail
• Comandi stats o timestats con campi di cardinalità elevata. Questi sono i campi con un numero elevato di valori distinti. ID transazione, ECID e così via sono esempi di tali campi.