emergency responseIntervention d’urgence
CONTACTEZ

Accueil | Optimisation du rendement SPL à l’aide de TERM()

Optimisation du rendement SPL à l’aide de TERM()

Décembre 2, 2025 | By / Par : Virtual Guardian
Share: linked inx

Le langage SPL (Splunk Processing Language) est le moyen fondamental par lequel les utilisateurs interagissent avec les données dans leur environnement Splunk.  Bien que nous soyons nombreux à utiliser régulièrement le langage SPL, nous oublions souvent que la charge de recherche est l’un des principaux facteurs déterminants pour le dimensionnement à long terme.  Si l’optimisation de l’ingestion est également importante, la création de recherches efficaces est un moyen essentiel de réduire la charge du serveur, offrant ainsi une meilleure expérience utilisateur à tous les utilisateurs de votre environnement Splunk.

Les environnements en pleine croissance, en particulier, ont tendance à générer des recherches de plus en plus complexes, alambiquées et gourmandes en ressources.  Cela se traduit directement par un ralentissement du chargement des tableaux de bord, des performances médiocres et une expérience utilisateur plus frustrante.  En améliorant les performances de recherche, la charge globale sur l’environnement est réduite, la productivité s’améliore et le SPL potentiellement inutilisable est supprimé, ce qui permet aux utilisateurs de s’attaquer à de nouveaux problèmes.  Il en résulte un meilleur retour sur investissement pour divers investissements matériels.

Pour atteindre nos objectifs, nous devons d’abord comprendre le LISPY et la manière dont Splunk utilise votre SPL pour créer plusieurs paramètres de recherche qui sont utilisés pour générer des résultats recherchés et correspondants. 

Qu’est-ce que le LISPY ?

Lorsqu’une recherche est exécutée, Splunk utilise votre SPL pour générer une recherche optimisée, une recherche littérale et une recherche LISPY. À un niveau très basique, LISPY est le lexique (ou les mots-clés) et les portes logiques (AND/OR/NOT) que Splunk utilise pour rassembler initialement les événements pertinents avant de faire correspondre vos événements à votre recherche.  Essentiellement, il détermine les événements que Splunk extraira de tous les compartiments pertinents avant de vérifier s’ils correspondent à vos critères de recherche. Il s’agit en quelque sorte d’une recherche préalable à la recherche.

Lorsque les événements sont ingérés, Splunk crée un mappage des événements vers divers mots-clés qui correspondent à chaque événement.  Il prend l’événement brut et le décompose à l’aide de séparateurs principaux, puis applique des séparateurs secondaires à ces séparateurs principaux.  Pour en savoir plus sur les séparateurs, consultez la page de documentation de Splunk.  Pour nos besoins, il suffit de savoir que les séparateurs principaux sont des mots qui apparaissent dans l’événement brut, délimités par des espaces, des guillemets et quelques autres caractères spéciaux.  Ce qui rend cela très intéressant, c’est qu’ils sont appliqués pendant l’indexation. Oui, vous avez bien lu.  Cela rend possible l’utilisation de TERM lors de fonctions telles que tstats.

En utilisant LISPY, les breakers majeurs/mineurs et la fonction TERM, nous pouvons désormais parler d’optimisation de notre recherche. Prenons la requête de recherche de référence suivante :

Requête de référence :

index=vg_es_windows sourcetype=”wineventlog” EventCode=4*

reference query

Requête de test :

index=vg_es_windows sourcetype=”wineventlog” TERM(EventCode=4*)

test query

Vous vous demandez peut-être pourquoi le temps d’exécution utilisant TERM est plus de 50 % plus rapide que la requête de référence ?

La réponse réside dans le LISPY.

LISPY de la requête de référence = [AND 4* index::vg_es_windows sourcetype::wineventlog]

LISPY de la requête test = [AND eventcode=4* index::vg_es_windows sourcetype::wineventlog]

Dans la recherche de référence, le LISPY extrait de la recherche est simplement 4*. Cela signifie que Splunk recherchera TOUT événement avec un nombre 4* sous l’index correspondant et la définition du type de source, ce qui correspondra au « nombre d’événements analysés » (29 560). Ensuite, il les comparera à votre requête de recherche et rejettera tous ceux qui ne répondent pas aux critères, ce qui donnera un total de 11 116 événements correspondants.

Notre requête de test utilisant la fonction TERM donne un LISPY différent. Dans ce cas, nous avons demandé à Splunk d’isoler uniquement les événements contenant le mot-clé eventcode=4* – cela donnera un nombre d’événements analysés beaucoup plus faible. En fait, comme vous pouvez le constater, le nombre d’événements analysés et le nombre d’événements correspondants sont identiques. Sur les 11 116 événements analysés à l’aide du LISPY, nous avons obtenu un taux de correspondance de 100 %. En conséquence, notre temps d’exécution de recherche a également diminué.

Pour utiliser TERM, le mot-clé que vous essayez d’isoler doit être délimité par des séparateurs majeurs. La fonction TERM fonctionne mieux lorsque le mot-clé que vous recherchez comporte un ou plusieurs séparateurs mineurs. Par exemple, une adresse IP 44.34.24.111 donnerait un LISPY de [AND 44 34 24 111], tandis que l’inclure dans une fonction TERM donnerait [AND 44.34.24.111]. Gardez à l’esprit que lorsque vous essayez d’optimiser votre requête avec la fonction TERM, il est préférable de comparer les résultats de recherche d’origine avec les nouveaux résultats de requête dans le même laps de temps fixe.

Vous souhaitez en savoir plus sur l’optimisation de Splunk ? Discutez dès aujourd’hui avec nos experts : https://www.virtualguardian.com/fr/api-contactez-nous/

Devenir contributeur

Devenez un blogueur invité avec Gardien Virtuel!

Vous avez une idée pour notre prochain billet de blogue ou vous souhaitez suggérer un sujet d’actualité pour “Behind the Shield”? Dites-nous ce que vous voulez savoir!

rss feed icon

Actualités du gouvernement

Vous n’arrivez pas à cibler les nombreuses menaces qui pèsent sur votre entreprise?

Laissez notre SOC actif en tout temps, alimenté par le système de sécurité d’IBM QRadar, protéger votre organisation