alex_aldo - Fotolia
Database Monitoring : Datadog étend sa couverture des SGBDR dans le cloud
Le spécialiste de la supervision du cloud espère convaincre les ingénieurs applicatifs et les administrateurs de bases de données avec son outil Database Monitoring. Il couvre désormais PostgreSQL, MySQL et SQL Server ainsi que leurs versions managées sur AWS, Google Cloud et Microsoft Azure.
À la mi-août, Datadog a annoncé l’extension de son service de monitoring des bases de données à PostgreSQL, MySQL et SQL Server sur le cloud Azure.
Lancé il y a un an, ce service nommé Database Monitoring doit enrichir la plateforme APM du spécialiste de l’observabilité. Après avoir installé l’agent de Datadog, les administrateurs de bases de données (DBA) et les équipes DevOps peuvent non seulement suivre les métriques de performance classique d’une base de données (latences, consommation CPU, utilisation des disques, de la RAM, etc.), mais surtout étudier les performances des requêtes. La vue Query Metrics doit ainsi permettre d’identifier les requêtes les plus lentes, de les filtrer et de connaître le nombre de lignes mises à jour ou restaurées.
Avec Query Samples, il est ensuite possible de comparer des requêtes, en prenant pour référence celles qui représentent le standard attendu. Cet échantillonnage doit permettre de repérer « des anomalies dans les temps et les coûts d’exécution » des requêtes, ainsi que de les attribuer à un utilisateur, une application ou un hôte client.
Enfin, les plans d’exécution visent à détailler la manière dont une base de données exécute une requête à un moment T et son évolution dans le temps. Par exemple, l’outil détecte l’activation successive des algorithmes de jointure (hash join), ou encore les agrégations. Il permet d’associer un coût de démarrage et d’exécution à ces opérations et de consulter le nombre de lignes concernées. Il est aussi possible de configurer des alertes afin d’être notifié quand l’exécution des requêtes est anormalement longue. Néanmoins, les plans d’exécution ne supportent que les requêtes SELECT, UPDATE, INSERT, DELETE et REPLACE.
Database Monitoring, compatible avec les DBaaS SQL Azure, GCP et AWS
« Database monitoring donne une vision de toutes les bases de données et de leurs appels entrants, l’agrégation et l’inventaire des requêtes normalisées, leur performance type. Nous mettons en évidence les changements de performance et fournissons une vue détaillée de la façon dont la base de données exécute la requête avec des suggestions d’amélioration de performance vis-à-vis de la configuration de la base de données », résume Renaud Boutet, SVP Product Management chez Datadog. « Si une requête normalisée s’exécute mal, c’est souvent qu’il faut retravailler un index ».
Jusqu’alors, l’éditeur new-yorkais proposait le support de ces SGBD sur AWS et Google. Plus précisément, il prenait en charge Amazon RDS (pour Postgres, MySQL et SQL Server), Aurora (MySQL et Postgres) et Google Cloud SQL (MySQL, Postgres et SQL Server). Les usagers peuvent aussi manier Database monitoring pour superviser ces trois SGBD quand ils les hébergent eux-mêmes.
« Database Monitoring est en très forte croissance », affirme Renaud Boutet. « Désormais, nous pensons couvrir les trois plateformes de bases de données les plus utilisées par nos clients ». Il était déjà possible d’instrumenter les SGBD avec la plateforme d’observabilité, mais ce travail restait à la charge des clients.
En août 2021, l’éditeur avait commencé par supporter les versions autohébergées de PostgreSQL et de MySQL. Selon Renaud Boutet, Datadog a mis environ six mois pour instrumenter Microsoft SQL Server. Pour rappel, cette base de données propriétaires a son propre langage de requêtes : T-SQL. De plus, Datadog s’est adapté aux infrastructures, d’abord celles d’AWS, puis GCP et enfin Azure.
« D’un point de volume d’usage, après PostgreSQL et MySQL, Microsoft SQL Server était la base la plus naturelle à instrumenter », avance Renaud Boutet. « Par ailleurs, Microsoft est un écosystème à part entière. C’est pour nous aussi un moyen de fournir de plus en plus d’outils aux clients qui ne jurent que par les produits Azure ». En l’occurrence, Datadog et Microsoft assurent une intégration entre la plateforme d’observabilité et Azure Monitor pour recueillir toutes les métriques qui y sont référencées.
En soi, l’observabilité des bases de données sur Datadog n’est pas nouvelle. « Dès le lancement de Datadog, nous instrumentions et détections les métriques clés d’un SGBD », assure Renaud Boutet. « Ensuite, avec notre outil APM, nous pouvions voir les appels entrants et la performance perçue par le consommateur de la base de données, mais nous n’avions pas les plans d’exécution pour comprendre comment les requêtes sont exécutées, ou divers événements d’attente, pour décomposer l’impact de l’activité simultanée de la base de données sur les performances ».
La supervision des bases de données, un marché qui sort de sa niche
Datadog n’est pas le seul à fournir des outils de supervision de bases de données. Historiquement, des outils comme Paessler PRTG, Nagios, Zabbix ou Solarwinds sont très souvent utilisés par les DBA. La plateforme de Redgate apporte le même niveau de granularité que celle de Datadog, tandis que Zabbix ou Solarwinds proposent des fonctions similaires pour des bases de données NoSQL, MongoDB en tête. A contrario, si Datadog prend en charge le monitoring de MongoDB, l’analyse des performances est beaucoup plus manuelle.
« Nos clients utilisent majoritairement les bases de données relationnelles et je pense que cela restera vrai pendant longtemps », justifie Renaud Boutet. « Les utilisateurs de Datadog déploient les bases NoSQL pour des usages bien spécifiques ».
Cela ne veut pas dire que l’éditeur se refuse à renforcer l’analyse du comportement des SGBD NoSQL. « Avec Database Monitoring, nous envisageons de supporter MongoDB, Elasticsearch, mais aussi les nouveaux lacs de données tels Snowflake ou Databricks », anticipe le responsable.
Comme la plateforme de Datadog peut être utilisée par les administrateurs des SGBD et les ingénieurs applicatifs, cela faciliterait le dialogue entre ces deux corps de métier. Ils ont habituellement dû mal à communiquer pour résoudre des problèmes de performance. C’est en tout cas ce qu’avance Renaud Boutet qui rappelle là un mantra de l’éditeur : la collaboration.
Cependant, l’éditeur n’est pas le seul sur ce créneau. Dynatrace a lui aussi sa solution d’observabilité des bases de données accessibles aux développeurs et aux DBA. Celle-ci ne réclame pas d’instrumentation pour Cassandra, PostgreSQL, Couchdb, Couchbase et Redis, tandis qu’une extension est nécessaire pour Oracle, MySQL, SAP HANA, et IBM db2. Pour l’instant, Dynatrace fournit des analyses à partir des appels entrants via les frameworks JBDC, ADO.NET ou PDO. L’instrumentation au niveau de la base de données n’est disponible qu’en accès anticipé avec Oracle RAC et AWS Oracle RDS.
De son côté, New Relic s’intègre avec DBMarlin, un outil offrant des fonctionnalités proches de celles de Database Monitoring pour IBM db2, CockroachDB, MariaDB, MySQL, Oracle, Postgres et SQL Server.
Article mis à jour pour apporter des précisions dans les citations de Renaud Boutet.