Comprendre l'index

Lors de l'ingestion de journal, 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 efficace pour les requêtes. 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 de grandes quantités 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îne. Voici quelques exemples :

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

  Un cas d'emploi 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 d'erreur contient une grande quantité de données, ou si la requête est exécutée sur un grand nombre d'enregistrements, elle expire à terme. 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 passer à une recherche par mot-clé comme suit :

  NullPointerException

  Cette opération permet de rechercher le mot NullPointerException dans le champ Contenu du journal d'origine qui représente l'enregistrement de journal brut. Cela 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 des caractères génériques.

  Remarque
  
  L'utilisation de caractères génériques pour un champ stockant un grand nombre de champs est moins performante que pour 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.

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

  Un index n'est pas 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.

Périodes longues

L'interrogation d'une grande quantité de données sur une longue période est également coûteuse. Essayez de réduire la période ou ajoutez 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é dans votre location, vous utilisez 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 effectuez une requête sur un seul ensemble de journaux, la requête est conservée sur un ensemble de serveurs plus petit. Toutefois, une interrogation sur un grand nombre d'ensembles de journaux entraîne davantage de transfert de données et d'interrogation sur un plus grand nombre de services. Cela peut ralentir considérablement les requêtes.

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 sur une grande quantité de données :

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