OpenTelemetry, optimisation des coûts : les arguments d’Elastic face à ses rivaux
Lors de son événement ElasticON Paris, Elastic a présenté en long, en large et en travers, ses avancées en matière de recherche vectorielle et sémantique. Or, la plupart des clients regardent davantage la manière dont l’éditeur compresse les logs et renforce sa prise en charge d’OpenTelemetry.
« Search is back! ». Tel est le constat fait par Shay Banon, fondateur et CTO d’Elastic après avoir mesuré les effets de l’IA générative sur l’évolution des fonctionnalités d’Elasticsearch. Et de présenter le SGBD NoSQL comme un socle idéal pour la recherche vectorielle et les architectures RAG.
Pour autant, il est clair que la majorité des clients présents regardaient ailleurs. De fait, les solutions Elasticsearch, Logstach et Kibana ont pris de l’ampleur dans les domaines voisins du monitoring et de la cybersécurité.
Une partie des préoccupations des clients de ces solutions d’observabilité et de SIEM sont représentées dans la note de mise à jour d’Elasticsearch 8.15, lancé en août.
Cette version inclut un collecteur OpenTelemetry. Il a émergé après la donation de l’Elastic Common Schema (ECS), une méthode pour collecter les métriques et les traces, ainsi que d’Universal Profiling au projet OpenTelemetry.
« Nous cherchons également à améliorer la collecte de logs au sein d’OpenTelemetry », affirme Shay Banon.
Les directions informatiques apprécient ce framework, car il doit permettre à la fois de standardiser l’ingestion de logs et, surtout, offrir un levier contre l’enfermement propriétaire.
Elastic est né dans l’écosystème open source. Pour autant, sa confrontation avec AWS l’a amené à « privatiser » Elasticsearch, avant un retour à une licence certes open source (AGPLv3), mais plus restrictive que celle précédemment utilisée (Apache 2.0).
Le directeur technique se dit très heureux de ce revirement et présente Elastic comme un des contributeurs majeurs à OpenTelemetry.
OpenTelemetry : Elastic en fait un argument de lutte contre ses compétiteurs
Le tableau des contributions tenues par OpenTelemetry et la CNCF prouve les dires du dirigeant, mais l’éditeur est devancé par un compétiteur. Au cours des trois dernières années, quand Elasticsearch inc. a réalisé 28 789 contributions, Splunk en a effectué 153 366. Cela dit, 23 979 des contributions réalisées par les employés et la communauté de l’éditeur ont été effectuées au cours des douze derniers mois. Ce qui fait d’Elastic le troisième plus gros contributeur à OpenTelemetry, derrière Splunk (le numéro 1) et Microsoft en 2024.
« Nous croyons que la collecte des données doit être ouverte et open source. »
Shay BanonFondateur et CTO, Elastic
« Nous croyons que la collecte des données doit être ouverte et open source », affirme Shay Banon. « La raison pour laquelle nous investissons fortement dans ce domaine, c’est que nous pensons que la plupart des bénéfices que l’on peut tirer des données sont obtenus lorsqu’on les place dans Elasticsearch », ajoute-t-il, sourire aux lèvres.
« D’autres éditeurs investissent dans OpenTelemetry, ce qui est louable, mais je dirais qu’ils n’investissent pas pleinement dans le projet [car] la majorité de leur activité réside dans la collecte des données ».
Elastic souhaite ainsi rivaliser avec Microsoft (Azure Sentinel) et Splunk non pas sur l’ingestion de données, mais sur leur stockage et leur analyse.
Pour convertir les entreprises vers ses offres d’observabilité et SIEM, l’éditeur doit montrer patte blanche en réduisant les coûts de stockage.
Compresser les données et les coûts de stockage
« Mon équipe aide les clients à contrôler leurs coûts en les informant sur le “right sizing”, la structure des clusters, les politiques de rétentions possibles, etc. »
Bahaaldine « Baha » AzarmiV-P global ingénierie client, Elastic
« Peu importe l’éditeur de logiciels, les clients veulent de plus en plus contrôler leur coût total de possession », affirme Bahaaldine « Baha » Azarmi, vice-président global de l’ingénierie client. « Les directeurs financiers regardent les lignes de dépenses liées aux services SaaS et nous, nous n’avons pas envie d’être en haut de la liste », ajoute-t-il.
« Quand vous migrez d’une version à une autre, il y a toujours une optimisation, toujours », assure-t-il. « Et mon équipe aide les clients à contrôler leurs coûts en les informant sur le “right sizing”, la structure des clusters, les politiques de rétentions possibles, etc. »
Elastic privilégierait ainsi la relation à long terme avec ses clients. Pour autant, les volumes de logs ne font qu’augmenter. Et les coûts qui vont avec.
« En 2015, lorsque j’ai rejoint Elastic, un cas d’usage impliquant la collecte de 100 Go de logs par jour était important. Deux ans plus tard, les clients nous parlaient d’un téraoctet. Aujourd’hui, c’est une moyenne basse. Et certains gèrent avec nous des pétaoctets de données », note Baha Azarmi.
Selon l’éditeur, une partie de la solution se trouve dans les tiers de stockage, une autre dans la compression de données.
Avec sa version 8.17, Elastic a annoncé à la mi-décembre la disponibilité générale du mode Logsdb Index. Celui-ci permettrait de diviser l’empreinte de stockage par trois par rapport à l’index par défaut.
Ce mode combine plusieurs techniques. Deux d’entre elles sont désormais de plus en plus répandues dans les systèmes de gestion de données.
La première consiste en l’adoption d’une technique d’indexation « intelligente » en plaçant les données similaires à proximité des unes des autres. Ici, les logs au sein d’un index sont triés par nom d’hôte et par horodatage, en ordre décroissant. De fait, Apache Lucene (la technologie servant de fondation à Elasticsearch) ne contient pas de fonctions de tri dans les index.
La deuxième technique consiste en l’implémentation de l’algorithme de compression ZSTD, en sus de codecs de compression des champs numériques. ZSTD ou Zstandard est un algorithme open source développé en 2015 par Yann Collet, expert en compression de données chez Facebook. Celui-ci a été conçu en vue de trouver un équilibre entre vitesse et ratio de compression de données collectées en presque temps réel. ZTSD est utilisé par bon nombre d’éditeurs, dont IBM, MongoDB, Splunk, ou encore Datadog.
Enfin, une troisième technique (nommée « synthetic source ») consiste à omettre le champ _source original, mais à le synthétiser à partir des valeurs ou des champs stockés lors de la récupération de documents. « Elasticsearch est une base de données orientée documents. Ce mode revient à y ajouter des fonctions de stockage en colonne », résume Shay Banon. « La mise en œuvre de cette fonctionnalité a nécessité un investissement considérable d’environ un an et demi », ajoute-t-il.
Bien que l’implémentation elle-même n’ait pas été particulièrement complexe, le véritable défi aurait été de garantir son fonctionnement de manière transparente au niveau de la couche de sortie des données. « Que les données soient stockées sous forme documentaire ou en format colonnaire, le système conserve les mêmes avantages en matière de compression tout en maintenant une compatibilité totale avec les API existantes », assure le CTO d’Elastic. « Maintenir la rétrocompatibilité dans cet environnement a été la partie la plus difficile du processus ».
Des gains à justifier
Il y a toutefois un contrecoup (coût ?) à cette approche : l’indexation et la compression des données sont plus gourmandes en ressources de calcul.
De plus, l’accès au mode Logsdb est compartimenté. « Les fonctionnalités logsdb de base (notamment le tri intelligent des index et la compression avancée) sont disponibles pour les organisations disposant de licences Standard, Gold et Platinum », précise l’éditeur. « Les fonctionnalités qui réduisent davantage les besoins en stockage (y compris synthetic_source) sont disponibles pour les clients serverless et les organisations disposant d’une licence Enterprise ».
Ce n’est pas un problème, selon Elastic. « Pour les clients qui ont besoin d’une rétention à long terme, nous prévoyons des réductions du coût total de possession (TCO) pouvant aller jusqu’à 50 % », écrivent les porte-parole de l’éditeur dans un billet de blog. Un argument supplémentaire pour tenter de retenir les clients sur le cloud.
Ces gains s’expliqueraient aussi par la suppression de tâches manuelles. Auparavant, les ingénieurs chargés de la gestion des clusters Elasticsearch menaient ces opérations d’optimisation de leur côté. Il faut probablement compter sur la suppression de la gestion des tiers de stockage promise par Elastic Cloud Serverless.
Elastic mise sur son offre Serverless
Elastic table sur la croissance de cette offre « stateless », lancée en disponibilité générale le 2 décembre dernier. Elle est issue de la révision en profondeur de son architecture cloud. Après deux ans de travail et un programme de préversion, l’éditeur avance prudemment, selon Baha Azarmi.
« Nous avançons prudemment : nous ne sommes pas encore déployés sur tous les fournisseurs cloud. Sur AWS, nous couvrons déjà les principales régions mondiales essentielles, mais l’expansion se poursuit. »
Bahaaldine « Baha » AzarmiV-P globalingénierie client, Elastic
« Depuis que nous avons introduit Serverless, nous avons constaté une adoption immédiate, visible dans les courbes d’essais, et nous redirigeons une partie du trafic de tests vers cette nouvelle plateforme », indique-t-il. « Cela montre un réel engouement, mais c’est encore très nouveau pour nous. Nous avançons prudemment : nous ne sommes pas encore déployés sur tous les fournisseurs cloud », illustre-t-il. « Sur AWS, nous couvrons déjà les principales régions mondiales essentielles, mais l’expansion se poursuit. La semaine dernière, nous avons lancé une préversion sur Azure, ce qui est une avancée notable ».
Elastic a promu de longue date des distributions Self-managed et SaaS. Cette diversité est synonyme de déploiements cloud, sur site et hybride. Or 46 % de son chiffre d’affaires au deuxième trimestre fiscal 2025 provenait du cloud. Cela représente 169 millions de dollars sur un total de 365 millions de dollars. Ses « revenus cloud » ont crû de 25 % entre le Q2 2025, terminé le 31 octobre 2024, et le Q2 2024.
En juin 2024, dans le Magic Quadrant consacré à l’observabilité, les analystes de Gartner constataient que « contrairement à d’autres fournisseurs sur ce marché, Elastic base son modèle de tarification sur les ressources informatiques ».
« Bien qu’Elastic propose un calculateur de prix, la comparaison lors de l’approvisionnement ou de l’examen, et lors de la prévision des coûts et des budgets, peut s’avérer difficile », signalaient-ils.
Elastic Cloud Serverless ne change pas la donne. Elastic facture à la consommation de VCU – des unités de calculs virtualisés – par heure et au volume de gigaoctet ingéré et stocké. Un coût s’applique également à la recherche, à l’activation des modèles de machine learning… et à la sortie des données (egress).