Partage via

Créer et configurer un observateur de base de données (préversion)

  • Article

S'applique à : Azure SQL DatabaseAzure SQL Managed Instance

Cet article contient les étapes détaillées pour créer, configurer et démarrer un observateur de base de données dans le Portail Azure pour Azure SQL Database et Azure 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 de la base de données de vos ressources Azure SQL en quelques minutes.

Pour obtenir un exemple pas à pas simplifié 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 l’exemple de code Créer un observateur de base de données.

Pour définir des surveillants à l’aide d’Infrastructure as Code (Bicep, modèles ARM, Terraform AzAPI), consultez la documentation de référence des ressources Azure .

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

Après avoir créé et configuré un observateur en suivant les étapes décrites dans cet article, vous pouvez utiliser des alertes Azure Monitor. Pour plus d’informations, consultez Alertes d’observateur de base de données.

Remarque

L’observateur de base de données est actuellement en préversion.

Prérequis

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

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

  • Pour configurer et démarrer un observateur de base de données, vous avez besoin d’une cible SQL existante : une base de données Azure SQL, un pool de base de données élastique ou une instance gérée SQL.

  • Les fournisseurs de ressources Microsoft.DatabaseWatcher, Microsoft.Kusto et Microsoft.Network doivent être enregistrés dans votre abonnement Azure.

    • Le fournisseur de ressources Microsoft.KeyVault doit également être enregistré afin d’utiliser l’authentification SQL pour les connexions à vos ressources Azure SQL. Consultez Configuration supplémentaire pour utiliser l’authentification SQL.
    • Pour créer des règles d’alerte, le fournisseur de ressources Microsoft.Insights doit également être inscrit.

    L’enregistrement du fournisseur de ressources est automatique si vous êtes membre du rôle RBAC Propriétaire ou Contributeur au niveau de l’abonnement. Dans le cas contraire, un utilisateur de l’un de ces rôles doit enregistrer les fournisseurs de ressources avant de pouvoir créer et configurer un observateur. Pour plus d’informations, consultez Enregistrer 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 membre du rôle Propriétaire pour le groupe de ressources, ou membre du rôle Propriétaire ou Administrateur de l’accès utilisateur pour le coffre de clés qui stocke les identifiants d’authentification SQL.

  • L’utilisateur qui configure l’observateur doit disposer d’un accès administrateur aux cibles Azure SQL. Un administrateur permet à l’observateur un accès limité et spécifique aux cibles SQL Monitoring. Pour plus d’informations, consultez Permettre d'accéder aux cibles.

  • Pour accorder à un observateur l’accès à une cible SQL, un administrateur doit exécuter des scripts T-SQL à l’aide de SQL Server Management Studio (SSMS), Visual Studio Code avec l’extension sql server mssql ou d’autres outils clients SQL.

  • Pour utiliser Azure Private Link pour une 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 les points de terminaison privés.

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 Observateurs de base de données. Vous pouvez également saisir observateur de base de données dans la zone Recherche en haut de la page du portail, puis sélectionner Observateurs de base de données.

    Une fois l’affichage Observateurs de base de données ouvert, sélectionnez Créer.

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

    Conseil

    Pendant la phase de préversion, 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. Dans l’onglet Identité, l’identité managée affectée par le système de l’observateur est activée par défaut. Si vous souhaitez que l’observateur utilise plutôt une identité managée affectée par l’utilisateur, sélectionnez le bouton Ajouter, recherchez l’identité que vous souhaitez utiliser, puis sélectionnez le bouton Ajouter. Pour rendre l’identité affectée par l’utilisateur effective pour l’observateur, désactivez l’identité managée affectée par le système.

    Pour plus d’informations sur les identités managées dans l’observateur de base de données, consultez Modifier l’identité de l’observateur.

  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 Extra small, optimisée pour le calcul. Il s’agit de la référence SKU la plus économique offrant néanmoins un Contrat de niveau de service (Service Level Agreement/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 Analytique en temps réel.

      1. Dans 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 Analytique en temps réel ou un cluster Azure Data Explorer.
      3. Si vous utilisez un cluster Azure Data Explorer existant, vous devez activer Ingestion de streaming.
      4. Créez une nouvelle base de données ou utilisez 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 d’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.

    • Vous pouvez également ignorer l’ajout d’un magasin de données à ce stade et l’ajouter ultérieurement. Un magasin de données est requis pour démarrer l’observateur.

  5. Dans 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. Vous devez ajouter au moins une cible avant de démarrer l’observateur.

  6. Dans l’onglet Vérifier + créer, passez en revue la configuration de l’observateur, puis sélectionnez Créer. Si vous sélectionnez l’option par défaut pour créer un nouveau 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 Analytique en temps réel, le déploiement prend généralement jusqu’à cinq minutes.

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

  8. Vous devrez peut-être également octroyer à l’observateur un accès au magasin de données.

    • L’accès à une base de données sur un cluster Azure Data Explorer nouveau ou existant est octroyé automatiquement lorsque l’observateur est créé si l’utilisateur qui crée l’observateur est membre du rôle RBAC Propriétaire pour le cluster.
    • Toutefois, vous devez permettre d'accéder au magasin de données en utilisant une commande KQL si vous sélectionnez une base de données dans :
      • Analytique en temps réel dans Microsoft Fabric.
      • Un cluster Azure Data Explorer gratuit.

  9. Créez et approuvez des points de terminaison privés managés si vous souhaitez utiliser une connectivité privée.

    • Si l’accès public à vos cibles SQL, au magasin de données et au coffre de clés sont activés et si vous souhaitez utiliser une connectivité publique, assurez-vous que tous les prérequis pour la connectivité publique sont satisfaits.

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 :

Une fois qu’un observateur est entièrement configuré, utilisez le bouton Démarrer sur la page Vue d’ensemble pour démarrer la collecte 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 démarrez-le à nouveau.

Modifier un observateur

Dans le portail Azure, vous pouvez ajouter ou supprimer des cibles, créer ou supprimer des points de terminaison privés, utiliser un autre magasin de données pour un observateur existant ou modifier l’identité managée de l’observateur.

Remarque

Sauf indication différente, les modifications que vous apportez à la configuration de l’observateur deviennent effectives 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 tout abonnement au sein du même locataire 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 SQL distinctes pour la même ressource, puis cochez la case Intention lecture de l’une d’entre elles. De même, créez deux cibles SQL distinctes pour un géo-réplica et son réplica secondaire haute disponibilité, le cas échéant.
    • Cocher la case Intention lecture configure la cible SQL pour le réplica secondaire haute disponibilité uniquement.
    • Ne cochez pas la case Intention lecture si vous souhaitez surveiller uniquement le réplica principal ou uniquement le géo-réplica, ou si aucun réplica secondaire haute disponibilité n’existe pour cette ressource, ou si la fonctionnalité échelle horizontale en lecture est désactivée.

Par défaut, l’observateur de base de données utilise l’authentification Microsoft Entra lors de la connexion aux cibles SQL. Si vous souhaitez que l’observateur utilise l’authentification SQL, cochez la case Utiliser l’authentification SQL et entrez les détails requis. 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 réelle.

Si vous supprimez une ressource Azure SQL surveillée par l’observateur de base de données, vous devez également supprimer la cible correspondante. Une limite sur le nombre de cibles SQL qu’un observateur peut avoir existant, la conservation des cibles obsolètes peut vous empêcher d’ajouter de nouvelles cibles.

Créer un point de terminaison privé managé

Vous devez créer des points de terminaison privés managés si vous souhaitez utiliser la connectivité privée pour la collecte de données depuis des cibles SQL, pour l’ingestion dans le magasin de données et pour la connexion aux coffres 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.

Remarque

L’observateur de base de données nécessite ses propres points de terminaison privés managés pour se connecter aux ressources Azure. Un observateur ne peut pas utiliser de point de terminaison privé qui peut déjà exister pour un serveur logique Azure SQL, une instance gérée SQL, un cluster Azure Data Explorer ou un coffre de clés.

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

  1. S’il existe un verrou sur la ressource, le groupe de ressources ou l’abonnement de la ressource pour laquelle vous créez un point de terminaison privé managé, supprimez le verrou. Vous pouvez ajouter le verrou à nouveau une fois le point de terminaison privé créé avec succès.

  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 le type de ressource pour lequel 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
    Instance managée SQL Microsoft.Sql/managedInstances managedInstance
    Cluster Azure Data Explorer Microsoft.Kusto/clusters cluster
    Coffre de clés 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, 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 base de données et pool élastique sur ce serveur.

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

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

    Important

    Le point de terminaison privé est créé dans l’état En attente. Le propriétaire de la ressource doit approuver le point de terminaison privé 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 la ressource peut rechercher Private Link 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é, il doit être redémarré pour commencer à utiliser la connectivité privée.

Conseil

Vous devez créer un point de terminaison privé supplémentaire pour votre cluster Azure Data Explorer si la connectivité publique du cluster est désactivée. Pour plus d’informations, consultez Connectivité privée au magasin de données.

Supprimer un point de terminaison privé managé

  1. S’il existe un verrou de suppression ou en lecture seule sur la ressource, le groupe de ressources ou l’abonnement de la ressource pour laquelle vous supprimez un point de terminaison privé managé, supprimez le verrou. Vous pouvez ajouter le verrou à nouveau une fois le point de terminaison privé 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 les points de terminaison privés que vous souhaitez supprimer.
  4. Sélectionnez Supprimer.

La suppression d’un point de terminaison privé managé arrête la collecte de données depuis les 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 collecte de données pour toutes les cibles. Pour reprendre la collecte 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 réelle du magasin de données sur un cluster Azure Data Explorer ou dans Analytique en temps réel dans Microsoft Fabric.
    • Pour arrêter la collecte 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 Analytique 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 d’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 en octroyer l’accès à l’observateur pour qu’il l’utilise. Pour plus d’informations, consultez Permettre d'accéder au magasin de données.
    • Une fois l’observateur redémarré, il commence à utiliser le nouveau magasin de données.

Conseil

Si vous basculez le magasin de données d’un cluster Azure Data Explorer payant vers un cluster Azure Data Explorer gratuit, envisagez d’arrêter ou de supprimer le cluster payant si vous n’en avez plus besoin. Cela peut éviter des coûts inutiles.

Modifier l’identité de l’observateur

Un observateur doit avoir une identité managée pour s’authentifier auprès des cibles SQL, des coffres de clés et du magasin de données. Une identité managée affectée par le système ou par l’utilisateur peut être utilisée. Pour plus d’informations sur les identités managées dans Azure, consultez Identités managées pour les ressources Azure ?

Les considérations suivantes vous aident à choisir le type d’identité managée d’un observateur :

  • Affectée par le système

    • Activée par défaut quand vous créez un observateur.
    • Toujours associée à un seul observateur.
    • Créée et supprimée avec l’observateur.
    • Si vous désactivez l’identité affectée par le système d’un observateur, les accès accordés à cette identité sont perdus. La réactivation de l’identité affectée par le système du même observateur crée une identité différente avec un ID d’objet (principal) différent. Vous devez permettre d'accéder aux cibles SQL, au coffre de clés et au magasin de données à cette nouvelle identité.

  • Affectée par l’utilisateur

    • Ne prend effet que si l’identité affectée par le système est désactivée pour l’observateur.
    • La même identité affectée par l’utilisateur peut être affectée à plusieurs observateurs pour simplifier la gestion des accès, par exemple lors de la surveillance de grands patrimoines Azure SQL. Au lieu de permettre l’accès aux identités affectées par le système à plusieurs observateurs, l’accès peut être accordé à une seule identité affectée par l’utilisateur.
    • Pour prendre en charge la séparation des tâches, la gestion des identités peut être distincte de la gestion de l’observateur. Une identité affectée par l’utilisateur peut être créée et accordée à un autre utilisateur, avant ou après la création de l’observateur.
    • À l’inverse, quand un observateur est supprimé, l’identité affectée par l’utilisateur et son accès restent inchangés. La même identité peut ensuite être utilisée pour un nouvel observateur.
    • La spécification de plusieurs identités affectées par l’utilisateur à un observateur n’est pas prise en charge.

Pour modifier l’identité managée d’un observateur, ouvrez la page Identité d’un observateur.

  • Pour utiliser une identité affectée par le système, activez le bouton bascule Identité affectée par le système.

  • Pour utiliser une identité affectée par l’utilisateur, désactivez le bouton bascule Identité affectée par le système. Sélectionnez le bouton Ajouter pour rechercher et ajouter une identité affectée par l’utilisateur existante.

    Pour créer une identité affectée par l’utilisateur, consultez Créer une identité managée affectée par l’utilisateur.

  • Pour supprimer une identité affectée par l’utilisateur d’un observateur, sélectionnez-la dans la liste, puis sélectionnez Supprimer. Une fois l’identité affectée par l’utilisateur supprimée, vous devez ajouter une autre identité affectée par l’utilisateur ou activer l’identité affectée par le système.

    L’identité affectée par l’utilisateur supprimée n’est pas supprimée du locataire Microsoft Entra ID.

Sélectionnez le bouton Enregistrer pour enregistrer les modifications d’identité. Vous ne pouvez pas enregistrer les modifications d’identité si cela entraîne un observateur sans identité. Les observateurs sans identité managée valide ne sont pas pris en charge.

Conseil

Nous recommandons que le nom complet de l’identité managée de l’observateur soit unique dans votre locataire Microsoft Entra ID. Vous pouvez choisir un nom unique lors de la création de l’identité affectée par l’utilisateur pour les observateurs.

Le nom complet de l’identité affectée par le système est identique au nom de l’observateur. Si vous utilisez l’identité affectée par le système, vérifiez que le nom de l’observateur est unique dans votre locataire Microsoft Entra ID.

Si le nom complet de l’identité managée n’est pas unique, le script T-SQL qui accorde à l’observateur un accès aux cibles SQL échoue avec une erreur de nom complet en double. Pour plus d’informations et une solution de contournement, consultez Connexions Microsoft Entra et utilisateurs avec des noms complets non uniques.

Peu après l’enregistrement des modifications d’identité, l’observateur se reconnecte aux cibles SQL, aux coffres de clés (le cas échéant) et au magasin de données en utilisant son identité managée à jour.

Supprimer un observateur

S’il existe un verrou de suppression ou en lecture seule sur l’observateur, son groupe de ressources ou son abonnement, supprimez le verrou. De même, s’il existe un verrou sur la ressource, le groupe de ressources ou l’abonnement de la ressource pour laquelle vous créez un point de terminaison privé géré, supprimez le verrou. Vous pouvez ajouter à nouveau les verrous une fois que l’observateur a été supprimé.

Quand vous supprimez un observateur dont l’identité managée affectée par le système est activée, l’identité 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 lui permettre d’accéder à l’identité managée affectée par le système du nouvel observateur pour s’authentifier auprès de chaque ressource. Notamment :

Vous devez permettre d'accéder à un observateur recréé, même si vous utilisez le même nom d’observateur.

Quand vous supprimez un observateur, les ressources Azure référencées comme ses cibles SQL et le magasin de données ne sont pas supprimés. 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 Azure Data Explorer ou Analytique en temps réel que la banque de données si vous créez un observateur ultérieurement.

Permettre d'accéder aux cibles SQL

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

  • Pour exécuter le script dans Azure SQL Database, vous avez besoin d’un accès administrateur de 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 le script qu’une seule fois par serveur logique pour chaque observateur que vous créez. Cela permet à l’observateur d’accéder à toutes les bases de données et tous pools élastiques existants et nouveaux sur ce serveur.

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

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

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

    Important

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

  2. Dans SQL Server Management 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 permettre d'accéder à l’observateur. Le script crée une connexion que l’observateur utilise pour se connecter et accorde des autorisations spécifiques et limitées afin de collecter des données de surveillance.

    1. Si vous utilisez un script d’authentification Microsoft Entra et que l’observateur utilise l’identité managée affectée par le système, l’observateur doit être déjà créé quand vous exécutez le script. Si l’observateur utilise une identité managée affectée par l’utilisateur, vous pouvez exécuter le script avant ou après la création de l’observateur.

    Vous devez être connecté avec une authentification Microsoft Entra lors de l’exécution des scripts d’accès T-SQL qui permettent d’accéder à une identité managée.

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

Permettre d'accéder 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 permettre d'accéder à l’observateur de base de données. Permettre un accès d’une manière différente peut bloquer la collecte 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, comme login-name-placeholder et password-placeholder, par les valeurs réelles.

Permettre d'accéder aux observateurs authentifiés Microsoft Entra

Ce script crée une connexion d’authentification Microsoft Entra (anciennement appelée 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 depuis toutes les bases de données et tous les pools élastiques sur le serveur logique.

Si l’observateur utilise l’identité managée affectée par le système, vous devez utiliser le nom de l’observateur comme ID de connexion. Si l’observateur utilise une identité managée affectée par l’utilisateur, vous devez utiliser le nom complet de l’identité comme ID de connexion.

Le script doit être exécuté dans la base de données master sur le serveur logique. Vous devez être connecté en utilisant une connexion d’authentification Microsoft Entra qui est administrateur du serveur.

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

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

Permettre d'accéder 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 depuis toutes les bases de données et tous les pools élastiques sur ce serveur logique.

Le script doit être exécuté dans la base de données master sur le serveur logique, en utilisant 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 utiliser l’authentification SQL

Pour stocker les informations d’identification 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 qu’il se connecte à une cible en utilisant 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 pour les 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 une 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. Vérifiez que le point de terminaison privé est approuvé avant de démarrer l’observateur.

    Si vous souhaitez utiliser la connectivité publique, le coffre doit autoriser l’accès public depuis tous les réseaux. La restriction de la connectivité du coffre publique à des réseaux spécifiques n’est pas prise en charge dans 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 spécifiques limitées en utilisant les scripts d’accès fournis. Dans le script, remplacez les espaces réservés de nom de connexion et de 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 l’ID de connexion et un secret distinct pour le mot de passe. Utilisez tout nom valide comme nom de secret et entrez l’ID de connexion et le mot de passe que vous avez utilisés dans le script T-SQL comme valeur secrète pour chaque secret.

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

    Pour créer des secrets, vous devez être membre du rôle RBAC Agent de secrets Key Vault.

  4. Ajoutez une cible SQL à un observateur. Lorsque vous ajoutez la cible, cochez la case Utiliser l’authentification SQL, puis sélectionnez le coffre dans lequel sont stockés l’ID de connexion et le mot de passe secrets. Entrez les noms secrets de l’ID de connexion et le mot de passe dans les champs correspondants.

    Lors de l’ajout d’une cible SQL, n’entrez pas l’ID de connexion et le mot de passe réels. En utilisant l’exemple précédent, vous devez entrer les noms secrets database-watcher-login-name et database-watcher-password.

  5. Quand vous ajoutez une cible SQL dans le portail Azure, l’identité managée de l’observateur reçoit automatiquement l’accès requis aux secrets du coffre de clés si l’utilisateur actuel est membre du rôle Propriétaires ou du rôle Administrateur de l’accès utilisateur du coffre de clés. Sinon, exécutez l’étape suivante pour octroyer l’accès requis manuellement.

  6. Dans 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 des Secrets Key Vault. Pour suivre le principe du privilège minimum, 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.

Si vous souhaitez utiliser différentes informations d’identification d’authentification SQL sur différentes cibles SQL, vous devez créer plusieurs paires de secrets. Vous pouvez utiliser le même coffre, ou des coffres différents, pour stocker les secrets de chaque cible SQL.

Remarque

Si vous mettez à jour la valeur secrète d’un ID de connexion ou d’un mot de passe dans le coffre de clés pendant qu’un observateur est en cours d’exécution, l’observateur se reconnecte aux cibles en utilisant les nouvelles informations d’identification d’authentification SQL dans les 15 minutes. Si vous souhaitez commencer à utiliser les nouvelles informations d’identification immédiatement, arrêtez et redémarrez l’observateur.

Permettre d'accéder au magasin de données

Pour créer et gérer le schéma de base de données dans le magasin de données et pour ingérer des 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 sur un cluster Azure Data Explorer ou dans Analytique en temps réel. L’observateur de base de données ne nécessite aucun accès au niveau du cluster Azure Data Explorer, ni aucun accès à d’autres bases de données qui peuvent exister sur le même cluster.

Si vous utilisez une base de données sur un cluster Azure Data Explorer comme magasin de données, cet accès est accordé automatiquement si vous êtes membre du rôle RBAC Propriétaire du cluster. Sinon, l’accès doit être accordé comme décrit dans cette section.

Si vous utilisez une base de données dans Analytique en temps réel ou sur un cluster Azure Data Explorer gratuit, vous devez permettre l’accès en utilisant KQL.

Permettre d'accéder à une base de données Azure Data Explorer en utilisant le Portail Azure

Vous pouvez utiliser le Portail Azure pour permettre d'accéder à 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 des 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. Si l’observateur utilise l’identité managée affectée par le système, tapez le nom de l’observateur dans la zone Rechercher. Si l’observateur utilise une identité managée affectée par l’utilisateur, tapez le nom complet de cette identité dans la zone Rechercher.
  4. Sélectionnez l’application d’entreprise pour l’identité managée de l’observateur.

Permettre d'accéder à une base de données Azure Data Explorer en utilisant KQL

Au lieu d’utiliser le Portail Azure, vous pouvez également permettre d'accéder à la base de données en utilisant une commande KQL. Utilisez cette méthode pour permettre d'accéder à une base de données dans Analytique en temps réel ou sur un cluster Azure Data Explorer gratuit.

  1. Connectez-vous à une base de données sur le cluster Azure Data Explorer en utilisant Kusto Explorer ou l’interface utilisateur Web d’Azure Data Explorer.

  2. Dans l’exemple de commande KQL suivant, remplacez les trois espaces réservés comme indiqué dans le tableau :

    .add database [adx-database-name-placeholder] admins ('aadapp=identity-principal-id-placeholder;tenant-primary-domain-placeholder');
    Espace réservé Remplacement
    adx-database-name-placeholder Nom d’une base de données sur un cluster Azure Data Explorer ou dans Analytique en temps réel.
    identity-principal-id-placeholder Valeur de l’ID de principal d’une identité managée (un GUID), trouvée dans la page Identité de l’observateur. Si l’identité affectée par le système est activée, utilisez la valeur de son ID de principal. Sinon, utilisez la valeur d’ID de principal de l’identité affectée par l’utilisateur.
    tenant-primary-domain-placeholder Nom de domaine du locataire Microsoft Entra ID de l’identité managée de l’observateur. Recherchez-le dans la page Vue d’ensemble Microsoft Entra ID dans le Portail Azure. Au lieu du domaine principal du locataire, la valeur GUID de l'ID de locataire peut être utilisée également.

    Cette partie de la commande est obligatoire si vous utilisez une base de données dans des analyses en temps réel ou sur un cluster Azure Data Explorer gratuit.

    La valeur de nom de domaine ou d'ID de locataire (et le point-virgule précédent) peut être omise pour une base de données sur un cluster Azure Data Explorer, car le cluster se trouve toujours dans le même locataire Microsoft Entra ID que l'identité managée du veilleur.

    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 Analytique 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 permettre d'accéder à une base de données sur le cluster Azure Data Explorer gratuit ou dans Analytique en temps réel. Pour suivre le principe du privilège minimum, nous vous recommandons de ne pas ajouter d’utilisateurs et de groupes à un rôle RBAC autre que Viewer par défaut.

Important

Examinez attentivement vos exigences de confidentialité et de sécurité des données lors de l’octroi de l’accès à l’affichage des 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 comme 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 lui permettre d’accéder à des données sensibles qu’il ne serait pas en mesure de consulter autrement.

Permettre d'accéder au magasin de données en utilisant le 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. Dans la page Nouveaux principaux, tapez le nom de l’utilisateur ou du groupe dans la zone Recherche.
  4. Sélectionnez l’utilisateur ou le groupe.

Permettre d'accéder 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 en utilisant une commande KQL. L’exemple de commande KQL suivant octroie un accès en lecture aux données à l’utilisateur mary@contoso.com et au groupe SQLMonitoringUsers@contoso.com d’un locataire Microsoft Entra ID avec une valeur d’ID de locataire 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 permettre d'accéder au magasin de données aux utilisateurs et groupes d’un autre locataire, vous devez activer l’authentification inter-locataires sur votre cluster Azure Data Explorer. Pour plus d’informations, consultez Autoriser les requêtes et les commandes inter-locataires.

Conseil

Pour vous permettre d’octroyer un accès aux utilisateurs et aux groupes de votre locataire Microsoft Entra ID, l’authentification inter-locataires est activée dans Analytique en temps réel et sur les clusters Azure Data Explorer gratuits.

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 Analytique en temps réel dans Fabric, la mise à l’échelle est managé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 Extra small, Dev/test si un contrat de niveau de service (SLA) n’est pas nécessaire, et si le niveau de performance d’ingestion des données et des requêtes reste acceptable.

Pour de nombreux déploiements d’observateur de base de données, la référence SKU par défaut Extra small, optimisée 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 un niveau de performance des requête adéquat et maintenir une faible latence d’ingestion des données.

Azure Data Explorer prend en charge la mise à l’échelle de cluster verticale et horizontale. Avec la mise à l’échelle verticale, vous modifiez la référence SKU du cluster, qui modifie le nombre de processeurs virtuels, de mémoire et de cache par instance (nœud). Avec la mise à l’échelle horizontale, 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 (horizontalement) ou un scale-up (verticalement) de votre cluster si vous remarquez un ou plusieurs des symptômes suivants :

  • Le niveau de performance des requêtes ad hoc ou du tableau de bord devient trop lent.
  • 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 devient constamment plus élevée qu’acceptable.

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 utilisent uniquement 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 ralentir au fil du temps, car la quantité totale de données collectées augmente et ne convient plus au stockage SSD local. Dans ce cas, la mise à l’échelle du cluster peut être nécessaire pour maintenir un niveau de performance des requêtes adéquat.

  • Si vous devez mettre à l’échelle votre cluster, nous vous recommandons de le mettre à l’échelle horizontalement pour augmenter le nombre d’instances. Ainsi, le cluster reste 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 pourriez 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 le niveau de performance des requêtes est limité 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. Pendant ce processus, un temps d’arrêt se produit, ce qui peut arrêter la collecte de données par l’observateur. Si cela se produit, arrêtez et redémarrez votre observateur une fois l’opération de mise à l’échelle terminée.

Cluster Azure Data Explorer gratuit

Le cluster Azure Data Explorer gratuit a certaines limites de capacité, notamment une limite de capacité de stockage sur les données non compressées d’origine. Vous ne pouvez pas mettre à l’échelle un cluster Azure Data Explorer gratuit pour augmenter sa capacité de calcul ou de stockage. Quand le cluster est sur le point d’atteindre sa capacité de stockage ou qu’il est à pleine capacité, un message d’avertissement s’affiche sur la page du cluster gratuit.

Si vous atteignez la capacité de stockage maximum, les nouvelles données de surveillance ne sont pas ingérées, mais les données existantes restent accessibles sur les tableaux de bord de l’observateur de base de données et peuvent être analysées en utilisant des requêtes KQL ou SQL.

Si vous constatez que les spécifications du cluster gratuit sont insuffisantes pour vos besoins, vous pouvez mettre à niveau vers un cluster Azure Data Explorer complet. La mise à niveau conserve toutes les données collectées.

Pour vous assurer que votre observateur continue de fonctionner après la mise à niveau, vous devez suivre les étapes suivantes :

  1. Arrêtez l’observateur.
  2. Suivez les étapes de mise à niveau vers un cluster Azure Data Explorer complet et attendez qu’elle soit terminée.
  3. Modifier la banque de données pour l’observateur, en sélectionnant le cluster et la base de données Azure Data Explorer mis à niveau.
  4. Démarrez l’observateur.

Pour continuer à utiliser le cluster Azure Data Explorer gratuit, gérez la conservation des données pour supprimer automatiquement les données les plus anciennes et libérer de l’espace pour de nouvelles données. Une fois l’espace de stockage disponible, vous devrez peut-être arrêter et redémarrer votre observateur pour reprendre la collecte de données.

Gérer la conservation des données

Si vous n’avez pas besoin des données les plus anciennes, vous pouvez configurer des stratégies de conservation des données pour les supprimer définitivement et automatiquement. 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 Analytique 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 tablesindividuelles de la base de données.
  • Vous pouvez également augmenter la durée de conservation des données si vous devez stocker des 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 les plus anciens. Cela peut se produire si des données sont toujours présentes dans certaines tables, mais qu’elles sont déjà purgées dans d’autres tables pour le même intervalle de temps.

La quantité de données de surveillance SQL ingérées dans le magasin de données dépend de vos charges de travail SQL et de la taille de votre patrimoine Azure SQL. Vous pouvez utiliser la requête KQL suivante pour afficher la quantité moyenne de données ingérées par jour, estimer la consommation de stockage au fil du temps et gérer les stratégies de conservation des données.

.show database extents
| summarize OriginalSize = sum(OriginalSize),
            CompressedSize = sum(CompressedSize)
            by bin(MinCreatedOn, 1d)
| summarize DailyAverageOriginal = format_bytes(avg(OriginalSize)),
            DailyAverageCompressed = format_bytes(avg(CompressedSize));

Modifications de schéma et d’accès dans le magasin de données d’observateur de base de données

Au fil du temps, Microsoft peut introduire de nouveaux jeux de données d’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 actuelle 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 cette appartenance à ce rôle ou son remplacement par l’appartenance à tout autre rôle RBAC peut avoir un impact sur la collecte 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 de nouveaux objets tels que des tables, des tables externes, des vues matérialisées, des fonctions, etc. dans le magasin de données d’observateur de base de données n’est pas prise en charge. Vous pouvez utiliser des Requêtes croisées entre clusters et entre bases de données pour interroger des données dans votre magasin de données depuis d’autres clusters Azure Data Explorer ou depuis 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 déplacer le magasin de données pour cet observateur vers une nouvelle base de données vide et octroyer à l’observateur un accès à cette nouvelle base de données pour reprendre la collecte 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 économiser des coûts. Par défaut, un cluster Azure Data Explorer créé 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 de créer un nouveau cluster Azure Data Explorer lors de la création d’un observateur, le comportement d’arrêt automatique est désactivé pour autoriser la collecte 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. Pour reprendre la collecte de données, vous devez démarrer 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 l’ingestion de streaming soit activée sur le cluster Azure Data Explorer contenant la base de données du magasin de données. L’ingestion de streaming est automatiquement activée pour le nouveau cluster Azure Data Explorer créé lorsque vous créez un nouvel observateur. Elle est également activée dans Analytique 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 de streaming. Cela prend quelques minutes et redémarre le cluster.

Connectivité privée au magasin de données

Si l’accès public est désactivé sur un cluster Azure Data Explorer, vous devez créer un point de terminaison privé pour vous connecter au cluster depuis votre navigateur et voir les données de surveillance SQL sur les tableaux de bord, ou pour interroger les données directement. Ce point de terminaison privé s’ajoute au point de terminaison privé managé créé pour permettre à l’observateur d’ingérer des données de surveillance dans une base de données sur le cluster Azure Data Explorer.

  • Si vous vous connectez à un cluster Azure Data Explorer depuis une machine virtuelle Azure, créez un point de terminaison privé pour le cluster Azure Data Explorer dans le réseau virtuel Azure où votre machine virtuelle Azure est déployée.

  • Si vous vous connectez à un cluster Azure Data Explorer depuis un ordinateur local, vous pouvez :

    1. Utiliser la Passerelle VPN Azure ou Azure ExpressRoute pour établir une connexion privée entre votre réseau local et un réseau virtuel Azure.
    2. Créer un point de terminaison privé pour le cluster Azure Data Explorer dans le réseau virtuel Azure où se termine la connexion VPN ou ExpressRoute, ou dans un autre réseau virtuel Azure accessible par le trafic depuis votre ordinateur local.
    3. Configurer le DNS pour ce point de terminaison privé.

La connectivité privée n’est pas disponible pour les clusters Azure Data Explorer gratuits ou pour Analytique en temps réel dans Microsoft Fabric.

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 Analytique 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 distinctes 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 au magasin de données commun :

  • Il existe une vue à volet unique de l’ensemble de votre patrimoine Azure SQL.
  • Les tableaux de bord de tout observateur affichent toutes les données dans le magasin de données, même si les données sont collectées par d’autres observateurs.
  • Les utilisateurs ayant accès au magasin de données ont accès aux données de surveillance de l’ensemble de votre patrimoine Azure SQL.

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 l’observateur de base de données dans le Portail Azure affichent toujours 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 croisées entre les clusters ou entre les bases de données pour accéder aux données de surveillance dans plusieurs magasins de données en utilisant une seule requête.
  • L’accès aux données dans Azure Data Explorer et Analytique en temps réel étant 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 néanmoins 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 les différentes bases de données sur différents clusters.

Contenu connexe