2 juin 2016

La dernière version de Splunk Enterprise, sortie en avril, apporte des nouveautés intéressantes tant du côté de son utilisation – nouvelles visualisations, nouvelles possibilités de recherche – que sur son fonctionnement – optimisation drastique du stockage notamment. Passons certaines d’entre elles en revue !

Les nouvelles visualisations

 

Le changement le plus spectaculaire concerne les visualisations. Jusqu’à présent, les visualisations officielles étaient intégrées à l’interface et il fallait passer par l’installation d’Apps tierces pour utiliser des formes plus avancées proposées sur Splunkbase.

 

Comme c’est souvent le cas avec Splunk, les meilleures Apps, qu’elles soient développées par la communauté Splunk ou par l’éditeur lui-même, finissent par être intégrées à l’interface Web. Ce fut par exemple le cas pour Splunk on Splunk (S.o.S), l’App qui apportait de la visibilité sur les composants Splunk et qui a été remplacée par la Distributed Management Console (DMC) en WebUI. Universal Field Extractor et PDF Report Server App en sont d’autres exemples.

 

Judicieusement, ce schéma semble se reproduire avec les nouvelles visualisations proposées en 6.4 puisque certaines d’entre elles – comme le diagramme de Sankey par exemple – semblent avoir été adaptées d’Apps populaires développées par des contributeurs.

 

 

En tout, Splunk a annoncé 15 nouvelles visualisations officielles.

 

timeline bullet_graph calendar_heatmap horizon_chart horseshoe_meter location_tracker treemap parallel_coordinates punchcard sankey status_indicator

 

Parmi celles-ci, on retrouve donc le diagramme de Sankey, mais aussi les coordonnées parallèles, la frise chronologique et le suivi de localisation. Surtout, ces visualisations sont à présent publiées sur Splunkbase et non plus directement intégrées à Splunk : il faut donc les télécharger puis les installer avant de pouvoir en tirer parti dans la WebUI.

 

more2

 

4 nouvelles visualisations officielles devraient être publiées prochainement.

D’autres sont d’ores et déjà proposées par la communauté grâce à l’ouverture du framework pour les visualisations customisées.

Reste à trouver des cas d’usage ! Pour faciliter leur utilisation, une aide sur la commande est proposée en regard de chacune.

Le post-traitement récursif

 

Qu’on installe une App ou qu’on la développe soi-même, on se rend rapidement compte qu’un même dashboard peut contenir de nombreuses recherches. À partir d’un certain seuil, il est impossible pour Splunk de lancer toutes ces recherches en même temps, celles-ci sont alors mises en file d’attente et exécutées progressivement, au détriment de l’expérience utilisateur :

 
code1
 

Une manière très efficace pour éviter cet écueil est d’utiliser le post-traitement des recherches : le dashboard contient une recherche de base sur laquelle s’appuient toutes les autres ce qui réduit considérablement le temps de traitement, puisqu’une seule recherche, au sens de tâche, est exécutée lors du chargement du dashboard :

 

code2

 

Cette fonctionnalité, introduite en version 6.0, a été améliorée en 6.2 avec la possibilité d’utiliser plusieurs recherches de base :

 
code3
 

Avec cette version 6.4, il est dorénavant possible de baser une recherche sur le résultat d’une précédente recherche elle-même basée sur une recherche de base :

 
code4

L’échantillonnage d’événements

 

Généralement, lorsque l’on construit un recherche Splunk, on commence par tester celle-ci sur une courte période de temps – les dernières heures – pour aller plus vite. Or, si l’on cherche à établir une tendance, il faut inévitablement allonger cette période et donc le temps de recherche. À présent, il est possible d’échantillonner les résultats : la recherche porte sur un échantillon Evènements aléatoires – 1/10, 1/100 ou 1/1000 – sélectionnés de manière aléatoire ce qui permet d’obtenir très rapidement une tendance relativement fidèle au jeu de données :

 
sampling
 

Au vu des gains de temps réalisés sur cet exemple, on peut très bien imaginer embarquer ce mécanisme dans un dashboard pour accélérer les recherches de tendances portant sur un volume important de données, ce qu’il est possible de faire grâce à l’objet <sampleRatio>100</sampleRatio>

L’indexation des alertes

 

Lorsqu’on utilise les alertes Splunk, plusieurs actions sont possibles. Le plus souvent, on choisit de les envoyer par mail et qu’elles soient générées dans Splunk. D’autres actions sont possibles : l’envoi vers un outil de ticketing ou le déclenchement d’un script.

Or, si l’on souhaite avoir de la visibilité sur ces alertes à travers, par exemple, un dashboard indiquant le nombre d’alertes générées par niveau de criticité, il faut baser les recherches sur les logs d’audit :

 

index=_audit action=alert_fired ss_app=<app_name> …

alerts
 

Cela permet déjà de faire des recherches intéressantes. Reste que cet index n’a pas vocation à être ouvert à tous les utilisateurs.

L’App Alert Manager, qui vient tout juste d’obtenir le statut d’App certifiée, et est dédiée, justement, aux alertes, indexe les métadonnées des alertes dans un index pour travailler ensuite dessus.

Dans cette version 6.4, Splunk intègre ce principe et il est donc désormais possible d’indexer les alertes déclenchées et de jouer avec les tokens pour customiser les événements.

Réduire la durée de rétention des fichiers d’index

 

Une des importantes nouveautés de cette version 6.4 est la possibilité d’optimiser le stockage en gérant la durée de rétention des fichiers d’index. Un fichier d’index ou fichier tsidx – pour time-series index file – associe chaque mot-clé contenu dans les données aux informations sur l’emplacement des évènements stockés en données brutes. Ensembles, données brutes et tsidx correspondants forment le contenu d’un bucket.

Si ces fichiers sont essentiels pour que les recherches sur des volumes de données importants soient efficaces, ils prennent aussi beaucoup de place. Or, si l’essentiel de vos recherches portent sur des données récemment indexées, vous pouvez vous passer de ces fichiers d’index pour les données les plus anciennes. De cette manière, les recherches occasionnelles sur des données anciennes seront plus lentes, mais il est possible réaliser entre 40 et 80 % d’économies sur le stockage.

 
tsidx
 

Voilà pour un tour d’horizon des principales nouveautés de la 6.4. Il y en a d’autres, n’hésitez pas à installer l’App Splunk 6.4 Overview pour les découvrir ou à nous contacter pour toute question sur la solution Splunk !

Partager :

Auteurs