Partage via

Créer et configurer un observateur de base de données (aperçu)

  • Article

S’applique à : Azure SQL DatabaseAzure SQL Managed Instance

L’observateur de base de données ne vous oblige pas à déployer et à gérer des agents de surveillance ou d’autres infrastructures de surveillance. Vous pouvez activer une surveillance approfondie des bases de données de vos ressources Azure SQL en quelques minutes.

Cet article contient des étapes détaillées pour la création, la configuration et le démarrage d’un observateur de base de données dans le Portail Azure.

Pour obtenir un exemple pas à pas de création et de configuration d’un observateur de base de données, consultez Démarrage rapide : créer un observateur de base de données pour surveiller Azure SQL.

Pour savoir comment créer et configurer un observateur de base de données avec Bicep ou un modèle ARM, consultez Créer un observateur de base de données.

Pour gérer les observateurs de base de données de manière programmatique, consultez la documentation de l’API REST de l’observateur de base de données.

Remarque

L’observateur de base de données est actuellement en aperçu. Les expériences et fonctionnalités en aperçu sont publiées avec des fonctionnalités limitées, mais sont mises à disposition sur un aperçu afin que les clients puissent obtenir un accès anticipé et fournir des commentaires. 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.

Prérequis

L’utilisation de l’observateur de base de données exige les prérequis suivants.

  • Vous aurez besoin d’un abonnement Azure actif. Si vous n’en avez pas, créez un compte gratuit. Pour pouvoir créer des ressources, vous devez être membre du rôle Contributeur ou du rôle Propriétaire de l’abonnement ou d’un groupe de ressources.

  • Pour configurer un observateur de base de données, vous aurez besoin d’une cible SQL existante : une base de données Azure SQL, un pool élastique ou une instance managée SQL.

  • Les fournisseurs de ressources Microsoft.DatabaseWatcher, Microsoft.Kusto et Microsoft.Network doivent être inscrits sur votre abonnement Azure.

    L’enregistrement du fournisseur de ressources est automatique si vous êtes membre du rôle RBACPropriétaire ou Contributeur au niveau de l’abonnement. Dans le cas contraire, un utilisateur ayant l’un de ces rôles doit inscrire les fournisseurs de ressources avant de pouvoir créer et configurer un observateur. Pour plus d’informations, consultez Inscrire un fournisseur de ressources.

  • L’utilisateur qui crée et configure l’observateur et les ressources du cluster Azure Data Explorer doit être membre du rôle RBAC Propriétaire ou Contributeur pour le groupe de ressources ou l’abonnement où ces ressources sont créées.

    En outre, si vous utilisez l’authentification SQL, l’utilisateur doit être soit un membre du rôle Propriétaire du groupe de ressources, soit membre du rôle Propriétaire ou Administrateur de l’accès utilisateur pour le coffre de clés qui stocke les identifiants SQL.

  • L’utilisateur qui configure l’observateur doit disposer d’un accès administrateur aux cibles Azure SQL. L’observateur se voit octroyer un accès limité et spécifique aux cibles de surveillance SQL. Pour plus d’informations, consultez Octroyer l’accès aux cible.

  • Pour octroyer à un observateur l’accès à une cible SQL, vous devez exécuter des scripts T-SQL. Vous pouvez utiliser SQL Server Management Studio (SSMS), Azure Data Studio ou Visual Studio Code avec l’extension mssql SQL Server.

  • Pour utiliser Azure Private Link pour la connectivité privée aux ressources Azure, l’utilisateur qui approuve le point de terminaison privé doit être membre du rôle RBAC Propriétaire, ou doit disposer des autorisations RBAC requises. Pour plus d’informations, consultez Approbation RBAC pour point de terminaison privé.

Créer un observateur

  1. Dans le Portail Azure, dans le menu de navigation, sélectionnez Tous les services. Sélectionnez Surveiller comme catégorie, puis sous Outils de surveillance, sélectionnez Observateur de base de données. Vous pouvez également saisir observateur de base de données dans la zone Rechercher en haut de la page du portail, puis sélectionner Observateur de base de données.

    Une fois la vue Observateur de base de données ouverte, sélectionnez Créer.

  2. Sous l’onglet Informations de base, sélectionnez l’abonnement et le groupe de ressources de l’observateur, saisissez le nom de l’observateur, puis sélectionnez une région Azure.

    Conseil

    Pendant la phase d’aperçu, si l’observateur de base de données n’est pas encore disponible dans votre région, vous pouvez le créer dans une autre région. Pour plus d’informations, consultez Disponibilité régionale.

  3. Sous l’onglet Identité, l’état de l’identité managée affectée par le système est Activé. Pour le moment, la création d’observateur sans identité managée affectée par le système n’est pas prise en charge.

  4. Choisissez un magasin de données pour l’observateur.

    Par défaut, la création d’un observateur crée également un cluster Azure Data Explorer et ajoute une base de données sur ce cluster comme magasin de données pour les données de surveillance collectées.

    • Par défaut, le nouveau cluster Azure Data Explorer utilise la référence SKU Très petit, Optimisé pour le calcul. Il s’agit de la SKU la plus économique offrant toujours un contrat de niveau de service (contrat SLA). Vous pouvez mettre à l’échelle ce cluster ultérieurement en fonction des besoins.

    • Vous pouvez également utiliser une base de données sur un cluster Azure Data Explorer existant, sur un cluster Azure Data Explorer gratuit ou dans l’Analyse en temps réel.

      1. Sous l’onglet Magasin de données, choisissez l’option Sélectionner un magasin de données, puis sélectionnez Ajouter.
      2. Sélectionnez une base de données d’Analyse en temps réel ou un cluster Azure Data Explorer.
      3. Si vous utilisez un cluster Azure Data Explorer existant, vous pouvez activer l’ingestion en streaming.
      4. Créer une base de données ou utiliser une base de données existante.

      Remarque

      Toute base de données existante que vous sélectionnez doit être vide ou doit être une base de données que vous avez précédemment utilisée comme magasin de données de l’observateur de base de données. La sélection d’une base de données qui contient des objets qui n’ont pas été créés par l’observateur de base de données n’est pas prise en charge.

  5. Sous l’onglet Cibles SQL, ajoutez une ou plusieurs ressources Azure SQL à surveiller. Vous pouvez ignorer l’ajout de cibles SQL lors de la création de l’observateur et les ajouter ultérieurement. L’ajout d’au moins une cible est requis avant de démarrer l’observateur.

  6. Sous l’onglet Vérifier + créer, passez en revue la configuration de l’observateur et sélectionnez Créer. Si vous sélectionnez l’option par défaut pour créer un cluster Azure Data Explorer, le déploiement prend généralement 15 à 20 minutes. Si vous sélectionnez une base de données sur un cluster Azure Data Explorer existant, sur un cluster Azure Data Explorer gratuit ou dans l’Analyse en temps réel, le déploiement prend généralement jusqu’à cinq minutes.

  7. Une fois le déploiement terminé, accordez à l’observateur l’accès aux cibles SQL.

    • L’accès à une base de données sur un cluster Azure Data Explorer nouveau ou existant est octroyé automatiquement lors de la création de l’observateur.
    • Toutefois, vous devez octroyer l’accès au magasin de données à l’aide d’une commande KQL si vous sélectionnez une base de données dans :
      • Analyse en temps réel dans Microsoft Fabric
      • Un cluster Azure Data Explorer gratuit

  8. Créez des points de terminaison privés managés si vous souhaitez utiliser la connectivité privée.

Démarrer et arrêter un observateur

Lorsqu’un observateur est créé, il n’est pas démarré automatiquement, car une configuration supplémentaire peut être requise.

Pour démarrer un observateur, il doit avoir :

  • Un magasin de données ;
  • Au minimum une cible ;
  • accès au magasin de données et aux cibles ;
    • accès à un coffre de clés, dans le cas où l’authentification SQL a été sélectionnée pour une cible ;
  • une connectivité privée ou publique aux cibles, au coffre de clés (si vous utilisez l’authentification SQL) et au magasin de données.

Lorsque l’observateur est entièrement configuré, cliquez sur le bouton Démarrer de la page Vue d’ensemble pour lancer la collection de données. En quelques minutes, les nouvelles données de surveillance apparaissent dans le magasin de données et sur les tableaux de bord. Si vous ne voyez pas de nouvelles données dans les cinq minutes, consultez Résolution des problèmes.

Vous pouvez arrêter l’observateur avec le bouton Arrêter si vous n’avez pas besoin de surveiller vos ressources Azure SQL pendant un certain temps.

Pour redémarrer un observateur, arrêtez-le puis redémarrez-le.

Modifier un observateur

Dans le Portail Azure, vous pouvez ajouter ou supprimer des cibles, créer ou supprimer des points de terminaison privés, ou utiliser un autre magasin de données pour un observateur existant.

Remarque

Sauf indication contraire, les modifications que vous apportez à la configuration de l’observateur n’entrent en vigueur qu’après l’arrêt et le redémarrage de l’observateur.

Ajouter des cibles SQL à un observateur

Pour activer la surveillance de l’observateur de base de données pour une base de données Azure SQL, un pool élastique ou une instance managée SQL, vous devez ajouter cette ressource en tant que cible SQL.

  1. Pour ajouter une cible, sur la page cibles SQL, sélectionnez Ajouter.
  2. Recherchez la ressource Azure SQL que vous souhaitez surveiller. Sélectionnez le type de ressource et l’abonnement, puis sélectionnez la cible SQL dans la liste des ressources. La cible SQL peut se trouver dans n’importe quel abonnement du même client Microsoft Entra ID que l’observateur.
  3. Pour surveiller le réplica principal et un réplica secondaire haute disponibilité d’une base de données, d’un pool élastique ou d’une instance managée SQL, ajoutez deux cibles distinctes pour la même ressource et cochez la case Intention de lecture pour l’une d’entre elles.
    • En cochant la case Intention de lecture, vous configurez l’observateur pour qu’il ne surveille que le réplica secondaire haute disponibilité.
    • Ne cochez pas la case Intention de lecture si vous souhaitez ne surveiller que le réplica primaire, ou si un réplica secondaire haute disponibilité n’existe pas pour cette ressource, ou encore si la fonctionnalité de Scale-out est désactivée.

Par défaut, l’observateur de bases de données utilise l’authentification Microsoft Entra pour se connecter aux cibles SQL. Si vous souhaitez que l’observateur utilise l’authentification SQL, cochez la case Utiliser l’authentification SQL et saisissez les informations requises. Pour plus d’informations, consultez Configuration supplémentaire pour utiliser l’authentification SQL.

Supprimer des cibles SQL d’un observateur

Pour supprimer une ou plusieurs cibles, ouvrez la page cibles SQL, sélectionnez les cibles que vous souhaitez supprimer dans la liste, puis sélectionnez Supprimer.

La suppression d’une cible arrête la surveillance d’une ressource Azure SQL une fois que l’observateur est redémarré, mais ne supprime pas la ressource elle-même.

Si vous supprimez une ressource Azure SQL surveillée par l’observateur de base de données, la cible correspondante doit également être supprimée. Comme il existe une limite au nombre de cibles SQL qu’un observateur peut avoir, le fait de conserver des cibles obsolètes peut vous empêcher d’ajouter de nouvelles cibles.

Créer un point de terminaison privé géré

Vous devez créer des points de terminaison privés managés si vous souhaitez utiliser la connectivité privée pour la collection de données à partir de cibles SQL, pour l’ingestion dans le magasin de données et pour la connexion à un coffre de clés. Si vous ne créez pas de points de terminaison privés, l’observateur de base de données utilise par défaut la connectivité publique.

Pour créer un point de terminaison privé managé :

  1. S’il existe un verrou de lecture seule sur la ressource, le groupe de ressources ou l’abonnement de la ressource pour lequel vous avez créé le point de terminaison privé managé, retirez le verrou. Vous pouvez remettre le verrou une fois que le point de terminaison privé est créé.

  2. Accédez à un observateur de base de données dans le Portail Azure, ouvrez la page Points de terminaison privés managés, puis sélectionnez Ajouter.

  3. Entrez un nom pour le point de terminaison privé.

  4. Sélectionnez l’abonnement de la ressource Azure pour laquelle vous souhaitez créer le point de terminaison privé.

  5. Selon la ressource pour laquelle vous souhaitez créer un point de terminaison privé, sélectionnez le Type de ressource et la Sous-ressource cible comme suit :

    Ressource Type de ressource Sous-ressource cible
    Serveur logique Microsoft.Sql/servers sqlServer
    SQL Managed Instance Microsoft.Sql/managedInstances managedInstance
    Cluster Azure Data Explorer Microsoft.Kusto/clusters cluster
    Key vault Microsoft.KeyVault/vaults vault

  6. Sélectionnez la ressource pour laquelle vous souhaitez créer un point de terminaison privé. Il peut s’agir d’un serveur logique Azure SQL ou d’une instance managée SQL, d’un cluster Azure Data Explorer ou d’un coffre de clés.

    • La création d’un point de terminaison privé pour un serveur logique Azure SQL Database active la connectivité privée de l’observateur de base de données pour toutes les cibles de base de données et de pool élastique sur ce serveur.

  7. Si vous le désirez, saisissez la description du point de terminaison privé. Cela peut aider le propriétaire de ressource à approuver la demande.

  8. Sélectionnez Créer. La création d’un point de terminaison privé peut prendre une à deux minutes. Un point de terminaison privé n’est créé qu’une fois que son état d’approvisionnement passe d’Accepté ou En cours d’exécution à Réussi. Actualisez l’affichage pour voir l’état d’approvisionnement actuel.

    Important

    Le point de terminaison privé est créé dans l’état En attente. Il doit être approuvé par le propriétaire de ressource avant que l’observateur de base de données puisse l’utiliser pour se connecter à la ressource.

    Pour permettre aux propriétaires de ressources de contrôler la connectivité réseau, les points de terminaison privés de l’observateur de base de données ne sont pas approuvés automatiquement.

  9. Le propriétaire de la ressource doit approuver la demande de point de terminaison privé.

    • Dans le Portail Azure, le propriétaire de ressource doit rechercher Liaison privée pour ouvrir le Centre Private Link. Sous Connexions en attente, recherchez le point de terminaison privé que vous avez créé, confirmez sa description et ses détails, puis sélectionnez Approuver.
    • Vous pouvez également approuver des demandes de point de terminaison privé en utilisant Azure CLI.

Si un observateur est déjà en cours d’exécution lorsqu’un point de terminaison privé est approuvé, l’’observateur doit être redémarré pour commencer à utiliser la connectivité privée.

Supprimer un point de terminaison privé managé

  1. S’il existe un verrou de suppression sur la ressource, le groupe de ressources ou l’abonnement de la ressource pour lequel vous avez supprimé le point de terminaison privé managé, retirez le verrou. Vous pouvez remettre le verrou une fois que le point de terminaison privé est supprimé.
  2. Sur la page du Portail Azure de votre observateur de base de données, ouvrez la page Points de terminaison privés managés.
  3. Sélectionnez le point de terminaison privé que vous souhaitez supprimer.
  4. Sélectionnez Supprimer.

La suppression d’un point de terminaison privé managé arrête la collection de données à partir de cibles SQL qui utilisent ce point de terminaison privé. La suppression du point de terminaison privé managé pour le cluster Azure Data Explorer arrête la collection de données pour toutes les cibles. Pour reprendre la collection de données, recréez le point de terminaison privé ou activez la connectivité publique, puis redémarrez l’observateur.

Modifier le magasin de données d’un observateur

Un observateur ne peut avoir qu’un seul magasin de données.

Pour modifier le magasin de données actuel, supprimez le magasin de données existant, puis ajoutez un nouveau magasin de données.

  • Pour supprimer le magasin de données actuel, ouvrez la page Magasin de données, sélectionnez le magasin de données dans la grille, puis sélectionnez Supprimer.

    • La suppression d’un magasin de données ne supprime pas la base de données du magasin de données elle-même sur un cluster Azure Data Explorer ou dans l’Analyse en temps réel dans Microsoft Fabric.
    • Pour arrêter la collection de données dans un magasin de données supprimé, arrêtez l’observateur.
    • Si vous supprimez un magasin de données, vous devez ajouter un nouveau magasin de données avant de pouvoir redémarrer l’observateur.

  • Pour ajouter un magasin de données, sélectionnez Ajouter sur la page Magasin de données, puis sélectionnez ou créez une base de données sur un cluster Azure Data Explorer, ou dans l’Analyse en temps réel.

    • La base de données que vous sélectionnez doit être vide ou doit être une base de données que vous avez précédemment utilisée comme magasin de données de l’observateur de base de données. La sélection d’une base de données qui contient des objets qui n’ont pas été créés par l’observateur de base de données n’est pas prise en charge.
    • Une fois que vous avez ajouté un magasin de données, vous devez octroyer à l’observateur l’accès pour qu’il puisse l’utiliser. Pour plus d’informations, consultez Octroyer l’accès au magasin de données.
    • Le nouveau magasin de données n’est utilisé qu’une fois l’observateur redémarré.

Supprimer un observateur

S’il existe un verrou sur l’observateur, son groupe de ressources ou son abonnement, supprimez le verrou. Vous pouvez remettre le verrou une fois que l’observateur est supprimé.

Lorsque vous supprimez un observateur, son identité managée affectée par le système est également supprimée. Cela supprime tout accès que vous avez octroyé à cette identité. Si vous recréez l’observateur ultérieurement, vous devez octroyer l’accès à l’identité managée affectée par le système du nouvel observateur pour vous authentifier auprès de chaque ressource. notamment :

Vous devez octroyer l’accès à un observateur recréé, même si vous utilisez le même nom d’observateur.

Lorsque vous supprimez un observateur, les ressources Azure référencées en tant que cibles et magasin de données ne sont pas supprimées. Vous conservez les données de surveillance SQL collectées dans le magasin de données et vous pouvez utiliser la même base de données que celle du magasin de données si vous créez un observateur ultérieurement.

Octroyer l’accès aux cibles SQL

Pour permettre à un observateur de collecter des données de surveillance SQL, vous devez exécuter un script T-SQL qui octroie les autorisations SQL spécifiques et limitées à l’observateur.

  • Pour exécuter ce script dans Azure SQL Database, vous avez besoin d’un accès de type administrateur du serveur au serveur logique contenant les bases de données et les pools élastiques que vous souhaitez surveiller.

    • Dans Azure SQL Database, vous ne devez exécuter ce script qu’une seule fois par serveur logique pour chaque observateur que vous créez. Cela octroie à l’observateur l’accès à toutes les bases de données et pools élastiques existants et nouveaux sur ce serveur.

  • Pour exécuter ce script dans Azure SQL Managed Instance, vous devez être membre du rôle serveur sysadmin ou securityadmin, ou disposer de l’autorisation serveur CONTROL sur l’instance managée SQL.

    • Dans Azure SQL Managed Instance, vous devez exécuter le script sur chaque instance que vous souhaitez surveiller.

  1. Accédez à l’observateur dans le Portail Azure, sélectionnez Cibles SQL, sélectionnez l’un des liens Octroyer l’accès pour ouvrir le script T-SQL, puis copiez le script. Veillez à choisir le lien approprié pour votre type de cible et le type d’authentification que vous souhaitez utiliser.

    Important

    Le script d’authentification Microsoft Entra dans le Portail Azure est spécifique à un observateur, car il inclut le nom de l’observateur. Pour obtenir une version générique de ce script que vous pouvez personnaliser pour chaque observateur, consultez Octroyer l’accès aux cibles SQL avec des scripts T-SQL.

  2. Dans SQL Server Management Studio, Azure Data Studio ou tout autre outil client SQL, ouvrez une nouvelle fenêtre de requête et connectez-la à la base de données master sur un serveur logique Azure SQL contenant la cible ou à la base de données master sur une cible d’instance managée SQL.

  3. Collez et exécutez le script T-SQL pour octroyer l’accès à l’observateur. Ce script crée une connexion que l’observateur utilisera pour se connecter et octroie des autorisations spécifiques et limitées pour collecter des données de surveillance.

    1. Si vous utilisez un script d’authentification Microsoft Entra, l’observateur doit déjà exister lorsque vous exécutez le script. En outre, vous devez être connecté au moyen de l’authentification Microsoft Entra.

Si vous ajoutez de nouvelles cibles à un observateur ultérieurement, vous devez octroyer l’accès à ces cibles de manière similaire, sauf si ces cibles se trouvent sur un serveur logique pour lequel l’accès a déjà été octroyé.

Octroyer l’accès aux cibles SQL avec des scripts T-SQL

Il existe différents scripts pour l’authentification Microsoft Entra et l’authentification SQL, et pour les cibles Azure SQL Database et Azure SQL Managed Instance.

Important

Utilisez toujours les scripts fournis pour octroyer l’accès à l’observateur de base de données. L’octroi d’un accès différent peut bloquer la collection de données. Pour plus d’informations, consultez Autorisation de l’observateur.

Avant d’exécuter un script, remplacez toutes les instances d’espaces réservés qui peuvent être présents dans le script, telles que login-name-placeholder, user-name-placeholder et password-placeholder par les valeurs réelles.

Octroyer l’accès aux observateurs authentifiés Microsoft Entra

Ce script crée une connexion d’authentification Microsoft Entra (anciennement appelé Azure Active Directory) sur un serveur logique dans Azure SQL Database. La connexion est créée pour l’identité managée d’un observateur. Le script octroie à l’observateur les autorisations nécessaires et suffisantes pour collecter les données de surveillance à partir de toutes les bases de données et pools élastiques sur le serveur logique.

Vous devez utiliser le nom de l’observateur comme nom de connexion. Le script doit être exécuté dans la base de données master sur le serveur logique. Vous devez être connecté au moyen d’une connexion d’authentification Microsoft Entra de type administrateur du serveur.

CREATE LOGIN [watcher-name-placeholder] FROM EXTERNAL PROVIDER;

ALTER SERVER ROLE ##MS_ServerPerformanceStateReader## ADD MEMBER [watcher-name-placeholder];
ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER [watcher-name-placeholder];
ALTER SERVER ROLE ##MS_DatabaseConnector## ADD MEMBER [watcher-name-placeholder];

Octroyer l’accès aux observateurs authentifiés SQL

Des étapes supplémentaires sont requises lors de l’utilisation de l’authentification SQL, consultez Configuration supplémentaire pour utiliser l’authentification SQL.

Ce script crée une connexion d’authentification SQL sur un serveur logique dans Azure SQL Database. Il octroie à la connexion les autorisations nécessaires et suffisantes pour collecter les données de surveillance à partir de toutes les bases de données et pools élastiques sur le serveur logique.

Le script doit être exécuté dans la base de données master sur le serveur logique, à l’aide d’une connexion qui est un administrateur du serveur logique.

CREATE LOGIN [login-name-placeholder] WITH PASSWORD = 'password-placeholder';

ALTER SERVER ROLE ##MS_ServerPerformanceStateReader## ADD MEMBER [login-name-placeholder];
ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER [login-name-placeholder];
ALTER SERVER ROLE ##MS_DatabaseConnector## ADD MEMBER [login-name-placeholder];

Configuration supplémentaire pour l’utilisation de l’authentification SQL

Pour stocker les identifiants d’authentification en toute sécurité, l’utilisation de l’authentification SQL dans l’observateur de base de données nécessite une configuration supplémentaire.

Conseil

Pour une configuration plus sécurisée, plus simple et moins sujette aux erreurs, nous vous recommandons d’activer l’authentification Microsoft Entra pour vos ressources Azure SQL et de l’utiliser au lieu de l’authentification SQL.

Pour configurer l’observateur de base de données pour se connecter à une cible à l’aide de l’authentification SQL, procédez comme suit :

  1. Créez un coffre dans Azure Key Vault ou identifiez un coffre existant que vous pouvez utiliser. Le coffre doit utiliser le modèle d’autorisation RBAC. Le modèle d’autorisation RBAC est la valeur par défaut des nouveaux coffres. Si vous souhaitez utiliser un coffre existant, assurez-vous qu’il n’est pas configuré pour utiliser l’ancien modèle de stratégie d’accès.

    Si vous souhaitez utiliser la connectivité privée au coffre, créez un point de terminaison privé sur la page Points de terminaison privés managés. Sélectionnez Microsoft.KeyVault/vaults comme Type de ressource et vault comme Sous-ressource cible. Assurez-vous que le point de terminaison privé est approuvé avant de démarrer l’observateur.

    Si vous souhaitez utiliser la connectivité publique, le coffre doit disposer d’un accès public à partir de tous les réseaux activés. La restriction de la connectivité du coffre public à des réseaux spécifiques n’est pas prise en charge par l’observateur de base de données.

  2. Créez une connexion d’authentification SQL sur chaque serveur logique Azure SQL ou instance managée que vous souhaitez surveiller et octroyez les autorisations requises. Utilisez les scripts d’accès fournis pour l’authentification SQL et remplacez le nom de connexion, le nom d’utilisateur et le mot de passe par les valeurs réelles. Utilisez un mot de passe fort.

  3. Dans le coffre, créez deux secrets : un secret pour le nom de connexion et un secret distinct pour le mot de passe. Utilisez n’importe quel nom valide comme nom de secret et saisissez le nom de connexion ou le mot de passe que vous avez utilisé dans le script T-SQL comme valeur secrète.

    Par exemple, les noms des deux secrets peuvent être database-watcher-login-name et database-watcher-password. Les valeurs des secrets sont un nom de connexion et un mot de passe fort.

    Pour créer des secrets, vous devez être membre du rôle RBAC d’agent des secrets du coffre de clés.

  4. Sur la page Contrôle d’accès (IAM) de chaque secret, ajoutez une attribution de rôle pour l’identité managée de l’observateur dans le rôle RBAC d’agent des secrets du coffre de clés. Pour suivre le principe du moindre privilège, ajoutez cette attribution de rôle pour chaque secret, plutôt que pour l’intégralité du coffre. La page Contrôle d’accès (IAM) s’affiche uniquement si le coffre est configuré pour utiliser le modèle d’autorisation RBAC.

  5. Ajoutez la cible SQL à un observateur. Lors de l’ajout d’une cible, cochez la case Utiliser l’authentification SQL, puis sélectionnez le coffre dans lequel sont stockés les secrets du nom de connexion et du mot de passe. Saisissez les noms de secrets pour le nom de connexion et le mot de passe.

    Lors de l’ajout d’une cible SQL, ne saisissez pas le nom de connexion et le mot de passe réels. À l’aide de l’exemple précédent, vous devez entrer les noms de secrets database-watcher-login-name et database-watcher-password.

Si vous souhaitez utiliser des connexions différentes sur des cibles SQL distinctes, vous pouvez utiliser le même coffre pour stocker tous les secrets.

Remarque

Si vous mettez à jour la valeur secrète d’un nom de connexion ou d’un mot de passe dans le coffre de clés alors qu’un observateur est en cours d’exécution, ce dernier se reconnecte aux cibles à l’aide des nouveaux identifiants d’authentification SQL dans un délai de 15 minutes. Si vous souhaitez commencer à utiliser les nouveaux identifiants immédiatement, arrêtez et redémarrez l’observateur.

Octroyer l’accès au magasin de données

Pour créer et gérer le schéma de base de données au fil du temps et pour ingérer des données de surveillance, l’observateur de base de données Pour créer et gérer le schéma de la base de données au fil du temps, et pour ingérer les données de surveillance, l’observateur de base de données doit être membre du rôle RBAC Administrateurs dans la base de données du magasin de données. L’observateur de base de données ne nécessite aucun accès au niveau du cluster Azure Data Explorer ou tout accès à d’autres bases de données qui peuvent exister sur le même cluster.

Si vous créez un cluster et une base de données Azure Data Explorer ou sélectionnez une base de données sur un cluster existant lors de la création d’un observateur, cet accès est octroyé automatiquement si l’utilisateur qui crée l’observateur est membre du rôle RBAC Propriétaire du cluster.

Si vous modifiez le magasin de données d’un observateur existant ou si vous utilisez une base de données d’Analyse en temps réel ou une base de données sur un cluster Azure Data Explorer gratuit, vous devez accorder l’accès comme décrit dans cette section.

Octroyer l’accès à une base de données Azure Data Explorer à l’aide du Portail Azure

Vous pouvez utiliser le Portail Azure pour octroyer l’accès à une base de données sur le cluster Azure Data Explorer :

  1. Pour une base de données sur un cluster Azure Data Explorer, dans le menu de ressources sous Sécurité + mise en réseau, sélectionnez Autorisations. N’utilisez pas la page Autorisations du cluster.
  2. Sélectionnez Ajouter, puis sélectionnez Administrateur.
  3. Sur la page Nouveaux principaux, sélectionnez Applications d’entreprise et saisissez le nom de l’observateur dans la zone Rechercher.
  4. Sélectionnez l’application d’entreprise portant le même nom que l’observateur.

Octroyer l’accès à une base de données Azure Data Explorer en utilisant KQL

Au lieu d’utiliser le Portail Azure, vous pouvez également octroyer l’accès à la base de données à l’aide d’une commande KQL.

  1. Connectez-vous à une base de données sur le cluster Azure Data Explorer à l’aide de Kusto Explorer ou de l’interface utilisateur Web d’Azure Data Explorer. Utilisez cette méthode pour octroyer l’accès à une base de données d’Analyse en temps réel ou une base de données sur un cluster Azure Data Explorer gratuit.

  2. Dans la commande suivante, remplacez ces espaces réservés :

    .add database [adx-database-name-placeholder] admins ('aadapp=watcher-object-id-placeholder;tenant-primary-domain-placeholder');
    Paramètre substituable Remplacement
    adx-database-name-placeholder Nom d’une base de données sur un cluster Azure Data Explorer ou dans l’Analyse en temps réel.
    watcher-object-id-placeholder Valeur d’ID d’objet (principal) (GUID), trouvée sur la page Identité de l’observateur.
    tenant-primary-domain-placeholder Nom de domaine du client Microsoft Entra ID de l’observateur. Vous trouverez cette information sur la page Vue d’ensemble de Microsoft Entra ID dans le Portail Azure. Au lieu du domaine principal du client, vous pouvez également utiliser la valeur GUID de l’ID du client.

    Vous pouvez omettre cette partie de la commande (ainsi que le point-virgule précédent) si l’observateur et le cluster Azure Data Explorer se trouvent dans le même client Microsoft Entra ID.

    Par exemple :

    .add database [watcher_data_store] admins ('aadapp=9da7bf9d-3098-46b4-bd9d-3b772c274931;contoso.com');

Pour plus d’informations, consultez Contrôle d’accès en fonction du rôle Kusto.

Octroyer aux utilisateurs et aux groupes l’accès au magasin de données

Vous pouvez utiliser le Portail Azure ou une commande KQL pour octroyer aux utilisateurs et aux groupes l’accès à une base de données sur un cluster Azure Data Explorer ou dans l’Analyse en temps réel. Pour octroyer l’accès, vous devez être membre du rôle RBAC Administrateur dans la base de données.

Utilisez une commande KQL pour accorder l’accès à une base de données sur le cluster Azure Data Explorer gratuit ou dans l’Analyse en temps réel. Pour suivre le principe du moindre privilège, nous vous recommandons de ne pas ajouter d’utilisateurs et de groupes à un rôle RBAC autre que celui de Viewer.

Important

Examinez attentivement vos exigences de confidentialité et de sécurité des données lors de l’octroi de l’accès pour afficher les données de surveillance SQL collectées par l’observateur de base de données.

Même si l’observateur de base de données n’a pas la possibilité de collecter des données stockées dans des tables utilisateur dans vos bases de données SQL, certains jeux de données tels que Sessions actives, Métadonnées d’index, Index manquants, Statistiques d’exécution de requête, Statistiques d’attente des requêtes, Statistiques de session et Métadonnées de table peuvent contenir des données potentiellement sensibles, telles que les noms de table et d’index, le texte de requête, les valeurs des paramètres de requête, les noms de connexion, etc.

En octroyant l’accès à la visualisation du magasin de données à un utilisateur qui n’a pas accès à ces données dans une base de données SQL, vous pouvez leur permettre d’accéder à des données sensibles qu’ils ne seraient pas en mesure de consulter autrement.

Octroyer l’accès au magasin de données à l’aide du Portail Azure

Vous pouvez utiliser le Portail Azure pour octroyer aux utilisateurs et aux groupes l’accès à une base de données sur le cluster Azure Data Explorer :

  1. Pour une base de données dans un cluster Azure Data Explorer, dans le menu de ressources sous Sécurité + mise en réseau, sélectionnez Autorisations. N’utilisez pas la page Autorisations du cluster.
  2. Sélectionnez Ajouter, puis sélectionnez Viewers.
  3. Sur la page Nouveaux principaux, saisissez le nom de l’utilisateur ou du groupe dans la zone de Rechercher.
  4. Sélectionnez l’utilisateur ou le groupe.

Octroyer l’accès au magasin de données en utilisant KQL

Au lieu d’utiliser le Portail Azure, vous pouvez également octroyer aux utilisateurs et aux groupes l’accès à la base de données au moyen d’une commande KQL. L’exemple de commande KQL suivant octroie l’accès en lecture aux données à l’utilisateur mary@contoso.com et au groupe SQLMonitoringUsers@contoso.com d’un client Microsoft Entra ID avec une valeur d’ID de client spécifique :

.add database [watcher_data_store] viewers ('aaduser=mary@contoso.com');

.add database [watcher_data_store] viewers ('aadgroup=SQLMonitoringUsers@contoso.com;8537e70e-7fb8-43d3-aac5-8b30fb3dcc4c');

Pour plus d’informations, consultez Contrôle d’accès en fonction du rôle Kusto.

Pour octroyer l’accès au magasin de données aux utilisateurs et groupes d’un autre client, vous devez activer l’authentification interlocataire sur votre cluster Azure Data Explorer. Pour plus d’informations sur les scénarios interlocataires, consultez Autoriser les requêtes et commandes interlocataires.

Conseil

L’authentification interlocataire est activée dans l’Analyse en temps réel et sur des clusters Azure Data Explorer gratuits. Cela vous permet d’octroyer l’accès aux utilisateurs et aux groupes de votre client Microsoft Entra ID pour afficher les données de ces bases de données.

Gérer le magasin de données

Cette section décrit comment gérer le magasin de données de surveillance, notamment la mise à l’échelle, la conservation des données et d’autres configurations. Les considérations relatives à la mise à l’échelle du cluster dans cette section sont pertinentes si vous utilisez une base de données sur le cluster Azure Data Explorer. Si vous utilisez une base de données dans l’Analyse en temps réel dans Fabric, la mise à l’échelle est gérée automatiquement.

Mettre à l’échelle un cluster Azure Data Explorer

Vous pouvez mettre à l’échelle votre cluster Azure Data Explorer en fonction des besoins. Par exemple, vous pouvez effectuer un scale-down de votre cluster vers la référence SKU Très petit, Dev/test si un contrat de niveau de service (contrat SLA) n’est pas nécessaire, et si les performances d’ingestion des données et des requêtes restent acceptables.

Pour de nombreux déploiements de l’observateur de base de données, la référence SKU par défaut Très petit, Optimisé pour le calcul en cluster à 2 instances est suffisante, et ce indéfiniment. Dans certains cas, selon vos modifications de configuration et de charge de travail au fil du temps, vous devrez peut-être mettre à l’échelle votre cluster pour garantir des performances de requête adéquates et maintenir une faible latence d’ingestion des données.

Azure Data Explorer prend en charge la mise à l’échelle verticale et horizontale des clusters. Avec la mise à l’échelle (montée en charge) verticale, vous modifiez la référence SKU du cluster, ce qui modifie le nombre de processeurs virtuels, de mémoire et de cache par instance (nœud). Avec la mise à l’échelle horizontale (Scale-out), la référence SKU reste la même, mais le nombre d’instances du cluster est augmenté ou diminué.

Vous devez effectuer un Scale-out de votre cluster (horizontalement) ou une montée en charge (verticalement) si vous remarquez un ou plusieurs des symptômes suivants :

  • Les performances des requêtes ad hoc ou du tableau de bord ralentissent.
  • Vous exécutez de nombreuses requêtes simultanées sur votre cluster et observez les erreurs de limitation.
  • La latence d’ingestion des données augmente de façon constante et inacceptable.

En général, vous n’avez pas besoin de mettre à l’échelle votre cluster à mesure que la quantité de données dans le magasin de données augmente au fil du temps. Cela est dû au fait que les requêtes de tableau de bord et les requêtes analytiques les plus courantes n’utilisent que les données les plus récentes, qui sont mises en cache dans le stockage SSD local sur les nœuds de cluster.

Toutefois, si vous exécutez des requêtes analytiques couvrant des intervalles de temps plus longs, elles peuvent devenir plus lentes au fil du temps, car la quantité totale de données collectées augmente et ne tient plus dans le stockage SSD local. Dans ce cas, la mise à l’échelle du cluster peut être nécessaire pour maintenir des performances de requêtes adéquates.

  • Si vous devez mettre à l’échelle votre cluster, nous vous recommandons de commencer par le mettre à l’échelle horizontalement pour augmenter le nombre d’instances. Le cluster reste ainsi disponible pour les requêtes et l’ingestion pendant le processus de mise à l’échelle.

    • Vous pouvez activer la mise à l’échelle automatique optimisée pour réduire ou augmenter automatiquement le nombre d’instances en réponse aux changements de charge de travail ou aux tendances saisonnières.

  • Vous pouvez constater que même après avoir mis à l’échelle le cluster horizontalement, certaines requêtes ne s’exécutent toujours pas comme prévu. Cela peut se produire si les performances des requêtes sont limitées par les ressources disponibles sur une instance (nœud) du cluster. Dans ce cas, effectuez un scale-up vertical du cluster.

    • La mise à l’échelle verticale du cluster prend plusieurs minutes. Au cours de ce processus, la collection de données peut être interrompue pendant une période d’indisponibilité. Si cela se produit, arrêtez et redémarrez votre observateur une fois l’opération de mise à l’échelle terminée.

Vous ne pouvez pas mettre à l’échelle un cluster Azure Data Explorer gratuit. Si vous jugez que les spécifications du cluster gratuit sont insuffisantes pour vos besoins, effectuez une mise à niveau vers un cluster Azure Data Explorer complet. Le processus de mise à niveau conserve toutes les données collectées. Étant donné qu’il peut y avoir un temps d’arrêt pendant la mise à niveau, vous devrez peut-être arrêter et redémarrer votre observateur pour reprendre la collection de données une fois la mise à niveau terminée.

Gérer la conservation des données

Si vous n’avez pas besoin des anciennes données, vous pouvez configurer des stratégies de rétention des données pour supprimer définitivement ces anciennes données. Par défaut, la conservation des données est définie sur 365 jours dans une nouvelle base de données sur un cluster Azure Data Explorer ou dans l’Analyse en temps réel.

  • Vous pouvez réduire la période de conservation des données au niveau de la base de données ou pour des tables individuelles dans la base de données.
  • Vous pouvez également augmenter la période de conservation si vous devez stocker les données de surveillance pendant plus d’un an. Il n’existe aucune limite supérieure à la période de conservation des données.
  • Si vous configurez différentes périodes de conservation des données pour différentes tables, les tableaux de bord peuvent ne pas fonctionner comme prévu pour les intervalles de temps plus anciens. Cela peut se produire si les données sont toujours présentes dans certaines tables, mais qu’elles sont déjà supprimées définitivement dans d’autres tables pendant le même intervalle de temps.

Schéma et modifications d’accès dans le magasin de données de l’observateur de base de données

Au fil du temps, Microsoft peut introduire de nouveaux jeux de données de l’observateur de base de données ou développer des jeux de données existants. Cela signifie que de nouvelles tables dans le magasin de données ou de nouvelles colonnes dans des tables existantes peuvent être ajoutées automatiquement.

Pour ce faire, l’identité managée d’un observateur de base de données doit être membre du rôle RBAC Administrateurs dans le magasin de données. La révocation de l’appartenance à ce rôle ou son remplacement par l’appartenance à n’importe quel autre rôle RBAC peut avoir un impact sur la collection de données de l’observateur de base de données et la gestion des schémas et n’est pas prise en charge.

De même, la création d’objets tels que des tables, des tables externes, des vues matérialisées, des fonctions, etc. dans le magasin de données de l’observateur de base de données n’est pas prise en charge. Vous pouvez utiliser des requêtes entre clusters et entre bases de données pour interroger des données dans votre magasin de données à partir d’autres clusters Azure Data Explorer ou à partir d’autres bases de données sur le même cluster.

Important

Si vous modifiez l’accès de l’observateur de base de données à son magasin de données ou apportez des modifications de schéma ou de configuration de base de données qui affectent l’ingestion des données, vous devrez peut-être modifier le magasin de données pour cet observateur vers une nouvelle base de données vide et accorder à l’observateur l’accès à cette nouvelle base de données pour reprendre la collection de données et rétablir une configuration prise en charge.

Clusters Azure Data Explorer arrêtés

Un cluster Azure Data Explorer peut être arrêté, par exemple pour réduire les coûts. Par défaut, un cluster Azure Data Explorer crée dans le portail Azure est arrêté automatiquement après plusieurs jours d’inactivité. Par exemple, cela peut se produire si vous arrêtez l’observateur qui ingère des données dans la seule base de données de votre cluster et n’exécutez aucune requête dans cette base de données.

Si vous utilisez l’option par défaut pour créer un cluster Azure Data Explorer lors de la création d’un observateur, le comportement d’arrêt automatique est désactivé pour autoriser la collection de données ininterrompue.

Si le cluster est arrêté, la collecte de données de l’observateur de base de données s’arrête également et les données de surveillance ne s’affichent pas sur les tableaux de bord. Pour reprendre la collecte de données et rendre les données accessibles via des tableaux de bord, vous devez reprendre manuellement le cluster. Une fois le cluster en cours d’exécution, redémarrez l’observateur.

Vous pouvez désactiver le comportement d’arrêt automatique si vous souhaitez que le cluster reste disponible même s’il est inactif. Cela peut augmenter le coût du cluster.

Ingestion de streaming

L’observateur de base de données nécessite que le cluster Azure Data Explorer contenant la base de données du magasin de données ait activé l’ingestion en streaming. L’ingestion en streaming est automatiquement activée pour le cluster Azure Data Explorer créé lorsque vous créez un observateur. Il est également activé dans l’Analyse en temps réel et sur le cluster Azure Data Explorer gratuit.

Si vous souhaitez utiliser un cluster Azure Data Explorer existant, veillez d’abord à activer l’ingestion en streaming. Cela prend quelques minutes et nécessite un redémarrage du cluster.

Surveiller les grands patrimoines

Pour surveiller un grand patrimoine Azure SQL, vous devrez peut-être créer plusieurs observateurs.

Chaque observateur nécessite une base de données sur un cluster Azure Data Explorer ou dans l’Analyse en temps réel comme magasin de données. Les observateurs que vous créez peuvent utiliser une base de données unique comme magasin de données commun ou des bases de données séparées en tant que magasins de données distincts. Les considérations suivantes peuvent vous aider à faire un choix de conception optimal pour vos scénarios et exigences de surveillance.

Considérations relatives à un magasin de données commun :

  • Il existe une vue à volet unique de l’ensemble de votre patrimoine Azure SQL.
  • Toutefois, les utilisateurs ayant accès au magasin de données ont accès à toutes les données de surveillance.

Considérations relatives aux magasins de données distincts :

  • Les sous-ensembles de votre patrimoine Azure SQL sont surveillés indépendamment. Les tableaux de bord de patrimoine dans le Portail Azure affichent les données d’un magasin de données unique. Les utilisateurs ayant accès à plusieurs magasins de données peuvent utiliser des requêtes KQL entre clusters ou entre bases de données pour accéder aux données de surveillance dans plusieurs magasins de données au moyen d’une seule requête.
  • Étant donné que l’accès aux données dans Azure Data Explorer et dans l’Analyse en temps réel est géré par base de données, vous pouvez gérer l’accès aux données de surveillance des sous-ensembles de votre patrimoine de manière granulaire.
  • Vous pouvez placer plusieurs bases de données sur le même cluster Azure Data Explorer pour partager des ressources de cluster et économiser des coûts, tout en conservant les données isolées dans chaque base de données.
  • Si vous avez besoin d’une séparation complète des environnements, y compris l’accès réseau aux clusters Azure Data Explorer, vous pouvez placer différentes bases de données sur différents clusters.

Contenu connexe