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.

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