Dans cet article, nous allons voir ce que sont les champs indexés – autrement documentés aux chapitres Indexed Field Extraction – et en quoi ils sont certes efficaces, mais peuvent aussi s’avérer consommateurs de ressources.
| tstats : La commande la plus rapide de Splunk
Vous pouvez immédiatement tester cette commande sur tout jeu de données, en commençant la recherche par le symbole | mettant à l’honneur les commandes dites generating, et en comparant la vitesse d’exécution avec une syntaxe plus classique.
Syntaxe tstats |
Syntaxe classique |
| tstats count |
* | stats count |
| tstats count by source |
* | stats count by source |
| tstats count where index=_internal by date_hour, host |xyseries date_hour, host, count | sort date_hour |
index=_internal | chart count by date_hour, host |
Les résultats seront identiques à l’affichage pour peu que vous ayez accès aux indexes sollicités. Mais pour bien voir l’efficacité de cette commande, assurez-vous de sélectionner une très grande plage de date, voire « Tout le temps ». Vérifiez depuis « Inspecter la tâche » (Job Inspector) et vous devriez noter un facteur de 1 à 10 dans la rapidité.
Vous avez bien lu : tstats renvoie les résultats dix fois plus vite pour des petites recherches, voire en dessous de la seconde au lieu de plusieurs minutes, sur de longues périodes. (NDLA : tout dépend du type de données, de la plage de date, et de la complexité de la recherche, mais le gain sera toujours notable).
Pourquoi ne pas utiliser tstats partout
Dans les exemples ci-dessus, vous aurez noté l’utilisation exclusive de champs en rapport aux metadata : host, source, sourcetype. À quoi on peut ajouter les champs de date : _time et autres date_hour, date_mday, date_year … et l’index contenant les données.
La commande tstats ne peut fonctionner qu’en sollicitant des champs indexés. Et seuls les champs de metadata sont indexés par défaut. On les appelle aussi les metachamps ou metafields.
Donc, dans son comportement par défaut, tstats ne peut pas être utilisé avec toutes les données. Pour autant, on peut sous certaines conditions et avec de bonnes précautions indexer les champs. On appelle cela Indexed Field Extraction.
Rappel sur le modèle de Splunk – Extraction des champs à la volée :
L’association d’un champ et de sa valeur permettent d’affiner les résultats des recherches. Adresse IP, nom d’utilisateur, numéro de port, URI, code d’erreur … sont définis par les sourcetypes. Les sourcetypes intégrés par défaut, ou bundled / pretrained utilisent principalement des expressions régulières pour reconnaître, identifier, et nommer ces objets : src, username, port, status en fonction de leur syntaxe, ou de leur position au sein d’un évènement.
Quand on débute sur Splunk, il est courant de croire que tous les champs sont indexés, et que lors de la recherche, on ne fait que piocher dans un lexique exhaustif. En réalité, et sauf exception, les champs sont extraits à la volée, au moment de la recherche et seules les metafields : host, source, sourcetype sont inscrites nommément dans ce lexique.
Les sourcetypes prédéfinis (plus d’une centaine) suivent aussi ce Schema On The Fly : les champs ne sont pas indexés, ils sont extraits au moment de la recherche.
Si un champ n’est pas indexé, il ne peut pas être utilisé dans la commande tstats. Les exemples suivants ne renverront aucun résultat : 👎
| tstats max(status) where index=web by host |
| tstats count where index=security by src |
| tstats sum(price) where index=web by product_name |
Comment Indexer des champs et profiter de tstats
Certains types de données seront naturellement identifiés par les Forwardeurs (NDLA : pour différencier rôle et action, l’auteur a choisi cette formulation : les Forwardeurs forwardent et les Indexeurs indexent. Mais le terme officiel est bien Forwarders et Indexers).
Ces exceptions sont documentées ici et concernent les données de type CSV, W3C, TSV, PSV, JSON et HEC.
Si une source de données est identifiée naturellement, ou choisie par l’administrateur de données comme relevant de l’un de ces types, alors tous les champs seront indexés. Et ils pourront tous être utilisés efficacement avec tstats. 👍
Pour les autres données, il est possible depuis l’Indexeur, au niveau de la phase de parsing, d’adapter le sourcetype dans le fichier props.conf pour nommer tel ou tel champ à indexer.
Dans les deux cas, Splunk ne recommande pas l’extraction des champs lors de la phase d’indexation, pour des raisons de performance et de coût.
Le véritable coût des champs indexés
Le modèle de Splunk est de réduire l’empreinte de stockage des indexes et de profiter des ressources CPU et Mémoire du Search Head et des Indexeurs lors de la recherche. Ces machines sont dédiées à ces fonctions, et dimensionnées d’après vos besoins.
1. Quand on décide d’utiliser les formats CSV ou JSON pour indexer les champs, on notera un impact négatif à trois niveaux :
- CPU et Mémoire du Forwardeur ;
- Trafic réseau entre le Forwardeur et l’Indexeur ;
- Consommation du Stockage de l’Indexeur.
Comme le Forwardeur est souvent le serveur applicatif de production, il n’est pas souhaitable de le pénaliser en redirigeant ses ressources vers le client Splunk.
2. Si on modifie la configuration props.conf au niveau de l’Indexeur pour ne traiter l’indexation de champs que ponctuellement, l’impact ne sera quasiment que sur le stockage.
Mais on trouve souvent un Heavy Forwardeur entre la source des données et les Indexeurs. Même si une machine est dédiée à ce rôle, il restera à transférer jusqu’aux Indexeurs, et on retombera sur un trafic réseau accru.
L’impact sur les ressources systèmes et le trafic réseau seront évidents, mais ce qui est immédiat à considérer est l’impact sur le stockage.
Pour une source au format JSON, l’empreinte sur le stockage s’étend de x2 à x8 quand on indexe les champs
3. L’impact sur la licence sera nul ou infime dans tous les cas, le contenu de l’événement brut indexé n’étant pas modifié.
🤓 Le coin de l’expert 🤓
Si on regarde le contenu de l’index en détail, on se souvient que les données brutes sont stockées dans un fichier compressé journal.gz occupant peu ou prou 15% de la taille des données d’origine, les fichiers tsidx (le lexique et les metadata) représentant 35%. Soit une empreinte moyenne de 50%, en dehors de toute réplication.
Quand on indexe les champs, ce sont les fichiers tsidx qui vont être gonflés, et en plus grand nombre.
L’impact se ressent alors sur la totalité de l’index : toutes ces données supplémentaires étant conservées aussi longtemps que le reste, et subissant aussi la réplication d’un cluster.
L’alternative aux champs indexés : l’accélération
Un prochain article parlera des 3 types d’accélération disponibles pour améliorer les performances de recherche sans impacter le stockage, mais celle qui nous intéresse immédiatement ici, c’est l’accélération des modèles de données ! (Datamodel Acceleration).
En créant un modèle de données, un Administrateur ou un Power User peut y inclure tous les champs qu’il veut.
En partageant puis en accélérant ce modèle de données, ces champs deviennent des champs indexés !
Ils sont alors disponibles pour la commande tstats, aussi efficacement que si on avait utilisé l’extraction des champs à l’indexation.
La grande différence est que vous gardez le contrôle :
- Sur les champs qui vous intéressent ;
- Sur la rétention, ou durée de l’accélération.
Une petite gymnastique sera nécessaire pour utiliser pleinement tstats.
Ici le modèle Buttercup_Games_Online_Sales porteur du jeu de données http_request présente des champs price et categoryId qui ne peuvent être utilisés par tstats que si l’accélération a été activée
| tstats sum(http_request.price) from datamodel=Buttercup_Games_Online_Sales where nodename=http_request by http_request.categoryId summariesonly=true |
Comparé à :
sourcetype=access_combined source="*access.log" | stats sum(price) by categoryId
le temps de recherche sur 12 mois est tombé de 0,9s à 0,05s. Même si cela n’est qu’un environnement de test, je pense que vous voudrez l’essayer sur vos propres données.
***
Le service Splunk Education se tient à votre disposition pour toute question supplémentaire et vous accompagne tout au long de votre progression dans l’apprentissage de la solution Splunk.
L’extraction des champs, les sourcetypes et la création des outils de connaissances sont abordés dans les formations Fundamentals 2, Data Administration, Advanced Searching and Reporting. D’ailleurs, si vous ne l’avez pas encore fait, je vous invite à consulter mon article qui fait le point sur la formation Splunk !
À bientôt
