Surveiller les charges de travail Azure SQL avec l’observateur de base de données (aperçu)

S’applique à :Azure SQL DatabaseAzure SQL Managed Instance

Important

Database Watcher prend sa retraite le 30 avril 2027 et n’atteindra pas la disponibilité générale (GA). Transition vers Database Hub dans Microsoft Fabric avant cette date. Pour le calendrier de mise hors service et les orientations de transition, consultez l’annonce de mise hors service.

À partir du 9 novembre 2026, vous ne pourrez plus créer de nouvelles ressources watcher ni modifier celles existantes. Les observateurs existants continuent d’opérer et de collecter des données jusqu’à leur retraite. Le 30 avril 2027, les ressources Watchers existantes entreront en état d’arrêt et cesseront la collecte de données. Après cette date, tu ne peux plus les commencer.

La mise hors service n'arrête ni ne déprovisionne vos ressources Azure Data Explorer ni votre Fabric Eventhouse. Les paramètres de rétention restent en vigueur, et les ressources conservées peuvent continuer à entraîner des frais. Les règles d’alerte existantes ne sont pas automatiquement supprimées. Recréez et testez les alertes dont vous avez besoin avant la retraite, puis désactivez ou supprimez les anciennes règles dont vous n’avez plus besoin.

Vous pouvez commencer à utiliser Database Hub avec une licence Fabric Free. Accéder au Database Hub ne nécessite pas de capacité Fabric, et activer la surveillance des performances prise en charge n'entraîne pas de coût supplémentaire. Des flux de travail supplémentaires, tels que des tableaux de bord personnalisés et des alertes Activator, peuvent avoir des exigences de capacité ou de licence distinctes. Pour commencer, voir Activer la surveillance des performances pour Microsoft SQL.

L’observateur de base de données est une solution de monitoring managée pour les services de base de données de la famille Azure SQL. Il prend en charge Azure SQL Database et Azure SQL Managed Instance.

L’observateur de base de données collecte des données de surveillance de charge de travail détaillées pour vous donner une vue détaillée des performances, de la configuration et de l’intégrité de la base de données. La surveillance des données à partir des bases de données, des pools élastiques et des instances managées SQL que vous sélectionnez est collectée dans un magasin de données central au sein de votre abonnement Azure. Les tableaux de bord dans le Portail Azure fournissent une vue à volet unique de votre patrimoine Azure SQL et une vue détaillée de chaque base de données, pool élastique et instance managée SQL. Les alertes vous envoient des notifications quand des conditions de base de données sur votre domaine Azure SQL peuvent nécessiter une attention particulière.

Capture d’écran d’un diagramme montrant les composants du watcher de base de données et le flux de données des ressources surveillées vers le watcher, puis au stockage de données et aux tableaux de bord du portail Azure.

Pour stocker et analyser des données de surveillance SQL, l’observateur de base de données peut utiliser Azure Data Explorer ou l’Analyse en temps réel dans Microsoft Fabric. Azure Data Explorer est un service de données complètement managé et hautement évolutif, conçu à des fins d’ingestion et d’analytique rapides sur les données de surveillance de série chronologique. Un cluster Azure Data Explorer unique peut être mis à l’échelle pour prendre en charge la surveillance des données provenant de milliers de ressources Azure SQL. L’Analyse en temps réel utilise le même moteur central qu’une offre SaaS au sein de Microsoft Fabric.

Vous pouvez interroger des données dans une base de données Azure Data Explorer ou d’Analyse en temps réel à l’aide de KQL ou T-SQL, créer des visualisations personnalisées à l’aide de tableaux de bord Azure Data Explorer, Power BI ou Grafana et analyser des données dans Excel. Vous pouvez définir la stratégie de conservation des données par base de données ou par table, et mettre à l’échelle votre cluster Azure Data Explorer automatiquement ou manuellement pour obtenir le rapport prix/performances optimal.

Pour commencer à surveiller vos ressources Azure SQL, créez une ressource observateur dans votre abonnement Azure. Configurez l’observateur en sélectionnant un magasin de données et un jeu de bases de données, de pools élastiques ou d’instances managées SQL à surveiller, appelées cibles SQL. Octroyez à l’observateur l’accès aux cibles et démarrez l’observateur.

Remarque

L’observateur de base de données est actuellement en préversion. Les fonctionnalités en aperçu sont publiées avec des capacités limitées, mais sont mises à disposition sur une base de version d'aperçu afin que les clients puissent obtenir un accès anticipé et donner leur avis. Les fonctionnalités en aperçu sont soumises à des conditions d’aperçu supplémentaires distinctes et ne sont pas soumises aux SLA. Le soutien est fourni comme meilleur effort dans certains cas. Toutefois, le support Microsoft est impatient d’obtenir vos commentaires sur la fonctionnalité en préversion et peut fournir un support optimal dans certains cas. Les fonctionnalités en aperçu peuvent avoir des fonctionnalités limitées ou restreintes et peuvent n’être disponibles que dans les zones géographiques sélectionnées.

Cibles Azure SQL prises en charge

L’observateur de base de données prend en charge tous les niveaux de service, niveaux de calcul et objectifs de service dans Azure SQL Database et Azure SQL Managed Instance. Ce support inclut les modèles d’achat vCore et DTU , les couches de calcul provisionnées et serverless , les bases de données uniques et les pools élastiques, ainsi que l’hyperscale.

L’observateur de base de données peut surveiller tous les types de réplicas lisibles secondaires, y compris les réplicas à haute disponibilité, les géo-réplicaset les réplicas secondaires nommés Hyperscale.

Pour un observateur donné, les cibles SQL peuvent se trouver dans n’importe quel abonnement dans le même locataire Microsoft Entra ID.

Tarification de l’observateur de base de données

Les coûts du watcher de base de données proviennent de ses composants individuels, comme suit :

Composant Prix Remarques
Observateurs Gratuit
Tableaux de bord Gratuit
Cluster de Azure Data Explorer 1 Détails de la tarification La référence SKU de cluster optimale dépend du nombre de cibles de surveillance et de la charge de travail de requête exécutée sur le cluster. Pour connaître les considérations relatives au dimensionnement du cluster, consultez Gérer le cluster Azure Data Explorer.
Analyse en temps réel dans Microsoft Fabric Inclus dans le modèle de consommation d'espace de travail Power BI Premium. Facturation à l'utilisation. Utilisez soit Azure Data Explorer, soit l’Analyse en temps réel. Il suffit d’une seule de ces offres.
Un coffre dans Azure Key Vault Détails de la tarification Vous n’avez besoin de ce composant que si vous utilisez l’authentification SQL optionnelle au lieu de l’authentification Microsoft Entra par défaut.
Bande passante du réseau Azure Détails de la tarification Vous n'avez pas ce coût si vous déployez un watcher, ses cibles et son stockage de données dans la même région Azure.
Alertes Détails de la tarification L’observateur de base de données utilise les alertes de logs. Le prix mensuel varie et dépend du nombre de règles d’alerte que vous créez, du nombre de cibles SQL générant des alertes au cours du mois, ainsi que de la fréquence d’évaluation de chaque règle d’alerte.

1 Vous pouvez utiliser un cluster Azure Data Explorer gratuit lorsque vous n'avez pas besoin d'un accord de niveau de service et lorsque les exigences de performance et de stockage des requêtes sont satisfaites par les spécifications de capacité du cluster gratuit. La période d’essai du cluster gratuit dure un an et peut être prolongée automatiquement.

Il n'y a pas de frais par ressource Azure SQL surveillée ni par utilisateur, ce qui fait de Database Watcher une solution de surveillance peu coûteuse pour les environnements Azure SQL plus larges et les équipes plus larges.

Disponibilité régionale

Vous pouvez créer des Watchers dans les régions Azure suivantes :

  • Centre du Canada
  • Est du Canada
  • Centre des États-Unis
  • USA Est
  • Est des États-Unis 2
  • Centre-Nord des États-Unis
  • USA Ouest

Conseil

Un observateur dans une région Azure peut surveiller les cibles d’une autre région. De même, un observateur et son magasin de données peuvent se trouver dans différentes régions.

Si possible, colocalisez un observateur, ses cibles et son magasin de données dans la même région. Si Database Watcher n'est pas disponible dans votre région, choisissez une région dans la même géographie Azure. Ce choix peut réduire les coûts de bande passante réseau Azure.

Limites

Il y a une limite au nombre de cibles SQL par observateur, et au nombre d’observateurs par abonnement. Azure ne prend pas en charge les déploiements dépassant ces limites.

Paramètre Limite
Cibles SQL par observateur1 100
Observateurs par abonnement 20

1Un réplica à haute disponibilité d’une base de données, d’un pool élastique ou d’une instance managée SQL est surveillé indépendamment de son réplica parent et est considéré comme une cible distincte.

Remarque

Pendant la phase d’aperçu, les limites sont susceptibles d’être modifiées.

Tableaux de bord

L’observateur de base de données utilise des classeurs Azure pour fournir des tableaux de bord de surveillance au niveau du domaine et au niveau des ressources.

L’image suivante montre un exemple de carte thermique d’utilisation du processeur de la base de données sur le tableau de bord du parc. Chaque hexagone représente une cible SQL. Il y a deux serveurs logiques, l’un avec six bases de données et l’autre avec trois bases de données. Les répliques secondaires à haute disponibilité apparaissent sur la carte thermique comme cibles distinctes. Sélectionnez l’image pour voir plus de détails, y compris les statistiques d’ingestion de données.

Capture d’écran d’un exemple de carte thermique d’utilisation du processeur dans le tableau de bord du parc Database Watcher de la base de données.

L’image suivante montre un exemple d’une vue partielle de l’onglet Performance d’un tableau de bord de base de données Azure SQL. Sélectionnez l’image pour zoomer sur les détails.

Capture d’écran d’un exemple de tableau de bord de surveillance de base de données pour une base de données Azure SQL.

Le tableau suivant décrit les capacités des tableaux de bord de l’observateur de base de données dans le Portail Azure.

Capacité Descriptif
Tableaux de bord du domaine Visualisez les données de surveillance de haut niveau pour plusieurs ressources surveillées dans une vue commune. Utilisez des cartes thermiques pour rechercher les principales bases de données consommatrices de ressources, les pools élastiques ou les instances managées SQL.

Utilisez la vue des requêtes les plus consommatrices de ressources pour trouver les requêtes les plus gourmandes en ressources dans votre parc Azure SQL, classer les requêtes par CPU, durée, nombre d’exécutions, et plus encore.

Utilisez les filtres d’abonnement, de groupe de ressources et de nom de ressource pour vous concentrer sur les sous-ensembles de votre patrimoine Azure SQL.

Explorez les tableaux de bord détaillés pour des ressources spécifiques.
Tableaux de bord de ressources Visualisez des données de surveillance détaillées pour une base de données, un pool élastique ou une instance managée SQL, notamment :

- Sessions actives
- Historique de sauvegarde
- Compteurs de performances courants
- Sondes de connectivité
- Propriétés et configuration de base de données et d’instance
- Géoréplication
- Métadonnées d’index, statistiques d’utilisation, avertissements et suggestions
- Utilisation des ressources
- Statistiques de session et de connexion
- État et historique des travaux SQL Agent
- Consommation et performance du stockage
- Métadonnées de table
- Requêtes principales
- Statistiques d’attente

Utilisez des listes déroulantes de ressources pour passer rapidement d’une ressource à une autre. Utilisez le lien de domaine pour effectuer un zoom arrière vers un tableau de bord de domaine.
Filtrage par intervalle de temps Sur chaque tableau de bord, définissez l’intervalle de temps sur lequel vous souhaitez vous concentrer. Utilisez des intervalles de temps standard ou personnalisés. Réduisez l’intervalle de temps à une plage d’intérêt en « balayant », ou en faisant glisser le curseur de la souris sur un graphique pour sélectionner un intervalle de temps plus court.
Données historiques En fonction du jeu de données, les tableaux de bord affichent soit un récapitulatif pour l’intervalle de temps sélectionné, soit le dernier échantillon collecté dans l’intervalle de temps.

Basculez entre la dernière vue et l’historique pour examiner les exemples de données plus tôt dans l’intervalle de temps sélectionné. Par exemple, au lieu d’examiner les sessions actuellement actives, passez en revue un échantillon précédent de sessions actives collectées lorsqu’un pic d’utilisation des ressources s’est produit.
Réplicas secondaires Surveillez tous les types de réplicas, y compris les réplicas secondaires haute disponibilité (HA) sur les tableaux de bord de domaine. Basculez entre l’affichage du réplica principal et son réplica secondaire haute disponibilité sur les tableaux de bord de ressources.
Téléchargement des données vers Excel Téléchargez les données des graphiques et des grilles sous forme de fichiers csv et ouvrez-les dans Excel pour plus d’analyses.
Actualisation des données Récupérez les données les plus récentes du magasin de données de surveillance lorsque vous ouvrez un tableau de bord et que vous passez d’un onglet à l’autre. Lorsque le tableau de bord est ouvert depuis un certain temps, actualisez-le manuellement pour afficher les données les plus récentes ou activez l’actualisation automatique du tableau de bord.
Requête KQL ad hoc Utilisez un lien sur chaque tableau de bord pour ouvrir l’interface utilisateur Web d’Azure Data Explorer et interroger vos données de surveillance avec KQL. Pour plus d’informations, consultez Jeux de données et Utiliser KQL pour analyser les données de surveillance.
Descriptions Activez le paramètre Afficher les descriptions pour consulter les descriptions qui vous aident à interpréter les données affichées et à inclure des liens de documentation pertinents.
Info-bulles Passez sur un champ pour afficher plus de détails et de contexte sur les données affichées.
Statistiques d’ingestion Utilisez le lien des statistiques d’ingestion pour afficher la latence d’ingestion des données et d’autres statistiques d’ingestion par jeu de données.
Mode sombre Changez l’apparence du Portail Azure pour qu’il utilise le thème sombre de manière à ce que les tableaux de bord de l’observateur de base de données utilisent le mode sombre.

Remarque

Pendant la phase d’aperçu, les visualisations et les fonctionnalités du tableau de bord sont susceptibles d’être modifiées.

Données de surveillance SQL

L’observateur de base de données collecte les données de surveillance à partir de plus de 70 affichages catalogue SQL et vues de gestion dynamique (DMV). Les données d’une ou plusieurs vues associées sont transformées en un jeu de données. Par exemple, les données provenant des vues sys.dm_exec_sessions, sys.dm_exec_requests et d’autres vues forment le jeu de données Sessions actives. Pour chaque jeu de données, il existe une table distincte dans la base de données Azure Data Explorer ou dans la base de données d’Analyse en temps réel.

L’observateur de base de données dispose de groupes de jeux de données distincts pour les bases de données, les pools élastiques et les instances managées SQL. Chaque groupe compte entre 10 et 30 jeux de données, offrant une vue détaillée des performances, de la configuration et de l’intégrité des bases de données pour vos ressources Azure SQL.

Pour plus d’informations, consultez Collection de données et jeux de données de l’observateur de base de données.

Alertes

L’observateur de base de données fournit un ensemble de modèles de règles d’alerte pour vous permettre de créer facilement des règles d’alerte Azure Monitor. Une fois qu’une règle d’alerte est créée, vous pouvez la personnaliser et la gérer comme n’importe quelle autre règle d’alerte dans Azure Monitor. Pour plus d’informations, consultez alertes d’observateur de base de données.

Connectivité réseau

L’observateur de base de données utilise un agent de collecte de données distant qui se connecte aux cibles, au magasin de données et au coffre de clés sur le réseau. En fonction des exigences de sécurité réseau et de la configuration de vos ressources Azure, l’observateur de base de données peut utiliser une connectivité privée ou publique. Vous contrôlez toujours entièrement la connectivité réseau de l’observateur de base de données à vos ressources Azure.

Pour plus d’informations sur la connectivité réseau dans Azure SQL, consultez Architecture de connectivité Azure SQL Database et Architecture de connectivité Azure SQL Managed Instance.

Connectivité privée

Pour fournir une connectivité privée, l’observateur de base de données utilise Azure Private Link. Lorsque vous configurez un observateur, vous pouvez créer des points de terminaison privés managés pour permettre à l’observateur de se connecter aux bases de données et aux pools élastiques sur des serveurs logiques ou à des instances managées SQL. Vous pouvez également créer un point de terminaison privé pour le cluster Azure Data Explorer et pour le coffre de clés qui stocke les identifiants d’authentification SQL. À ce stade, la connectivité privée n’est pas disponible pour les connexions à l’Analyse en temps réel dans Microsoft Fabric.

Un propriétaire de ressource doit approuver le point de terminaison privé managé pour un observateur avant que l’observateur puisse l’utiliser. À l’inverse, les propriétaires de ressources peuvent supprimer n’importe quel point de terminaison privé pour un observateur à tout moment pour arrêter la collecte de données.

Une fois que vous avez créé et approuvé un point de terminaison privé managé pour un observateur qui cible une ressource Azure, tout le trafic réseau entre l’observateur et la ressource utilise une connectivité privée, même si la connectivité publique pour la ressource reste activée.

Pour plus d’informations sur les points de terminaison privés dans Azure SQL, consultez Azure Private Link pour Azure SQL Database et Azure Private Link pour Azure SQL Managed Instance.

Connectivité publique

Si vous n'avez pas besoin de connectivité privée, Database Watcher peut utiliser la connectivité publique pour se connecter aux ressources Azure. Pour permettre à un observateur de se connecter à des bases de données et des pools élastiques sur un serveur logique Azure SQL Database, vous devez activer l’accès public au serveur et configurer le pare-feu basé sur IP pour permettre les connexions depuis tous les services Azure.

Pour permettre à un observateur de se connecter à une instance gérée SQL en utilisant une connectivité publique, vous devez activer le point de terminaison public de l’instance. Vous devez également définir sur AzureCloud la source d’une règle Network Security Group (NSG) qui autorise le trafic entrant sur le port TCP 3342 vers le sous-réseau de l’instance gérée. Pour plus d’informations, consultez Configurer un point de terminaison public dans Azure SQL Managed Instance.

Pour permettre à un watcher de se connecter à un cluster Azure Data Explorer ou à un coffre de clés en utilisant la connectivité publique, vous devez activer l’accès réseau depuis tous les réseaux vers le cluster ou le coffre.

Accès aux données

Vous contrôlez entièrement l’accès des watchers de base de données à vos bases de données, tout comme la connectivité réseau. Accordez l’accès en créant des comptes watcher dédiés sur des serveurs logiques et des instances managées SQL. Ensuite, accordez des autorisations spécifiques et limitées pour collecter des données de surveillance à partir des vues SQL du système.

Authentification de l’observateur

L’observateur de base de données prend en charge l’authentification Microsoft Entra (précédemment appelée authentification Azure Active Directory). Cette méthode d’authentification est la méthode préférée et recommandée pour un watcher afin de s’authentifier sur une cible SQL. Créez un identifiant d’authentification Microsoft Entra pour l’identité gérée de l’observateur sur tous les serveurs logiques et instances gérées SQL que vous souhaitez surveiller.

L’observateur de base de données prend également en charge l’authentification SQL basée sur mot de passe. Utilisez l'authentification SQL si vous n'activez pas l'authentification Microsoft Entra sur vos ressources Azure SQL. Pour plus d’informations, consultez Configuration supplémentaire pour utiliser l’authentification SQL.

Autorisation de l’observateur

Pour collecter des données de surveillance, un watcher a besoin d’un accès spécifique et limité à chaque cible monitorée. Le tableau suivant décrit l’accès requis. Ces appartenances et autorisations de rôle donnent à un observateur l’accès nécessaire aux données de surveillance du système, mais pas à d’autres données de vos bases de données.

Azure SQL Database Azure SQL Managed Instance (Instance gérée Azure SQL)
Appartenance à tous les rôles serveur suivants :
##MS_ServerPerformanceStateReader##
##MS_DefinitionReader##
##MS_DatabaseConnector##
Autorisations de serveur suivantes :
CONNECT SQL
CONNECT ANY DATABASE
VIEW ANY DATABASE
VIEW ANY DEFINITION
VIEW SERVER PERFORMANCE STATE

L'autorisation SELECT sur les tables suivantes de la base de données msdb :
dbo.backupmediafamily
dbo.backupmediaset
dbo.backupset
dbo.suspect_pages
dbo.syscategories
dbo.sysjobactivity
dbo.sysjobhistory
dbo.sysjobs
dbo.sysjobsteps
dbo.sysoperators
dbo.syssessions

Important

Lorsqu’un observateur se connecte à une ressource Azure SQL, il valide les autorisations SQL qu’il contient. Si les autorisations octroyées sont insuffisantes ou si des autorisations inutiles sont octroyées, l’observateur se déconnecte. Cela garantit que l’observateur peut collecter les données de surveillance du système, mais n’est pas accidentellement autorisé à accéder à d’autres données dans vos bases de données.

Inversement, si vous accordez des permissions inutiles à la connexion ou à l’utilisateur d’un observateur, ou à un rôle dont la connexion ou l’utilisateur de l’observateur est membre, l’observateur pourrait ne pas collecter de données de surveillance pour certains ou tous les ensembles de données. De même, la collecte de données peut s’arrêter si vous ajoutez le login ou l’utilisateur du watcher à un rôle serveur intégré ou à un rôle de base de données intégré.

Si vous refusez les autorisations requises à la connexion ou à l’utilisateur d’un observateur, ou à un rôle disposant d’une connexion ou d’un utilisateur observateur en tant que membre (y compris le public rôle de base de données), l’observateur risque de ne pas collecter les données de surveillance. Selon les autorisations refusées, cela peut affecter certains ou tous les jeux de données.

À l’inverse, si vous accordez des autorisations inutiles à la connexion ou à l’utilisateur pour un observateur, ou à un rôle disposant de la connexion ou de l’utilisateur observateur en tant que membre, il se peut que l’observateur ne collecte pas les données de surveillance pour certains jeux de données ou tous les jeux de données. De même, les données peuvent ne pas être collectées si vous ajoutez la connexion ou l’utilisateur observateur à un serveur ou un rôle de base de données intégré.

Nouveautés

Cette section décrit les correctifs, modifications et améliorations récents de l’observateur de base de données.

Période Modifications
Juillet 2025 - Résolution d’un problème où les requêtes de surveillance de l’observateur de base de données empêchaient les bases de données serverless, y compris les bases de données de l’offre gratuite, de se mettre en pause. Pour plus d’informations, consultez Collecte de données dans les bases de données serverless.
Avril 2025 - Correction d'un bug où un déploiement d'observateur de base de données via Bicep, un modèle ARM, Terraform ou une API REST échouait si les paramètres de déploiement de l'ID d'abonnement, du nom du groupe de ressources ou du nom de l'observateur utilisaient une casse incohérente.
- Correction d’un bogue dans lequel la collecte de certains jeux de données pour une cible de base de données SQL s’arrêterait si la base de données a été restaurée à partir de la sauvegarde.
- Changez pour limiter la collecte de données dans les jeux de données de métadonnées de table pour les bases de données avec de nombreuses tables et pour les instances managées SQL avec de nombreuses bases de données afin d’éviter les requêtes de collecte longues.
- Améliorer les performances des requêtes de collecte pour l'ensemble de données de statistiques de session pour les cibles SQL Managed Instance.
Février 2025 - Ajouter la prise en charge des alertes. Pour plus d’informations, consultez alertes d’observateur de base de données.
Janvier 2025 - Correctif pour rendre les déploiements de l’observateur de base de données via des modèles Bicep ou ARM idempotent.
- Correction d’un bogue dans lequel les détails de l’historique des travaux de SQL Agent sur le tableau de bord détaillé sql Managed Instance n’étaient pas affichés.
- Correction d'un bogue qui se produisait lors du filtrage des données sur les graphiques Sessions sur les tableaux de bord détaillés, ce qui entraînait des erreurs lors des requêtes KQL.
- Correction d’un bogue dans lequel les valeurs de débit de stockage sur les tableaux de bord détaillés étaient incorrectes.
- Améliorez les graphiques d’utilisation du stockage sur les tableaux de bord détaillés pour inclure la taille de stockage maximale.
- Améliorez l’affichage de la taille d’origine et compressée des données collectées dans la section Magasin de données .
- Améliorez le message affiché lorsqu’un tableau de bord ne peut pas se connecter au magasin de données pour inclure des suggestions pour des problèmes courants.
- Ajoutez des messages d’information lorsqu’il n’y a pas de données affichées dans les tableaux de bord Top requêtes pour des raisons connues.
- Ajout des informations de limite de débit de journal Hyperscale dans le jeu de données Réplicas pour les bases de données Azure SQL.
- Ajoutez l’heure de début de la transaction et les octets de journal utilisés aux jeux de données des sessions actives .
Novembre 2024 - Activer l’observateur de base de données dans les régions Azure Australie Centre, Australie Sud-Est, Canada Est, USA Centre, Allemagne Centre-Ouest, Japon Ouest, Corée Centre et USA Centre Nord.
- Augmentez la limite du nombre de cibles SQL par observateur de 50 à 100.
Octobre 2024 - Corrigez les bogues dans lesquels le jeu de données Métadonnées de table n’a pas été collecté s’il y avait des vues avec des références de table non valides ou des tables avec plusieurs contraintes de vérification de colonne.
- Ajout de la prise en charge de l’utilisation d’une identité affectée par l’utilisateur comme identité observateur. Pour plus d’informations, consultez Modifier l’identité de l’observateur.
- Accordez automatiquement à l’observateur l’accès aux secrets du coffre de clés lors de l’ajout d’une cible SQL qui utilise l’authentification SQL.
- Accordez automatiquement à l’observateur l’accès à une base de données Azure Data Explorer lors de l’ajout d’un magasin de données à un observateur existant.
- Ajoutez le bouton commentaires sur la page Vue d’ensemble et d’autres pages.
Septembre 2024 - Correction d’un bogue dans lequel le nombre de sessions logiques utilisateur dans le jeu de données Statistiques de session était toujours identique au nombre de sessions utilisateur, même si les sessions logiques MARS étaient utilisées.
- Corrigez un bogue dans lequel l’utilisation du stockage de pool élastique n’a pas été signalée correctement pour les pools élastiques Hyperscale.
- Résoudre un problème où, pour certains ensembles de données, le premier échantillon collecté après un redémarrage du watcher peut contenir des données déjà collectées avant le redémarrage.
- Améliorez les performances des requêtes de collecte afin d’éviter les délais d’expiration pour le jeu de données de métadonnées de table.
- Améliorez la fiabilité de collecte pour les statistiques d’exécution de requête et les jeux de données de statistiques d’attente de requête sur SQL Managed Instance.
- Ajout des colonnes liées au basculement au jeu de données Réplicas de base de données pour SQL Managed Instance.
- Ajoutez des colonnes de statistiques opérationnelles d’index aux jeux de données de métadonnées d’index.
- Prise en charge de la sélection de plusieurs bases de données Azure SQL dans le volet Ajouter une cible SQL.
Août 2024 - Activez l’observateur de base de données dans les régions Azure USA Centre, USA Est 2, Europe Nord et Suède Centre.
- Ajouter des filtres d’abonnement et de groupe de ressources dans les tableaux de bord de l'ensemble.
Juillet 2024 - Correction d’un bogue dans lequel les jeux de données Compteurs de performances n’ont pas été collectés à partir de bases de données avec un classement de catalogue sensible à la casse ou des instances gérées avec un classement de base de données sensible à la casse.
- Correction d’un bogue dans lequel les données n’ont pas été collectées si le nom de la base de données dans les métadonnées SQL avait un cas différent du nom de la base de données dans les métadonnées Azure Resource Manager (ARM).
- Correction d’un bogue dans lequel les jeux de données des statistiques d'exécution de requête et des statistiques d’attente de requête n’étaient pas collectés dans les bases de données avec un grand volume de nouvelles requêtes et de plans de requête insérés dans les tables du store de requêtes.
- Résolvez un problème où les jeux de données géoréplicas et réplicas n’ont pas été collectés à partir de bases de données Hyperscale.
- Ajoutez les subscription_idresource_group_namecolonnes communes à tous les jeux de données. Nécessite un redémarrage unique d’un observateur.
- Ajoutez la resource_idcolonne commune à tous les jeux de données. Les données s’affichent pour les cibles SQL ajoutées en juillet 2024 ou plus tard. Pour que les données apparaissent pour une cible SQL existante, supprimez et ajoutez à nouveau la cible, puis redémarrez l’observateur.
Juin 2024 - Correction d’un bogue dans lequel les données n’étaient pas collectées à partir de certaines cibles SQL ajoutées via Bicep ou un modèle ARM.
- Correction d’un bogue dans lequel le jeu de données de l’historique de sauvegarde n’a pas été collecté pour certaines bases de données Azure SQL.
- Correction d’un bogue dans lequel le type de réplica d’une instance managée a été mal déterminé comme redirecteur de géoréplication si l’instance avait une base de données à l’aide du lien Managed Instance. Le même bogue a fait que les ensembles de données des statistiques d'exécution de requête et des statistiques d'attente de requête n'ont pas été collectés dans ce cas.
- Corriger un bug qui causait une erreur « échec au chargement des cibles » dans le volet SQL des cibles du portail Azure si l'utilisateur n'avait pas accès à l'abonnement de la cible SQL, ou si l'abonnement était supprimé.
- Correction d’un bogue dans lequel la période de rétention et de cache d’une base de données Azure Data Explorer créée par défaut lors de la création d’un observateur dans le portail Azure a été définie sur illimitée au lieu de 365 et 31 jours respectivement.
- Corriger un bug où certaines opérations de gestion, telles que la création ou la suppression d’un point de terminaison privé géré, étaient signalées comme réussies dans le portail Azure alors qu’elles avaient échoué.
- Corriger un bug où, pour les cibles de base de données SQL , la liste des bases de données dans la liste déroulante était incomplète si le serveur logique SQL contenait plus de 1 000 bases de données.
- Corriger un bogue où la sélection d’une base de données Azure Data Explorer comme magasin de données entraînerait la suppression de l’accès d'un autre observateur du même groupe de ressources à cette base de données.
- Activer l’exportation de modèle ARM observateur dans le portail Azure.
- Ajoutez un avertissement lors de la création de l’observateur si le fournisseur de ressources Microsoft.Network n’est pas inscrit dans l’abonnement sélectionné pour l’observateur.
- Ajoutez une erreur détaillée si la suppression d’un observateur ou d’un point de terminaison privé managé échoue, car il existe un verrou de suppression sur l’étendue de la ressource.
Avril 2024 - Activation de l’observateur de base de données dans les régions Azure Australie Est et Royaume-Uni Sud.
- Correction d’une défaillance lors de l’ajout d’un point de terminaison privé managé lorsque plusieurs points de terminaison privés sont ajoutés rapidement pour le même observateur.
- Corrigez le jeu de données d’historique de sauvegarde pour les bases de données SQL afin d’inclure des sauvegardes complètes.
- Améliorez les performances des requêtes de collecte pour éviter les délais d’expiration des métadonnées d’index, les statistiques d’exécution des requêtes, les statistiques d’attente des requêtes et les jeux de données de métadonnées de table .
- Correction d’un bogue où pour certains jeux de données, les données n’ont pas été collectées après la restauration d’une base de données à partir d’une sauvegarde.
- Correction d’un bogue où les métadonnées de l'index n'ont pas été collectées lorsque les index ont de nombreuses colonnes clés ou incluses ou lorsque les noms de ces colonnes sont longs.
- Ajoutez le jeu de données des planificateurs SOS.
- Ajoutez un bouton pour télécharger le plan de requête sélectionné à partir des tableaux de bord Principales requêtes .
- Ajoutez un exemple de démarrage rapide pour créer et configurer un observateur à l’aide de Bicep ou d’un modèle ARM.

Limites

Cette section décrit les limitations de l’observateur de base de données. Les solutions de contournement sont fournies si elles sont disponibles.

Limite Solution de contournement
Les alertes ne sont pas disponibles lorsque le magasin de données utilise Analytique en temps réel dans Microsoft Fabric ou un cluster Azure Data Explorer gratuit. Dans Analytique en temps réel, vous pouvez créer des alertes d’activateur pour un tableau de bord Real-Time.
Les alertes de recherche dans les journaux Azure sur Azure Data Explorer ne prennent pas en charge la fréquence d’évaluation des alertes de 1 minute. Aucune à l’heure actuelle
Les alertes de recherche journalière Azure dans Azure Data Explorer ne sont pas prises en charge lorsque l'accès public au cluster Azure Data Explorer est désactivé. Aucune à l’heure actuelle
En raison d’une restriction de sécurité dans Azure Monitor, vous ne pouvez pas modifier les requêtes de règle d’alerte dans le portail Azure si vous vous connectez à partir d’une adresse IP associée à un réseau virtuel où des points de terminaison privés existent. Vous pouvez modifier une règle d’alerte à l’aide d’Azure CLI, de PowerShell, d’API REST ou de modèles ARM. Pour plus d’informations, consultez Créer une règle d’alerte à l’aide de l’interface CLI, de PowerShell ou d’un modèle ARM et Gérer les règles d’alerte.
Si vous utilisez des références SKU Azure Data Explorer plus petites telles que Dev/test ou Très petit, certaines requêtes de tableau de bord peuvent échouer par intermittence à s’exécuter avec une erreur « Annulée en raison d’une limitation ». Rechargez le tableau de bord ou effectuez un scale-up du cluster Azure Data Explorer vers la référence SKU supérieure suivante.
Si vous créez un cluster Azure Data Explorer gratuit à partir de l’interface utilisateur de l’observateur de base de données dans le Portail Azure, vous pouvez obtenir une erreur « Impossible de se connecter au cluster, 403-Interdit » si vous essayez d’accéder au cluster dans l’interface utilisateur Web d’Azure Data Explorer. Ce problème ne se produit pas si vous créez le cluster gratuit à l’aide de https://aka.ms/kustofree.

Si vous avez déjà créé un cluster gratuit à partir du portail Azure, procédez comme suit :

Dans l’interface utilisateur web d’Azure Data Explorer, sélectionnez le nom de votre profil dans la barre principale pour ouvrir le gestionnaire de comptes, puis sélectionnez Changer d’annuaire. Sélectionnez le répertoire autre quele compte Microsoft, puis sélectionnez Switch. Vous devriez maintenant voir le cluster Azure Data Explorer gratuit que vous avez créé.

Vous pouvez également modifier la connexion de cluster dans l’interface utilisateur web d’Azure Data Explorer à l’aide du bouton Modifier (crayon) et changer de même le répertoire.
Si la consommation de l’UC pour une base de données, un pool élastique ou une instance managée SQL persiste à près de 100 %, les ressources d’UC restantes peuvent être insuffisantes pour les requêtes de collection de données de l’observateur de base de données, ce qui entraîne des lacunes dans les données collectées. Si vous observez des lacunes de données qui correspondent à une utilisation élevée de l’UC dans la base de données, le pool élastique ou une instance managée SQL, envisagez de régler la charge de travail de votre application pour réduire la consommation de l’UC, ou augmentez le nombre de vCores ou de DTU pour permettre une surveillance fiable.

Problèmes connus

Pendant la préversion, l’observateur de base de données présente les problèmes connus suivants.

Problème Atténuation ou solution de contournement
Si la collecte de données ne peut ni démarrer ni continuer à cause d’une erreur (par exemple, un accès insuffisant à une cible SQL ou au stockage de données), l’erreur n’est pas exposée. Pour résoudre le problème, voyez Les données ne sont pas collectées.
En raison d’un problème connu dans Azure SQL Database et Azure SQL Managed Instance, les données attendues peuvent ne pas être collectées à partir d’un réplica secondaire accessible en haute disponibilité (HA) si les réplicas de base de données changent de rôles, par exemple après un événement de maintenance. Généralement, le problème se résout sans aucune action dans un ou deux jours. Pour reprendre la collecte de données plus tôt, redémarrez l’observateur.
Pour Azure SQL Managed Instance, les données peuvent ne pas être collectées à partir d'un réplica haute disponibilité en lecture seule ou d'une géo-réplication si vous utilisez l’authentification SQL. Il existe deux solutions de contournement :
1. Utilisez l’authentification Microsoft Entra ID (par défaut).
2. Désactivez la vérification de la politique de mot de passe. Exécutez ALTER LOGIN [database-watcher-login-placeholder] WITH CHECK_POLICY = OFF;, en remplaçant database-watcher-login-placeholder par le nom de la connexion d’authentification SQL de l’observateur. Exécutez cette commande sur la réplique principale et sur la géoréplique, si disponible.
Dans Azure SQL Managed Instance, les données ne sont pas collectées si l'autorisation EXECUTE sur la procédure stockée du système sys.xp_msver est révoquée ou refusée au rôle public. Accordez l'autorisation EXECUTE sur sys.xp_msver à la connexion de l'observateur.

Sur chaque SQL Managed Instance ajoutée en tant que cible SQL, exécutez USE master; CREATE USER [database-watcher-login-placeholder] FOR LOGIN [database-watcher-login-placeholder]; GRANT EXECUTE ON sys.xp_msver TO [database-watcher-login-placeholder];, en remplaçant database-watcher-login-placeholder par le nom de la connexion observateur.
Si vous créez un point de terminaison privé managé pour qu’un observateur se connecte à une instance managée SQL arrêtée, l’état d’approvisionnement du point de terminaison privé est signalé comme en échec et l’observateur ne peut pas se connecter à l’instance. Supprimez le point de terminaison privé managé avec l’état d’approvisionnement enéchec et démarrez l’instance managée SQL. Une fois le point de terminaison privé en échec supprimé et l’instance en cours d’exécution, recréez le point de terminaison privé managé.
Les données ne sont pas collectées si vous utilisez une base de données d’Analyse en temps réel comme magasin de données et que l’option de disponibilité OneLake est activée. Désactivez l’option de disponibilité OneLake et redémarrez l’observateur pour reprendre la collection de données.
En raison d’un problème connu dans les alertes Azure Monitor, si vous modifiez une règle d’alerte créée à partir d’un modèle observateur de base de données, l’étendue d’une alerte déclenchée est définie sur le cluster Azure Data Explorer utilisé comme magasin de données observateur au lieu de la cible SQL à laquelle l’alerte s’applique. Modifiez la règle d’alerte par programmation, par exemple à l’aide de Bicep ou d’un modèle ARM, puis définissez la propriété resourceIdColumn sur la valeur resource_id. Pour plus d’informations, consultez Exemples de modèles Resource Manager pour les règles d’alerte de recherche dans les journaux dans Azure Monitor.

Résolution des problèmes

Cette section décrit les étapes à suivre pour résoudre les problèmes courants. Si les étapes de cette section ne résolvent pas le problème, ouvrez un cas de support.

Les données ne sont pas collectées

Si vous créez un nouveau watcher et ne voyez pas de données de surveillance sur les dashboards et dans le data store, ou si vous ne voyez que des données plus anciennes pour un watcher existant, consultez cette section.

  • Dans la page Vue d’ensemble de l’observateur, vérifiez le champ État pour voir si l’observateur est en cours d’exécution. Si ce n’est pas le cas, utilisez le bouton Démarrer sur la même page pour démarrer la collection de données. Un nouveau watcher n’est pas lancé automatiquement.

  • Vérifiez que l’observateur dispose de l’accès au magasin de données.

  • Si vous utilisez une base de données Azure Data Explorer comme magasin de données, vérifiez que le cluster Azure Data Explorer est démarré. Pour plus d’informations, consultez Clusters Azure Data Explorer arrêtés.

  • Vérifiez que l’observateur dispose de l’accès spécifique et limitéaux cibles SQL. En outre, si vous utilisez l’authentification SQL pour n'importe quelle cible, vérifiez l’accès de l’observateur au coffre de clés, ou utilisez plutôt l’authentification recommandée Microsoft Entra.

  • Si vous souhaitez que l’observateur utilise l’authentification Microsoft Entra pour se connecter aux cibles SQL, assurez-vous que l’authentification Microsoft Entra est activée sur les serveurs logiques SQL hébergeant les cibles de base de données et de pool élastique, ainsi que sur les cibles d’instance gérée SQL.

  • Si vous avez créé des points de terminaison privés pour le watcher, assurez-vous que le propriétaire de la ressource les approuve.

  • Si vous utilisez une connectivité publique, assurez-vous de remplir les exigences permettant au watcher de se connecter aux cibles, au stockage de données et à Key Vault.

  • Le cluster ou la base de données Azure Data Explorer, ou la base de données Analytique en temps réel, peut être supprimé après l’avoir sélectionné comme stockage de données pour votre watcher. Accédez au cluster et à la base de données, et confirmez qu’ils existent.

  • Si vous utilisez le cluster gratuit Azure Data Explorer, assurez-vous de ne pas avoir atteint la capacité de stockage du cluster. Pour plus d’informations, consultez Cluster Azure Data Explorer gratuit.

Si vous apportez des modifications à l’accès ou à la connectivité de l’observateur dans le cadre de la résolution des problèmes, vous devrez peut-être arrêter et redémarrer l’observateur pour que les modifications prennent effet.

Les tableaux de bord sont vides

Si vous sélectionnez la page Dashboards d’un watcher mais ne voyez pas de résumé des cibles SQL sur la page, développez la section Data store. Si vous voyez une erreur Impossible de se connecter..., passez en revue cette section.

Pour vérifier que vous avez accès et que vous pouvez vous connecter au magasin de données et que la base de données du magasin de données existe, procédez comme suit :

  • Dans la page Tableaux de bord d’un observateur, développez la section Magasin de données et copiez la valeur de l’URI de requête Kusto. Assurez-vous de copier toute la chaîne d’URI. Notez également la valeur de la base de données Kusto.

  • Ouvrez l’interface utilisateur web Azure Data Explorer. Connectez-vous si vous y êtes invité.

  • Sélectionnez Ajouter, Connexion, puis saisissez l’URI copié en tant que l’URI de connexion.

  • Sélectionnez Ajouter pour créer une nouvelle connexion.

  • Une fois qu’une nouvelle entrée de connexion est ajoutée, développez-la pour afficher les bases de données.

  • Sélectionnez la base de données référencée comme base de données Kusto sur la page Tableaux de bord de votre observateur, puis sélectionnez le signe + de la barre d’onglets pour ouvrir un nouvel onglet de requête connecté à cette base de données.

  • Exécutez la commande KQL suivante :

    .show database principals;
    

    Vérifiez qu’une ligne pour un Viewer ou un rôle privilégié supérieur existe pour votre compte d’utilisateur, ou pour un groupe Microsoft Entra ID qui contient votre compte d’utilisateur.

Envoyer les commentaires

L’équipe de surveillance de la base de données chez Microsoft attend avec impatience vos commentaires et suggestions. Envoyez un retour sur le produit de l’une des manières suivantes :

  • Publiez une nouvelle idée dans le forum de commentaires SQL. Sur la page Publier une nouvelle idée, utilisez SQL comme forum, sélectionnez le groupe Azure SQL et incluez observateur de base de données dans le titre. Les commentaires que vous envoyez dans le forum de commentaires sont publics. D’autres membres de la communauté peuvent commenter et voter pour vos idées et suggestions. Les votes et commentaires de la communauté aident l’équipe en charge de l’observateur de base de données à planifier et à hiérarchiser les améliorations de produit.
  • Utilisez le bouton commentaires sur l’une des pages observateur de base de données dans le portail Azure. Par exemple, vous pouvez trouver le bouton commentaires sur la page Vue d’ensemble de l’observateur ou sur les tableaux de bord en regard du bouton Actualiser. Les retours que vous envoyez par ici ne sont pas publics. Bien que Microsoft prenne en compte vos retours, selon vos préférences et les règles de confidentialité en vigueur, Microsoft pourrait ne pas être en mesure de vous répondre à ce sujet.

Pour un support technique ou pour résoudre un problème avec l’observateur de base de données, ouvrez un cas de support.