Ecrire des requêtes performantes pour la recherche et l'exportation de journaux

Comprendre l'index

Pendant l'assimilation des journaux, l'enregistrement de journal est analysé à l'aide de l'analyseur, de la source de journal, des champs et des champs étendus, et les libellés sont extraits. Toutes ces valeurs sont stockées dans un index basé sur une requête. En outre, les mots-clés de l'ensemble de l'enregistrement de journal sont également indexés. Les requêtes qui utilisent l'index sont plusieurs fois plus rapides que celles qui n'utilisent pas l'index. Si vous interrogez une grande quantité de données, vous devez vous assurer que l'index est utilisé.

Quand l'index n'est-il pas utilisé ?

Un index n'est pas utilisé lorsqu'une requête utilise des caractères génériques ou lorsqu'un champ est manipulé à l'aide de l'une des fonctions de traitement de chaînes. Vous trouverez ci-dessous quelques exemples :

• Evitez d'utiliser des caractères génériques dans la requête

  Un cas d'utilisation courant consiste à rechercher un modèle spécifique dans un champ comme suit :

  'Error Text' like '%NullPointerException%'

  La requête ci-dessus n'utilisera pas l'index en raison de l'utilisation de caractères génériques. Si le champ Texte de l'erreur contient une grande quantité de données, ou si la requête est exécutée sur un grand nombre d'enregistrements, elle finit par expirer. Pour éviter cela, ajoutez une condition dans la source de journal pour détecter ce modèle et définir un champ. Vous pouvez ensuite utiliser directement ce champ dans la requête.

  Par exemple, vous pouvez renseigner un champ nommé Type d'erreur dans la source de journal, en fonction de différentes conditions, puis mettre à jour la requête pour utiliser ce champ :

  'Error Type' = NullPointerException

  Si vous ne pouvez pas ajouter le modèle à la source de journal, vous pouvez également effectuer une recherche par mot-clé comme suit :

  NullPointerException

  Cette action recherche le mot NullPointerException dans le champ Contenu du journal d'origine qui représente l'enregistrement de journal brut. Ceci est utile si vous n'avez pas besoin d'une correspondance exacte, car cette requête est plusieurs fois plus rapide que la requête précédente utilisant les caractères génériques.

  Remarque
  
  L'utilisation de caractères génériques sur un champ stockant un grand nombre de champs est pire que sur un petit champ. Mais si le nombre d'enregistrements de journal impliqués est important, même les caractères génériques contre un petit champ sont lents.

• Eviter d'utiliser des opérateurs de chaîne coûteux

  Aucun index n'est utilisé sur les champs générés à l'aide d'opérations de chaîne telles que substr(), extract et jsonExtract. Voici quelques exemples où l'index est ignoré :

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

  Si vous avez besoin d'utiliser fréquemment des opérateurs de chaîne, vous devez envisager de les déplacer vers l'analyseur ou la source de journal et de créer des champs distincts.

Intervalles de temps longs

Interroger une grande quantité de données sur une longue période est également coûteux. Essayez de réduire la période ou d'ajouter d'autres critères de recherche pour réduire la quantité de données à traiter.

Utiliser plusieurs ensembles de journaux

Si le partitionnement de journal est activé pour votre location, vous devez utiliser un ensemble de journaux pour sélectionner une partie des données de journal. Les ensembles de journaux sont optimisés pour réduire la charge sur le système. Si vous interrogez un seul ensemble de journaux, celui-ci conserve la requête sur un plus petit ensemble de serveurs. Mais une interrogation sur un grand nombre d'ensembles de journaux entraîne davantage de transfert de données et d'interrogations sur un plus grand nombre de services. Les requêtes peuvent ainsi ralentir considérablement.

Evitez d'utiliser plus de cinq ensembles de journaux dans une requête pour obtenir les meilleures performances.

Autres opérations coûteuses

Voici quelques-unes des autres opérations coûteuses qui peuvent ralentir les requêtes portant sur une grande quantité de données :

• sort
• Commandes head ou tail
• Commandes stats ou timestats avec des champs de cardinalité élevée. Ce sont les champs qui ont un grand nombre de valeurs distinctes. ID de transaction, ECID, etc. sont des exemples de ces champs.