Datadog gonfle ses fonctionnalités, mais ne cède pas aux sirènes de l’AIOps

Datadog profite de sa conférence Dash 2020 pour annoncer cinq produits afin de compléter son offre d’observabilité. L’éditeur new-yorkais préfère miser sur l’observabilité de bout en bout plutôt que de sortir les cartes de l’AIOps et de l’autoremédiation.

Datadog, éditeur new-yorkais fondé en 2010 par des Français passés via Centrale Paris, a rapidement gagné ses lettres de noblesse sur le marché de l’observabilité. Il revendique aujourd’hui plus de 12 000 clients.

Suite de l'article ci-dessous

Après un produit consacré au monitoring des infrastructures cloud natives en 2012, il enchaîne depuis 2016 les acquisitions et les lancements de produits consacrés aux APM, à la gestion de logs et au monitoring de la sécurité. « Dès notre lancement, nous nous sommes évertués à briser les silos qui séparent les différentes équipes Dev et Ops », affirme Amit Agarwal, Chief Product Officer chez Datadog.

Dans cette droite lignée, l’éditeur profite de sa conférence annuelle (virtuelle évidemment) Dash 2020 pour annoncer cinq nouveaux modules. Le premier d’entre eux se nomme Datadog Continuous Profiler, en disponibilité générale depuis ce mardi. Il s’agit d’un outil de code profiling, conçu pour fonctionner continuellement en production.

« Les profileurs traditionnels ne sont pas ou peu utilisés en production à cause de leur impact sur les performances des systèmes et ne sont donc pas actifs en continu. Datadog Continuous Profiler consomme moins de 3 % de ressources CPU et n’ajoute pas de latence sur les transactions », assure Renaud Boutet, Vice-Président Produit chez Datadog.

 « Dès notre lancement, nous nous sommes évertués à briser les silos qui séparent les différentes équipes Dev et Ops. »
Amit AgarwalChief Product Officer, Datadog

 Continuous Profiler supporte des langages de programmation comme Ruby, .Net, Go, Java, Php, NodeJS et Python. Il doit signaler les problèmes au niveau d’une seule ligne de code. Les cas d’usage sont variés, mais Renaud Boutet insiste sur les capacités du profileur à détecter les deadlocks, des états où les ressources qui devraient être partagées dans un système distribué (à base de multithread) ne le sont plus parce que mises en attente.

Le responsable évoque également la détection de problème lié au blocking IO, c’est-à-dire la mise en attente de données en lecture et en écriture dans une mémoire tampon. L’outil surveille aussi la consommation de mémoire, de ressources CPU et les collecteurs de déchets.

Pour cela, Continuous Profiler doit analyser toutes les données en arrière-plan, à savoir les métriques, les traces, les logs et les processus applicatifs (APM). Si l’outil s’adresse en premier lieu à des connaisseurs du profiling, il doit également proposer des recommandations d’actions à prendre pour régler les problèmes ou en réduire les effets. Ces recommandations sont issues de « l’expertise de profiling » des ingénieurs chez Datadog.

Des outils pour faciliter la vie du SRE

Datadog Error Tracking, quant à lui, est un produit consacré à la détection d’erreurs affectant directement les utilisateurs d’une application. À cet effet, il utilise les données en provenance des outils de gestion de logs, de suivi APM et RUM (Real User Monitoring), l’outil de Datadog servant à monitorer les environnements frontends.

Habituellement, les DevOps et les Ops retrouvent les erreurs eux-mêmes et doivent effectuer des rapprochements sur des millions d’entrées et d’erreurs au niveau des logs, des métriques et des APM. Error Tracking fait de l’agrégation automatique de ces erreurs afin de fournir une vue d’ensemble d’un problème.

« Il est possible de voir quand un événement se produit et sous quelles conditions grâce à ces agrégations », explique Ilan Rabinovitch, Vice President Product & Community chez Datadog. Error Tracking fournit également des fonctionnalités pour suivre les types d’événements et recevoir des notifications sur PagerDuty et Slack. L’outil doit garder en mémoire ces erreurs et donc signaler les nouveaux problèmes potentiellement provoqués par un changement du code en production, ou inversement si ce changement est un succès.

Error Tracking est fourni dans RUM et le sera dans les produits Log Management et APM prochainement. Ainsi, l’agrégation des métriques, des logs et des APM n’est possible qu’en disposant des trois produits.

Pour l’instant, l’outil n’analyse que les erreurs des applications développées en JavaScript sur les environnements frontends, il permettra de faire la même chose sur les langages de programmation des applications mobiles iOS et Android (probablement Kotlin, Java, Swift, Objective C, etc.). L’analyse des problèmes issus des environnements back-end (codés en Go, Java,.NET, Php, NodeJS, Python et Ruby) suivra d’ici à la fin de l’année.

Troisième produit de cette liste, Datadog Incident Management. Si les deux autres visent à accélérer le temps de détection des erreurs et des problèmes, Incident Management doit simplifier la collaboration entre les membres d’une équipe afin de mieux gérer les incidents. Là encore, il s’agit de mettre à la disposition d’une équipe SRE toutes les données nécessaires à la résolution rapide d’un incident. Les équipes DevOps et SRE utilisent généralement des outils différents et n’ont souvent pas accès aux mêmes informations.

Concrètement, la bêta d’Incident Management rassemble un patchwork d’outils. En premier lieu, il comprend la fonctionnalité Incident Timeline, un tableau de bord pour visualiser toutes les activités et les signaux d’investigation liés à un incident. L’éditeur y ajoute une application mobile fraîchement terminée pour prévenir les membres en astreintes et les informer. Il a aussi développé un chatbot afin de faciliter la collaboration entre les équipes.

Celui-ci permet de créer un canal dédié Slack, lié à l’incident créé par un SRE, et de partager les premières informations sur l’incident via une URL vers la plateforme Datadog. Le SRE peut en amont former son équipe et désigner les personnes qui seront concernées par ce dernier.

Enfin les notebooks de Datadog ont été revus et corrigés pour accueillir plusieurs éditeurs afin de réaliser des postmortems à plusieurs mains. « Nous pensons que cela va réduire le volume de tâches répétitives et de coordination tout en accélérant les résolutions », déclare Ilan Rabinovitch.

La cybersécurité, l’attention du moment

Datadog s’est récemment lancé sur le marché de la cybersécurité. C’est d’ailleurs le dernier module qu’il a développé en avril 2020 sous l’appellation Datadog Security Monitoring. Lors de la Dash conference 2020, il présente Datadog Compliance Monitor, un outil conçu pour rapprocher les équipes DevOps, SecOps et GRC (Gouvernance Risque et Conformité).

Avec la migration vers le cloud et le développement de systèmes cloud natifs souvent complexes, la nécessité d’un tel rapprochement paraît évidente, « mais ces équipes n’évoluent pas aux mêmes rythmes », considère Renaud Boutet. La solution SIEM Data Security Monitoring vise déjà à offrir une visibilité complète des systèmes, la détection des menaces en temps réel (via des règles et l’analyse de logs) ainsi que la corrélation des problèmes suivant leur contexte.

« La mauvaise configuration des environnements cloud est la principale cause profonde des failles de sécurité en 2019 et 2020. »
Renaud BoutetVice-président Produit, Datadog

 La bêta de Datadog Compliance Monitor ajoute la possibilité de monitorer les configurations dans des environnements en production. « La mauvaise configuration des environnements cloud est la principale cause profonde des failles de sécurité en 2019 et 2020 », indique Renaud Boutet. « Si l’on exagère le trait, n’importe quel développeur peut lancer un environnement en production et potentiellement exposer des ressources critiques en quelques clics », ajoute-t-il.

Pour cela, Compliance Monitor ajoute deux tags. Le premier permet de tracer en quasi temps réel les états de beaucoup de ressources cloud. Il doit permettre de surveiller les fichiers de configuration Docker, Kubernetes, des hôtes et des containers. Le second doit effectuer un suivi des groupes de sécurité, les buckets de stockage type S3, l’activité des load balancers et les politiques des IAM.

Toutes ces informations sont rassemblées dans un historique pour les audits et doivent permettre de repérer les modifications légitimes et illégitimes des fichiers de configurations. L’outil fournit les tableaux de bord et un moteur de règles qui offre une compatibilité native avec les standards de conformité CIS, Soc2 et PCI DSS. De nouvelles règles peuvent être injectées par les utilisateurs et Datadog prévoit de supporter d’autres standards comme le RGPD. L’outil propose également des conseils de remédiations.

Enfin, Datadog lance une place de marché afin de faciliter l’intégration avec des outils et des services compatibles et surtout les monétiser. Au lancement, Fairwinds, TreK10, IOconnect Services et Rapdev proposent différentes offres pour simplifier le suivi et le déploiement de containers Kubernetes, favoriser les intégrations avec certains environnements comme Office 365.  

Chez Datadog l’unification passe avant autoremédiation

S’il s’agit de différents produits, l’éditeur évoque une « plateforme unifiée » en mode SaaS. Non pas parce qu’il veut seulement profiter des effets marketing d’une telle dénomination, mais parce que cela doit se vérifier techniquement.

La pile Datadog utilise plusieurs types de stockage et repose sur différents microservices, API, ainsi que sur une base de données Time Series. Mais c’est bien une plateforme d’injection et de monitoring de données temps réel, qui supporte les autres produits en principe étroitement intégrés avec cette dernière. L’interface utilisateur donne par ailleurs accès à tous ces modules, à condition d’y avoir souscrit. De plus, Datadog fait partie des acteurs qui proposent un seul agent, tout comme Dynatrace. Cette approche bout en bout, des concurrents comme New Relic ou Splunk commencent à l’adopter.

« Nous fournissons une plateforme dont le but est de résoudre vos problèmes depuis un seul endroit. »
Amit Argawal,Chief Product Officer, Datadog

« Nous croyons que nos clients n’ont pas besoin d’acheter vingt produits d’éditeurs différents pour régler leurs problèmes d’observabilité. Nous fournissons une plateforme dont le but est de résoudre vos problèmes depuis un seul endroit », insiste Amit Argawal.

Et pour cela, Datadog n’hésite pas à refondre les solutions acquises par le passé. C’est d’ailleurs un processus qui a surpris Renaud Boutet après le rachat de Logmatic, société qu’il a cofondée. « Une des premières choses que m’a dites Olivier Pomel [Directeur général et cofondateur de Datadog N.D.L.R.] au moment du rachat, c’est qu’il fallait tout déconstruire et reconstruire. Je n’ai pas bien compris à ce moment-là, mais c’était dans l’optique de proposer une plateforme unifiée ».

À noter cependant que la tarification, elle, n’est pas unifiée et que les entreprises clientes sont amenées à composer leurs propres suites d’outils suivant leurs besoins.

Mais là où Datadog semble en avance concernant l’architecture de sa plateforme d’ingestion de données et de ses produits, il marque a priori un retard sur le développement de solutions dites intelligentes. Les acteurs comme Dynatrace, New Relic, PagerDuty ou encore Splunk mettent en avant des capacités AiOps et d’autoremédiation.

« Il se trouve que beaucoup de gens promettent aujourd’hui la gestion automatisée des incidents, par exemple. Ce n’est pas encore une réalité. »
Renaud BoutetVice-Président Produit, Datadog

« La plupart de nos produits incluent des algorithmes et du machine learning, par exemple pour réduire le volume des alertes et réaliser des agrégations. Pour certaines problématiques, certains de nos concurrents déploient des capacités d’intelligence artificielle, qui ne sont pas forcément nécessaires pour les résoudre. Nous faisons tout ce que nos concurrents font et plus encore, simplement nous n’en faisons pas un argument marketing », déclare Amit Agarwal.

 Renaud Boutet se veut prudent sur l’utilisation des arguments comme l’AIops ou l’autoremédiation.
« Il se trouve que beaucoup de gens promettent aujourd’hui la gestion automatisée des incidents, par exemple. Ce n’est pas encore une réalité. Cela va le devenir avec des systèmes de workflows [comme le feature flagging N.D.L.R.], mais cela se limitera en premier lieu à des capacités simples comme redémarrer des machines dans un cluster. Nous nous dirigeons également dans cette direction, c’est inévitable », estime-t-il.

Pour approfondir sur Administration et supervision du Cloud

Close