.conf19 : Splunk propose du monitoring qui fonctionne... sans Splunk
Les modules Data Stream Processor et Data Fabric Search traitent respectivement des données qui sont produites dans des succursales ou hébergées dans sur un cluster comme Hadoop.
L’éditeur Splunk, spécialiste des solutions de monitoring pour datacenters et SOCs, lance deux modules qui fonctionnent en marge de Splunk Enterprise, sa plateforme centrale.
Le premier, Data Stream Processor (DSP) et un module inédit d’Edge Computing qui s’exécute de manière autonome. Le second, Data Fabric Search (DFS), croise des données qui sont - ou pas - indexées par Splunk Enterprise. DFS peut en l’occurrence aller puiser des informations sur des clusters Hadoop, des volumes de stockage objet S3, ou d’autres sources de données à l’avenir.
« Afficher ensemble des métriques éparpillées sur plusieurs instances Splunk était une demande de nos clients internationaux, qui disposent d’un Splunk Enterprise par continent, pour monitorer leurs antennes locales, mais qui souhaitent avoir une vue globale de leurs activités », explique au MagIT Jeff Schultz, en charge du marketing produits chez Splunk, lors de l’événement annuel .conf19, que l’éditeur vient d’organiser à Las Vegas.
Agréger les résultats de requêtes traitées ailleurs
Sur scène, Jon Prall, responsable de l’ingénierie chez Verizon Media témoigne avoir utilisé DFS pour obtenir en quelques minutes des renseignements opérationnels à partir de milliards d’événements dispersés sur plusieurs instances de Splunk Enterprise. « Il est possible de lancer des requêtes optimisées, à dimensions variables, qui nous évitent de passer des heures à chercher sur chaque déploiement Splunk où se trouvent les problèmes et comment y répondre », dit-il, en précisant que le temps gagné en dépannage permet à ses équipes de mieux se consacrer aux développements de produits innovants.
« DFS, n’indexe pas lui-même les données, mais communique ses requêtes aux entrepôts de données qui, eux-mêmes, calculent le résultat local de la requête. »
Jeff SchultzEn charge du marketing produits, Splunk
Concernant la corrélation avec des données tierces non indexées, il s’agit surtout d’un effet du moteur de DFS. « DFS, n’indexe pas lui-même les données, mais communique ses requêtes aux entrepôts de données qui, eux-mêmes, calculent le résultat local de la requête. DFS ne fait qu’agréger ces résultats », ajoute Jeff Schultz.
Pour l’heure, outre savoir envoyer des commandes SPL à des instances Splunk, DFS a la capacité de piloter des nœuds Apache Spark. La fonction de rapatriement de données depuis des volumes S3 serait quant à elle encore en version beta.
Filtrer les données à la source avant de les analyser
Data Stream Processor est encore plus Indépendant de Splunk, puisqu’il peut tout à fait fonctionner sans, un peu à la manière de Xi IoT chez Nutanix.
« DSP sert à filtrer les métriques sur le lieu où elles sont produites afin de n’envoyer que l’essentiel au moteur qui va les analyser, lequel peut être Splunk Enterprise ou tout autre plateforme d’analytique », résume encore Jeff Schultz.
« DSP sera typiquement utilisé pour ne pas transférer tout ce qui a trait aux informations personnelles dans le cadre du RGPD, ou pour détecter, via un moteur de statistiques tiers, les signes précurseurs d’un problème. Il enverra dans ce cas immédiatement une alerte à un responsable ou déclenchera en temps réel un processus de dépannage. »
Ces deux modules devraient à terme bénéficier des travaux de Streamlio, une startup que Splunk a rachetée la veille de l’ouverture de son événement .conf19. A l’initiative de la plateforme Open source Apache Pulsar, qui sert à envoyer des messages entre serveurs, l’équipe de Streamlio a mis au point une plateforme commerciale éponyme qui sert plus précisément à envoyer des métriques en temps réel.
