Splunk joue les cartes observabilité et data science

Splunk Enterprise fait peau neuve pour le cloud

Le système de gestion des métriques a également été revu. Il est maintenant possible « d’agréger plus de deux millions d’événements par seconde », assure l’éditeur.

Surtout, Splunk introduit en bêta un opérateur Kubernetes open source pour déployer et gérer Splunk Enterprise depuis des containers en cloud privé ou public. L’opérateur est compatible avec AWS, GCP, Azure et OpenShift.

L’éditeur privilégie désormais Splunk Cloud et assure qu’il a largement refactorisé ses composants et ses logiciels pour supporter ce changement. « Notre offre Splunk cloud n’était pas cloud native au départ. Et nous avons investi massivement pour mener à bien la dernière étape de ce voyage. Je suis fier de dire que nous avons presque terminé », vante Sendur Sellakumar, Chief Product Officer auprès du MagIT. Pendant la conférence, le responsable a expliqué que 30 % du code de Splunk cloud (Splunk Enterprise donc) avait été modifié en douze mois.

L’entreprise a aussi présenté la nouvelle version de Data Stream Processing (DSP), sa distribution d’un service de streaming de données basées sur les projets open source Apache Kafka, Flink et Pulsar, entre autres, et permet de se connecter aux services AWS, Google Pub/Sub ou encore Azure Event Hub. DSP 1.2 vient améliorer le système intégré pour filtrer les métriques, les traces et les logs les plus pertinents, enrichir les données grâce à des algorithmes de machine learning tout en réduisant le temps de recherche, vante Tim Tully, le CTO de Splunk.

Splunk Cloud s’ouvre aux data scientists

S’il utilise des algorithmes au sein de ses logiciels depuis quelques années, l’éditeur veut aller plus loin en fournissant aux métiers des modèles intégrés. Pour les professionnels de l’IT, Splunk ITSI offre des fonctionnalités AIOps pour détecter les anomalies et prévenir les responsables en cas de problème. Un module d’analyse prédictive est déjà intégré dans ce produit. Pour les utilisateurs de SAP, Splunk annonce des solutions Service Intelligence for SAP. Il s’agit d’une version, semble-t-il, adaptée de Splunk ITSI, dédié aux infrastructures de l’éditeur allemand de solutions ERP.

Certains modèles d’apprentissage statistique embarqués dans Splunk bénéficient d’un apprentissage par renforcement, ce qui doit permettre leur amélioration en continu. Pour les responsables IT, les DevOps, SecOps et SRE, ils sont manipulables en glisser-déposer, mais portent toujours leurs noms scientifiques : par exemple, l’« adaptive tresholding » désigne la détection d’anomalies.

Plus surprenant, Tim Tully a présenté SMLE (Splunk Machine Learning Environnment – à prononcer smile), un environnement de data science dédiée, disponible en bêta dans Splunk Cloud. Il permet de concevoir des algorithmes en tirant les données ingérées dans Splunk via des notebooks Jupyter. Les modèles peuvent être développés en R, Python, Scala et SPL. SMLE propose des moyens de déployer et de gérer les modèles entraînés sur les données de télémétrie.

« Nous proposions déjà un kit d’outils pour les utilisateurs avancés dans Splunk Cloud », précise Sendur Sellakumar.

Les concurrents comme Dynatrace, New Relic ou Datadog ont fait le choix de cacher cette forme de complexité aux utilisateurs. Splunk veut à la fois proposer des modèles sur étagères et rapprocher les équipes de data science des métiers, selon Sendur Sellakumar.

« Nous voulons soutenir ces clients qui vont continuer à adapter et à faire évoluer leurs modèles et à s’améliorer, ainsi que ceux qui utilisent nos modèles en libre-service. »

« Certains de nos clients sont au début de leur parcours avec le machine learning et ils veulent la facilité d’utilisation, dont nous avons parlé. Et il y a aussi un ensemble de clients comme une grande compagnie d’assurance qui exécute aujourd’hui ses systèmes sur le cloud. Elle a des data scientists dans ses équipes de sécurité et SOCs. Ils construisent leurs propres modèles de détection. Et ils disent : “Hé, je veux pouvoir appliquer mon modèle de détection dans le moteur que Splunk exécute”. Nous voulons soutenir ces clients qui vont continuer à adapter et à faire évoluer leurs modèles et à s’améliorer, ainsi que ceux qui utilisent nos modèles en libre-service », déclare-t-il.

Splunk a lui aussi sa suite dédiée à l’observabilité

L’éditeur a également mis l’accent sur un volet affectionné par ses concurrents : l’observabilité. Il s’était investi dans cette voie l’année dernière en acquérant SignalFX et Omnition. À l’occasion de .conf20, Splunk a lancé Observability Suite, une suite de produits basés sur le socle Splunk Cloud (ou Splunk Enterprise sur site) qui comprend Splunk Infrastructure Monitoring, APM, Real User Monitoring (RUM), Log Observer et On-Call. L’éditeur rassemble ici des produits existants et complète son catalogue avec Real User Monitoring et Log Observer. Splunk entend rassembler les vues disponibles dans ces différents outils au sein d’une seule interface visuelle.

Log Observer est un outil pour l’investigation de logs disponible en bêta cet hiver. L’outil sert à consulter les données de différentes sources comme Kubernetes, Fluentd ou encore des services AWS. L’interface doit permettre de consulter des précisions sur les logs en cliquant dessus. Splunk propose une fonctionnalité nommée Live Tail. Celle-ci doit faciliter le filtrage des différents logs par les SRE et les équipes DevOps afin d’accéder aux informations dites critiques. Par ailleurs, « Splunk Log Explorer est conçu de manière à ce qu’un attribut d’une trace, qu’il s’agisse d’un ID de trace spécifique ou d’un paramètre d’une balise, devienne un filtre permettant de supprimer les étapes superflues de l’exploration », promet l’éditeur sur son site web.

Également en bêta, RUM est une extension de Splunk Application Monitoring, conçue pour analyser les expériences des utilisateurs. La collecte des données est basée sur OpenTelemetry (l’éditeur prévoit des ajustements pour mieux supporter le protocole), de l’ingestion certifiée temps réel.

L’éditeur entend offrir un portefeuille « robuste » de solutions APM, des fonctionnalités qui sont encore jeunes dans son portfolio. En ce sens, Splunk a annoncé son intention d’acquérir Plumbr, un spécialiste de l’APM et de l’instrumentation de bytecode. « Plumbr, c’est vraiment la chance pour nos clients de bénéficier du Java Profiling et de la BCI (Bytecode Instrumentation), ce qui est indispensable pour avoir le bon niveau de visibilité sur les applications Java et .NET », promet Tim Tully.

L’acquisition de Rigor, elle, doit permettre d’améliorer cette supervision des usages des utilisateurs. Rigor est spécialisé dans le monitoring des synthétiques, le fait de simuler des actions pour observer leur conséquence sur les applications d’une entreprise.

Travaux en cours

Toutefois, la peinture de l’Observability Suite est encore très fraîche : deux produits sont en bêta et la tarification n’est pas totalement établie. « Pour clarifier tout ça, nous allons faire deux choses. La première c’est que chacun des produits peut dépendre d’une souscription séparée via un modèle de tarification par hôte, ou suivant l’utilisation, tout en fournissant un outil de contrôle de la consommation. La deuxième, c’est que nous avons l’intention de consolider tous les produits et proposer en parallèle une tarification unique pour la suite d’outils », indique Sendur Sellakumar.

« Nous sommes convaincus que la tarification au workload est la réponse pour permettre un modèle de tarification beaucoup plus transparent et plus efficace pour nos clients. »

Ce modèle tarifaire unifié sera sans doute basé sur l’achat de capacités à consommer en fonction des usages, selon le Chief Product Officer.

« Nous examinons cette dynamique, nous nous basons sur les commentaires des clients et nous ajusterons certains éléments en fonction », promet-il.

L’année dernière, Splunk avait revu la tarification de ses produits SaaS sur site et Splunk Cloud. L’éditeur a également introduit une tarification basée sur les workloads, principalement fondée sur les requêtes, les exécutions des modèles de machine learning et sur la consommation de l’infrastructure. Les clients s’étaient plaints des coûts entraînés par le précédent modèle basé sur l’ingestion de données.

« Je ne dirais pas que 100 % de nos clients sont satisfaits. On ne connaît jamais toutes les situations. Mais nous sommes convaincus que la tarification au workload est la réponse pour permettre un modèle de tarification beaucoup plus transparent et plus efficace pour nos clients. Et je pense que nos prix sont très compétitifs » vante Sendur Sellakumar.