Créer et configurer un observateur (préversion)

S'applique à : Azure SQL DatabaseAzure SQL Managed Instance

Cet article contient des étapes détaillées pour créer, configurer et démarrer un observateur 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 détaillé simplifié de création et de configuration d’un observateur, consultez Démarrage rapide : Créer un observateur pour surveiller Azure SQL.

Pour voir comment créer et configurer un observateur avec Bicep ou un modèle ARM, consultez l’exemple de code Créer un observateur .

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 par programmation, consultez la documentation de l’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.

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, vous avez besoin d’une cible SQL existante : une base de données Azure SQL, un pool élastique ou une instance managée SQL.

  • Si vous n’avez pas encore créé de base de données Azure SQL, rendez-vous sur Démarrage rapide : créer une base de données unique. Recherchez l’option permettant d’utiliser votre offre pour Essayer Azure SQL Database gratuitement.
  • Vous pouvez également Essayer Azure SQL Managed Instance gratuitement (préversion).

• 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 RBACProprié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 observateur. 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 activer le veilleur.

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 :

• Un magasin de données.
• Au moins une cible.
• Un accès au magasin de données et aux cibles.
  • Un accès à un coffre de clés est également nécessaire si l’authentification SQL a été sélectionnée pour l’une quelconque des cibles.
• 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.
  • Pour utiliser la connectivité privée, créez des points de terminaison privés.

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.

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. S’il existe un verrou en lecture seule sur l’observateur, son groupe de ressources ou son abonnement, supprimez le verrou. Vous pouvez ajouter à nouveau le verrou une fois que les cibles SQL ont été ajoutées avec succès.
2. Dans la page cibles SQL , sélectionnez Ajouter.
3. 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.
4. 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, un observateur utilise l’authentification Microsoft Entra lors de la connexion à des 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 veilleur

Pour arrêter la surveillance de l’observateur de base de données pour une cible SQL, supprimez la cible d’un observateur.

1. S’il existe un verrou de suppression ou en lecture seule sur l’observateur, son groupe de ressources ou son abonnement, supprimez le verrou. Vous pouvez ajouter à nouveau les verrous une fois les cibles SQL supprimées.
2. 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 SQL 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 un observateur, vous devez également supprimer la cible SQL correspondante de l’observateur. 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, un observateur utilise par défaut la connectivité publique.

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 dans le portail Azure, ouvrez la page Points de terminaison privés géré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 permet à un observateur d’utiliser la connectivité privée pour toutes les cibles de base de données et de 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 qu’un observateur 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 gérés pour un observateur 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.

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. Dans la page du portail Azure de votre observateur, 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 stockage 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 utilisée précédemment comme magasin de données observateur. 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.

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 :

• Attribué 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é assignée par le système pour le même observateur crée une nouvelle identité avec un autre ID d'objet (principal). 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é assigné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é attribuée par l'utilisateur peut être créée et l'accès peut être accordé par un autre utilisateur, soit avant, soit après la création de l'observateur.
  • À l’inverse, quand un observateur est supprimé, l'identité utilisateur assignée et son accès restent inchangés. La même identité peut ensuite être utilisée pour un nouvel observateur.
  • La spécification de plus d'une identité assignée 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é assignée par l'utilisateur, désactivez l'interrupteur Identité assignée par le système. Sélectionnez le bouton Ajouter pour rechercher et ajouter une identité utilisateur attribuée 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é attribuée à un 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.

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 :

• Les cibles
• Le magasin de données
• Et le coffre de clés (le cas échéant)

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.

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.

Accorder l'accès aux observateurs authentifiés de Microsoft Entra

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];

USE master;

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

GRANT CONNECT SQL, CONNECT ANY DATABASE, VIEW ANY DATABASE, VIEW ANY DEFINITION, VIEW SERVER PERFORMANCE STATE TO [identity-name-placeholder];

USE msdb;

CREATE USER [identity-name-placeholder] FOR LOGIN [identity-name-placeholder];

GRANT SELECT ON dbo.sysjobactivity TO [identity-name-placeholder];
GRANT SELECT ON dbo.sysjobs TO [identity-name-placeholder];
GRANT SELECT ON dbo.syssessions TO [identity-name-placeholder];
GRANT SELECT ON dbo.sysjobhistory TO [identity-name-placeholder];
GRANT SELECT ON dbo.sysjobsteps TO [identity-name-placeholder];
GRANT SELECT ON dbo.syscategories TO [identity-name-placeholder];
GRANT SELECT ON dbo.sysoperators TO [identity-name-placeholder];
GRANT SELECT ON dbo.suspect_pages TO [identity-name-placeholder];
GRANT SELECT ON dbo.backupset TO [identity-name-placeholder];
GRANT SELECT ON dbo.backupmediaset TO [identity-name-placeholder];
GRANT SELECT ON dbo.backupmediafamily TO [identity-name-placeholder];

Accorder l'accès aux observateurs s'authentifiant via SQL

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

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];

USE master;

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

GRANT CONNECT SQL, CONNECT ANY DATABASE, VIEW ANY DATABASE, VIEW ANY DEFINITION, VIEW SERVER PERFORMANCE STATE TO [login-name-placeholder];

USE msdb;

CREATE USER [login-name-placeholder] FOR LOGIN [login-name-placeholder];

GRANT SELECT ON dbo.sysjobactivity TO [login-name-placeholder];
GRANT SELECT ON dbo.sysjobs TO [login-name-placeholder];
GRANT SELECT ON dbo.syssessions TO [login-name-placeholder];
GRANT SELECT ON dbo.sysjobhistory TO [login-name-placeholder];
GRANT SELECT ON dbo.sysjobsteps TO [login-name-placeholder];
GRANT SELECT ON dbo.syscategories TO [login-name-placeholder];
GRANT SELECT ON dbo.sysoperators TO [login-name-placeholder];
GRANT SELECT ON dbo.suspect_pages TO [login-name-placeholder];
GRANT SELECT ON dbo.backupset TO [login-name-placeholder];
GRANT SELECT ON dbo.backupmediaset TO [login-name-placeholder];
GRANT SELECT ON dbo.backupmediafamily TO [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 pour un observateur nécessite une configuration supplémentaire.

Pour configurer un observateur pour se connecter à une cible SQL à 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 pour les nouveaux coffres. Si vous souhaitez utiliser un coffre-fort 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 du watcher dans le rôle RBAC Key Vault Secrets User. 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.

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, un observateur nécessite l’appartenance au rôle RBAC administrateurs dans la base de données du magasin de données sur un cluster Azure Data Explorer ou dans Real-Time Analytics. L’observateur n’a pas besoin d’un accès au niveau du cluster Azure Data Explorer ou d’un 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 sa valeur ID principal. Sinon, utilisez la valeur de l’ID principal de l’identité assigné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.

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.

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 régulation.
• 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, augmentez verticalement le 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 gratuit Azure Data Explorer

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 de l’observateur

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 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 à n’importe quel autre rôle RBAC peut avoir un impact sur la collecte 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 observateur n'est pas supportée. 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.

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 par l’observateur 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 de stockage. 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

• Démarrage rapide : Créer un observateur pour surveiller Azure SQL (préversion)
• Surveiller les charges de travail Azure SQL avec un observateur de base de données (préversion)
• Collecte de données et jeux de données de l’observateur de base de données (préversion)
• Analyser les données de surveillance de l’observateur de base de données (préversion)
• Alertes d’observateur de base de données (préversion)
• FAQ sur l’observateur de base de données