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.

Pour approfondir sur Base de données