Partager via

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

  • Article

S’applique à : Azure SQL Database Azure 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 la base de données Azure SQL 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 des bases 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 gérer les observateurs de base de données de manière programmatique, consultez la documentation de l’API REST de l’observateur de base de données.

Remarque

L’observateur de base de données est actuellement en aperçu.

Prérequis

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

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

  • Pour configurer et démarrer un observateur de base de données, vous aurez besoin d’une cible SQL existante : une base de données Azure SQL, un pool élastique ou une SQL Managed Instance.

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

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

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

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

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

  • Pour octroyer à 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), d’Azure Data Studio ou de Visual Studio Code avec l’extension mssql SQL Server.

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

Créer un observateur

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

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

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

    Conseil

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

  3. 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 Très petit, Optimisé pour le calcul. Il s’agit de la SKU la plus économique offrant toujours un contrat de niveau de service (contrat SLA). Vous pouvez mettre à l’échelle ce cluster ultérieurement en fonction des besoins.

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

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

      Remarque

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

    • Il est également possible d’ignorer l’ajout d’un magasin de données pour l’instant et de l’ajouter ultérieurement. Un magasin de données est requis pour démarrer l’observateur.

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

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

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

  8. Vous devrez peut-être également accorder à 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 accordé automatiquement lors de la création de l’observateur si l’utilisateur qui crée l’observateur est membre du rôle RBAC Propriétaire du cluster.
    • Toutefois, vous devez octroyer l’accès au magasin de données à l’aide d’une commande KQL si vous sélectionnez une base de données dans :
      • Analyse en temps réel dans Microsoft Fabric.
      • Un cluster Azure Data Explorer gratuit.

  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, le magasin de données et le coffre de clés sont activés et si vous souhaitez utiliser une connectivité publique, assurez-vous que tous les prérequis à une 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 minimum une cible ;
  • accès au magasin de données et aux cibles ;
    • accès à un coffre de clés, dans le cas où l’authentification SQL a été sélectionnée pour une cible ;
  • une connectivité privée ou publique aux cibles, au coffre de clés (si vous utilisez l’authentification SQL) et au magasin de données.

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

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

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

Modifier un observateur

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

Remarque

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

Ajouter des cibles SQL à un observateur

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

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

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

Supprimer des cibles SQL d’un observateur

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

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

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

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

Vous devez créer des points de terminaison privés managés si vous souhaitez utiliser la connectivité privée pour la collection de données à partir de cibles SQL, pour l’ingestion dans le magasin de données et pour la connexion à des 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 la base de données nécessite ses propres points de terminaison privés managés pour se connecter aux ressources Azure. Tout point de terminaison privé qui existe déjà pour un serveur logique Azure SQL, une SQL Managed Instance, un cluster Azure Data Explorer ou un coffre de clés ne peut pas être utilisé par un observateur.

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

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

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

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

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

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

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

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

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

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

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

    Important

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

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

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

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

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

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 lequel vous avez supprimé le point de terminaison privé managé, retirez le verrou. Vous pouvez remettre le verrou une fois que le point de terminaison privé est supprimé.
  2. Sur la page du Portail Azure de votre observateur de base de données, ouvrez la page Points de terminaison privés managés.
  3. Sélectionnez le point de terminaison privé que vous souhaitez supprimer.
  4. Sélectionnez Supprimer.

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

Modifier le magasin de données d’un observateur

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

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

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

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

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

    • La base de données que vous sélectionnez doit être vide ou doit être une base de données que vous avez précédemment utilisée comme magasin de données de l’observateur de base de données. La sélection d’une base de données qui contient des objets qui n’ont pas été créés par l’observateur de base de données n’est pas prise en charge.
    • Une fois que vous avez ajouté un magasin de données, vous devez octroyer à l’observateur l’accès pour qu’il puisse l’utiliser. Pour plus d’informations, consultez Octroyer l’accès au magasin de données.
    • 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é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 l’accès aux cibles SQL, au coffre de clés et au magasin de données à cette nouvelle identité.

  • Attribué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 un nom complet d’identité managée de l’observateur 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 à l’aide de 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. Vous pouvez remettre le verrou une fois que l’observateur est 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 octroyer l’accès à 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 Analyse en temps réel que celle du magasin de données si vous créez un observateur ultérieurement.

Octroyer l’accès aux cibles SQL

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

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

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

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

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

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

    Important

    Le script d’authentification Microsoft Entra 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 Octroyer l’accès aux cibles SQL avec des scripts T-SQL.

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

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

    1. Si vous utilisez un script d’authentification Microsoft Entra et si 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 octroyer l’accès à ces cibles de manière similaire, sauf si ces cibles se trouvent sur un serveur logique pour lequel l’accès a déjà été octroyé.

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

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

Important

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

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

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

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

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é au moyen d’une connexion d’authentification Microsoft Entra de type 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];

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

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

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

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

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

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

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

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

Conseil

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

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

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

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

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

  2. Créez une connexion d’authentification SQL sur chaque serveur logique Azure SQL ou Managed Instance que vous souhaitez surveiller et octroyez des autorisations spécifiques et limitées à l’aide des scripts d’accès fournis. Dans le script, remplacez les espaces réservés au nom de connexion et au mot de passe par les valeurs réelles. Utilisez un mot de passe fort.

  3. Dans le coffre, créez deux secrets : un secret pour le nom de connexion et un secret distinct pour le mot de passe. Utilisez n’importe quel nom valide comme nom de secret et saisissez le nom de connexion et le mot de passe que vous avez utilisé 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 des secrets sont un nom de connexion et un mot de passe fort.

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

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

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

  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 accorder l’accès requis manuellement.

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

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

Remarque

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

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

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

Si vous 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 des analyses en temps réel ou sur un cluster Azure Data Explorer gratuit, vous devez accorder l’accès à l’aide de KQL.

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

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

  1. Pour une base de données sur un cluster Azure Data Explorer, dans le menu de ressources sous Sécurité + mise en réseau, sélectionnez Autorisations. N’utilisez pas la page Autorisations du cluster.
  2. Sélectionnez Ajouter, puis sélectionnez Administrateur.
  3. Dans 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 de l’identité managée de l’observateur.

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

Au lieu d’utiliser le Portail Azure, vous pouvez également octroyer l’accès à la base de données à l’aide d’une commande KQL. Utilisez cette méthode pour octroyer l’accès à une base de données d’Analyse en temps réel ou une base de données sur un cluster Azure Data Explorer gratuit.

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

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

    .add database [adx-database-name-placeholder] admins ('aadapp=identity-principal-id-placeholder;tenant-primary-domain-placeholder');
    Paramètre substituable Remplacement
    adx-database-name-placeholder Nom d’une base de données sur un cluster Azure Data Explorer ou dans l’Analyse en temps réel.
    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. Vous trouverez cette information sur la page Vue d’ensemble de Microsoft Entra ID dans le Portail Azure. Au lieu du domaine principal du locataire, la valeur GUID de l’ID de locataire peut également être utilisée.

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

    Le nom de domaine ou la valeur d’ID de locataire (et le point-virgule précédent) peut être omis 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 de l’observateur.

    Par exemple :

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

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

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

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

Utilisez une commande KQL pour accorder l’accès à une base de données sur le cluster Azure Data Explorer gratuit ou dans l’Analyse en temps réel. Pour suivre le principe du moindre privilège, nous vous recommandons de ne pas ajouter d’utilisateurs et de groupes à un rôle RBAC autre que celui de Viewer 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 pour afficher les données de surveillance SQL collectées par l’observateur de base de données.

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

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

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

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

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

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

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

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

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

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

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

Conseil

Pour vous permettre d’accorder l’accès aux utilisateurs et aux groupes de votre client Microsoft Entra ID, l’authentification interclient est activée dans l’Analyse 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 l’Analyse en temps réel dans Fabric, la mise à l’échelle est gérée automatiquement.

Mettre à l’échelle un cluster Azure Data Explorer

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

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

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

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

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

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

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

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

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

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

    • La mise à l’échelle verticale du cluster prend plusieurs minutes. Au cours de ce processus, la collection de données de l’observateur peut être interrompue pendant un temps d’arrêt. 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, 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 la base de données et peuvent être analysées à l’aide de 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 et conserver les données collectées. Étant donné qu’il peut y avoir un temps d’arrêt pendant la mise à niveau, vous devrez peut-être arrêter et redémarrer votre observateur pour reprendre la collection de données une fois la mise à niveau terminée.

Pour continuer à utiliser le cluster Azure Data Explorer gratuit, gérer la conservation des données pour supprimer automatiquement les données 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 anciennes données, vous pouvez configurer des stratégies de rétention des données pour supprimer définitivement ces anciennes données. Par défaut, la conservation des données est définie sur 365 jours dans une nouvelle base de données sur un cluster Azure Data Explorer ou dans l’Analyse en temps réel.

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

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

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

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

Pour ce faire, l’identité managée 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 l’appartenance à ce rôle ou son remplacement par l’appartenance à n’importe quel autre rôle RBAC peut avoir un impact sur la collection de données de l’observateur de base de données et la gestion des schémas et n’est pas prise en charge.

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

Important

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

Clusters Azure Data Explorer arrêtés

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

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

Si le cluster est arrêté, la collection de données de l’observateur de base de données s’arrête également. Pour reprendre la collection 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 le cluster Azure Data Explorer contenant la base de données du magasin de données ait activé l’ingestion en streaming. L’ingestion en streaming est automatiquement activée pour le cluster Azure Data Explorer créé lorsque vous créez un observateur. Il est également activé dans l’Analyse en temps réel et sur le cluster Azure Data Explorer gratuit.

Si vous souhaitez utiliser un cluster Azure Data Explorer existant, veillez d’abord à activer l’ingestion en streaming. Cela prend quelques minutes et 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 à partir de votre browser et voir les données de SQL Monitoring sur les tableaux de bord, ou pour interroger les données directement. Ce point de terminaison privé est en plus du 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 à partir d’un ordinateur virtuel Azure, créez un point de terminaison privé pour le cluster Azure Data Explorer sur le réseau virtuel Azure où votre ordinateur virtuel Azure est déployée.

  • Si vous vous connectez à un cluster Azure Data Explorer à partir d’un ordinateur local, vous pouvez :

    1. utiliser la Passerelle VPN Azure ou Azure ExpressRoute pour établir une connexion privée de votre réseau local vers 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 de terminaison de la connectivité VPN ou ExpressRoute, ou dans un autre réseau virtuel Azure accessible via le trafic de votre ordinateur local.
    3. configurer un DNS pour ce point de terminaison privé.

La connectivité privée n’est pas disponible pour les clusters Azure Data Explorer gratuits ou pour l’Analyse 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 l’Analyse en temps réel comme magasin de données. Les observateurs que vous créez peuvent utiliser une base de données unique comme magasin de données commun ou des bases de données séparées en tant que magasins de données distincts. Les considérations suivantes peuvent vous aider à faire un choix de conception optimal pour vos scénarios et exigences de surveillance.

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

  • Il existe une vue à volet unique de l’ensemble de votre patrimoine Azure SQL.
  • Les tableaux de bord d’un 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 pour 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 entre clusters ou entre bases de données pour accéder aux données de surveillance dans plusieurs magasins de données au moyen d’une seule requête.
  • Étant donné que l’accès aux données dans Azure Data Explorer et dans l’Analyse en temps réel est géré par base de données, vous pouvez gérer l’accès aux données de surveillance des sous-ensembles de votre patrimoine de manière granulaire.
  • Vous pouvez placer plusieurs bases de données sur le même cluster Azure Data Explorer pour partager des ressources de cluster et économiser des coûts, tout en conservant les données isolées dans chaque base de données.
  • Si vous avez besoin d’une séparation complète des environnements, y compris l’accès réseau aux clusters Azure Data Explorer, vous pouvez placer différentes bases de données sur différents clusters.

Contenu connexe