Événements étendus dans Azure SQL

S’applique à :Base de données SQLAzure SQL Managed InstanceBase de données Azure SQL dans Fabric

Pour une présentation des événements étendus, consultez :

L’ensemble de fonctionnalités, les fonctionnalités et les scénarios d’utilisation pour les événements étendus dans Azure SQL Database, SQL Database dans Fabric et Azure SQL Managed Instance sont similaires à ce qui est disponible dans SQL Server. Les principales différences sont les suivantes :

  • Dans Azure SQL Database, SQL Database dans Fabric et Azure SQL Managed Instance, la event_file cible utilise toujours des blobs dans stockage Azure, plutôt que des fichiers sur le disque.
    • Dans SQL Server, la event_file cible peut utiliser des fichiers sur disque ou des blocs dans le stockage Azure.
  • Dans Azure SQL Database et dans la base de données SQL de Fabric, les sessions d’événements sont toujours limitées à l’étendue de la base de données. Cela signifie que :
    • Une session d’événements d’une base de données ne peut pas accéder aux données ou événements d’une autre base de données.
    • Un événement doit se produire dans le contexte d’une base de données utilisateur à inclure dans une session.
  • Dans Azure SQL Managed Instance, vous pouvez créer des sessions d’événements à l'échelle du serveur et à l'échelle de la base de données. Nous vous recommandons d’utiliser des sessions d’événements au niveau du serveur pour la plupart des scénarios.

Get started

Il existe deux exemples de procédure pas à pas pour vous aider à démarrer rapidement avec les événements étendus :

Extended Events peut être utilisé pour surveiller les réplicas en lecture seule. Pour plus d'informations, consultez Requêtes en lecture sur les réplicas.

Meilleures pratiques

Adoptez les meilleures pratiques suivantes pour utiliser des événements étendus de manière sécurisée, fiable et sans affecter les performances de charge de travail et d’intégrité du moteur de base de données.

  • Si vous utilisez la cible event_file :
    • Selon les événements ajoutés à une session, les fichiers produits par la event_file cible peuvent contenir des données sensibles. Examinez attentivement les attributions de rôles RBAC et les listes de contrôle d’accès (ACL) sur le compte de stockage et le conteneur, y compris l’accès hérité, pour éviter d’accorder un accès en lecture inutile. Suivez le principe du privilège minimum.
    • Utiliser un compte de stockage dans la même région Azure que la base de données ou l’instance gérée où vous créez des sessions d’événements.
    • Aligner la redondance du compte de stockage avec la redondance de la base de données, du pool élastique, ou de l’instance gérée. Pour les ressources localement redondantes, utiliser LRS, GRS ou RA-GRS. Pour les ressources redondantes interzones, utiliser ZRS, GZRS ou RA-GZRS. Pour plus d’informations, consultez Redondance de Stockage Azure.
    • N’utilisez aucun niveau d’accès du blob autre que Hot.
    • N’activez pas l’espace de noms hiérarchique pour le compte de stockage.
  • Si vous souhaitez créer une session d’événements en cours d’exécution continue qui démarre automatiquement après chaque redémarrage de moteur de base de données (par exemple, après un basculement ou un événement de maintenance), incluez l’option de session d’événements de STARTUP_STATE = ON dans vos CREATE EVENT SESSION ou instructions ALTER EVENT SESSION.
  • À l’inverse, utilisez STARTUP_STATE = OFF pour les sessions d’événements à court terme, telles que celles utilisées dans le cadre d’un dépannage ad hoc.
  • Dans la base de données Azure SQL, ne lisez pas les événements de blocage de la session d’événements intégrée dl. S’il existe un grand nombre d’événements de blocage collectés, leur lecture avec la fonction sys.fn_xe_file_target_read_file() peut entraîner une erreur de mémoire insuffisante dans la base de données master. Cela peut affecter le traitement de la connexion et entraîner une panne d’application. Pour connaître les méthodes recommandées pour surveiller les blocages, consultez Collecter des graphiques de blocage dans la base de données Azure SQL avec des événements étendus.

Objectifs de session d’événement

Pour plus d’informations sur les cibles d’événements étendus prises en charge dans Azure SQL Database, SQL Database dans Fabric, Azure SQL Managed Instance et SQL Server, consultez Cibles pour les événements étendus.

Différences de Transact-SQL

Lorsque vous exécutez les instructions CREATE EVENT SESSION, ALTER EVENT SESSION et DROP EVENT SESSION dans SQL Server et dans Azure SQL Managed Instance, vous utilisez la clause ON SERVER. Dans Azure SQL Database, vous utilisez la clause ON DATABASE à la place, car dans Azure SQL Database, les sessions d’événements sont étendues à la base de données.

Vues du catalogue des événements étendus

Les événements étendus proposent plusieurs vues de catalogue. Les vues de catalogue vous renseignent sur les métadonnées ou la définition d’une session d’événement. Ces vues ne renvoient pas d’informations sur les instances de sessions d’événements actives.

Pour obtenir la liste des vues de catalogue pour chaque plateforme, consultez Extended Events Catalog Views.

Vues de gestion dynamique des événements étendus

Les événements étendus fournissent plusieurs vues de gestion dynamique (DMV). Les DMV renvoient des informations sur les sessions d’événements démarrées.

Pour obtenir la liste des vues de gestion dynamique des événements étendus pour chaque plateforme, consultez les vues de gestion dynamique des événements étendus.

Vues de gestion dynamique les plus courantes

Il existe d’autres DMV d’événements étendus communes à Azure SQL Database, Azure SQL Managed Instance et SQL Server :

Événements, actions et cibles disponibles

Vous pouvez obtenir des événements, des actions et des cibles disponibles à l’aide de cette requête :

SELECT o.object_type,
       p.name AS package_name,
       o.name AS db_object_name,
       o.description AS db_obj_description
FROM sys.dm_xe_objects AS o
INNER JOIN sys.dm_xe_packages AS p
ON p.guid = o.package_guid
WHERE o.object_type IN ('action','event','target')
ORDER BY o.object_type,
         p.name,
         o.name;

Permissions

Consultez les autorisations pour obtenir des autorisations détaillées par plateforme.

Autorisation du conteneur de stockage et contrôle

Lorsque vous utilisez la event_file cible avec des objets blob de stockage Azure, le moteur de base de données qui exécute la session d’événements doit avoir un accès spécifique au conteneur d’objets blob. Vous pouvez accorder cet accès de l’une des manière suivantes :

  • Attribuez le rôle RBAC Contributeur aux données Blob du stockage à l’identité managée du serveur logique Azure SQL ou de l’instance gérée Azure SQL pour le conteneur, puis créez des informations d’identification afin d’indiquer au moteur de base de données d’utiliser l’identité managée pour l’authentification.

    Au lieu d’attribuer le rôle RBAC Contributeur aux données Blob de stockage, vous pouvez attribuer les actions RBAC suivantes :

    Namespace Action
    Microsoft.Storage/storageAccounts/blobServices/containers/ read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ delete
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ read
    Microsoft.Storage/storageAccounts/blobServices/containers/blobs/ write

  • Créez un jeton SAS pour le conteneur, puis stockez-le dans des informations d’identification.

    Dans Azure SQL Database, vous devez utiliser des informations d’identification à portée de base de données. Dans Azure SQL Managed Instance et SQL Server, utilisez des informations d’identification au niveau du serveur.

    Le jeton SAS que vous créez pour votre conteneur Stockage Azure doit répondre aux exigences suivantes :

    • Disposez des autorisations rwdl (Read, Write, Delete, List).
    • Définissez une heure de début et une heure d’expiration couvrant toute la durée de la session d’événement.
    • Il ne doit avoir aucune restriction des adresses IP.

Périmètre de sécurité réseau (aperçu)

Le périmètre de sécurité réseau (aperçu) établit une frontière d’accès réseau autour d’Azure SQL Database et d’autres ressources Azure platform as a service (PaaS). Lorsque vous associez un serveur logique à un périmètre de sécurité réseau (NSP), les connexions sortantes que les événements étendus établissent vers stockage Azure sont soumises aux règles d'accès du périmètre.

Note

Le périmètre de sécurité réseau est disponible uniquement pour Azure SQL Database. Cette section ne s'applique pas à Azure SQL Managed Instance ou à la base de données SQL dans Fabric. En tant que fonction de prévisualisation, le périmètre de sécurité réseau est soumis aux Conditions d’utilisation supplémentaires pour les Aperçus Microsoft Azure.

Comment les événements étendus utilisent l’accès réseau

Extended Events établit des connexions sortantes du Moteur de base de données vers stockage Azure dans deux cas :

  • Écrire des données d’événements. Lorsque vous démarrez une session d’événements avec une cible event_file pointant vers un blob, le Moteur de base de données vérifie l’accès sortant avant le démarrage de la session, puis de nouveau chaque fois qu’il vide les mémoires tampons d’événements dans le blob.
  • Lecture des données d’événement. Lorsque vous appelez sys.fn_xe_file_target_read_file ou sys.fn_MSxe_read_event_stream avec une URL de blob, le Moteur de base de données vérifie l’accès sortant lorsque la fonction s’initialise. SSMS appelle sys.fn_MSxe_read_event_stream lorsque vous ouvrez les données d’événements capturées dans l’Observateur d’événements.

Les connexions TDS entrantes utilisées pour gérer les sessions d’événements via T-SQL n’ont pas besoin d’aucune configuration NSP spécifique aux événements étendus. Les CREATE EVENT SESSIONinstructions , ALTER EVENT SESSION, et DROP EVENT SESSION ainsi que les fonctions de lecture s’exécutent toutes sur une connexion client normale, donc elles suivent les mêmes règles d’accès entrant que toute autre connexion client à la base de données.

Configurations prises en charge

Le comportement dépend du mode d’accès du périmètre, du fait que le compte de stockage soit dans le même périmètre que le serveur logique, et du fait que deux périmètres différents soient liés entre eux.

Serveur logique SQL NSP Compte de stockage NSP Behavior
Pas de NSP Pas de NSP Le périmètre n’évalue pas la connexion. Extended Events se connecte au compte de stockage en utilisant l’identifiant que vous avez configuré et les règles du pare-feu du compte de stockage. Pour plus d’informations, voir Autorisation et contrôle du conteneur de stockage.
Pas de NSP Dans un NSP Le périmètre n’évalue pas l’accès sortant depuis le serveur logique. La réussite de la connexion dépend des règles d’entrée du périmètre propre au compte de stockage.
Dans un NSP (Appliqué) Même NSP L’accès est toujours autorisé. Vous n’avez pas besoin d’une règle de sortie.
Dans un NSP (Appliqué) NSP différent mais lié L’accès est autorisé grâce à des règles inter-périmètres. Vous n’avez pas besoin d’une règle FQDN sortante.
Dans un NSP (Appliqué) NSP différent non lié, ou aucun NSP L’accès est autorisé lorsque vous utilisez une identité gérée, ou lorsqu’une règle FQDN sortante dans le profil périmétrique correspond au nom hôte du compte de stockage. Si vous utilisez un jeton SAS et qu’aucune règle ne correspond, la session d’événement ne démarre pas avec l’erreur 25602, et les fonctions de lecture peuvent échouer avec l’erreur 25759.
Dans un NSP (Transition) N'importe quel Le périmètre évalue et enregistre les règles mais ne bloque pas le trafic.

Configurez l’accès sortant au compte de stockage

Lorsque vous configurez une base de données pour utiliser des événements étendus, vous pouvez choisir entre l’identité gérée et l’authentification du token SAS . Le mécanisme d’authentification que vous choisissez détermine si vous avez besoin d’une règle d’accès sortant.

  1. Vérifiez l’association du périmètre. Dans le portail Azure, cherchez Périmètre de sécurité réseau, sélectionnez votre périmètre, puis sélectionnez Ressources associées dans le menu Paramètres pour confirmer que votre serveur est listé. Pour plus d’informations, voir Périmètre de sécurité réseau.
  2. Choisissez votre mécanisme d’authentification. Utilisez l’authentification d’identité gérée. Un token d’identité géré inclut les revendications dont le périmètre a besoin, donc vous n’avez pas besoin d’ajouter une règle sortante et pouvez sauter l’étape suivante.
  3. Ajoutez une règle d’accès sortant (jeton SAS uniquement). Si vous utilisez un jeton SAS et que le périmètre est en mode appliqué, ajoutez une règle d’accès sortant sur le profil périmétrique. Utilisez un type de règle de noms de domaine entièrement qualifiés (FQDN) et le nom hôte de votre compte de stockage comme valeur myxedata.blob.core.windows.net.

Dans cet exemple, vous pouvez utiliser *.blob.core.windows.net pour autoriser tous les comptes stockage Azure, mais ce paramètre permet des connexions sortantes vers des comptes de stockage que vous ne possédez pas. Utilisez le nom d’hôte spécifique lorsque vous le pouvez.

Gardez le périmètre en mode transition tant que vous n’avez pas confirmé les règles sortantes dont vous avez besoin. En mode transition, le périmètre enregistre les évaluations des règles sans bloquer l’accès, ce qui permet de trouver les règles manquantes avant qu’elles ne provoquent des défaillances. Passez en mode appliqué une fois les règles en place.

Limitations et différences de comportement

  • Le Moteur de base de données vérifie l’accès sortant au démarrage d’une session et à chaque vidage du tampon. Si vous supprimez une règle sortante pendant qu’une session tourne, celle-ci ne s’arrête pas. Les écritures individuelles dans la mémoire tampon commencent en revanche à échouer.
  • Les identités gérées et les jetons SAS ne sont pas équivalents sous un périmètre. Un jeton d’identité géré porte des revendications périmétriques, il n’a donc pas besoin de règle sortante. Un jeton SAS ne porte pas ces revendications, il a donc besoin d’une règle sortante correspondante en mode appliqué.
  • Une fonction de lecture bloquée peut ne pas générer d’erreur. Lorsqu’un périmètre bloque sys.fn_xe_file_target_read_file ou sys.fn_MSxe_read_event_stream, la fonction peut générer l’erreur 25759 ou 25717, ou retourner un ensemble de résultats vide sans erreur. Si vous attendez des données mais ne recevez aucune ligne ni aucun message d’erreur, vérifiez vos règles de sortie.

Erreurs lorsqu’un périmètre bloque l’accès

L’erreur 25602 signifie que la event_file cible n’a pas pu initialiser car le périmètre bloquait la connexion sortante vers le compte de stockage :

The target, "<target_name>", encountered a configuration error during initialization. Object cannot be added to the event session.
For more information, see https://go.microsoft.com/fwlink/?linkid=2336061.

L’erreur 25759 signifie qu’un périmètre a bloqué une fonction de lecture :

Network Security Perimeter (NSP) blocked outbound access to the storage URL '<url>'.
The NSP configuration does not allow reading from the specified location.

L’erreur 25717 signifie que l’accès a été révoqué alors qu’une fonction de lecture était en train de lire. Parce que le Moteur de base de données lit les données blobs par blocs plutôt que de télécharger des fichiers entiers, cette erreur peut survenir en cours d’ensemble de résultats :

The operating system returned error <error details> while reading from the file '<url>'.

Pour résoudre l’une de ces erreurs, passez à l’authentification d’identité gérée, ajoutez une règle FQDN sortante correspondant au nom hôte du compte de stockage, ou déplacez le compte de stockage dans le même périmètre que le serveur logique.

Pour obtenir plus d’informations de diagnostic sur l’initialisation de la cible et les échecs d’écriture dans la mémoire tampon, consultez le journal du moteur Extended Events :

SELECT CONVERT(xml, record) AS record_xml
FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type = 'RING_BUFFER_XE_LOG';

Les changements d’association de périmètre et les changements de mode d’accès apparaissent dans le journal d’activité Azure pour le serveur logique. Les évaluations des règles entrantes et sortantes apparaissent dans les journaux de diagnostic du périmètre de sécurité réseau.

Gouvernance des ressources

Dans Azure SQL Database, la consommation de mémoire par les sessions d’événements étendues est contrôlée dynamiquement par les Moteur de base de données pour réduire la contention des ressources.

Il existe une limite de mémoire disponible pour les sessions d’événements :

  • Dans une base de données unique, la mémoire de session totale est limitée à 128 Mo.
  • Dans un pool élastique, les bases de données individuelles sont soumises aux limites des bases de données uniques et au total, elles ne peuvent pas dépasser 512 Mo.

Si vous recevez un message d’erreur référençant une limite de mémoire, les actions correctives que vous pouvez effectuer sont les suivantes :

  • Réduisez le nombre de sessions d’événements simultanées.
  • En utilisant les instructions CREATE et ALTER pour des sessions d’événements, réduisez la quantité de mémoire que vous spécifiez dans la clause MAX_MEMORY de la session.

Note

Dans les événements étendus, la clause MAX_MEMORY apparaît dans deux contextes : lors de la création ou de la modification d’une session (au niveau de la session) et lors de l’utilisation de la cible ring_buffer (au niveau cible). Les limites ci-dessus s’appliquent à la mémoire au niveau de la session.

Le nombre de sessions d’événements démarrées dans Azure SQL Database est limité :

  • Dans une base de données unique, la limite est de 100.
  • Dans un pool élastique, la limite est de 100 sessions étendues à la base de données par pool.

Dans les pools élastiques denses, le démarrage d’une nouvelle session d’événements étendue peut échouer en raison de contraintes de mémoire, même lorsque le nombre total de sessions démarrées est inférieur à 100.

Pour rechercher la mémoire totale consommée par une session d’événements, exécutez la requête suivante lors de la connexion à la base de données où la session d’événements est démarrée :

SELECT name AS session_name,
       total_buffer_size + total_target_memory AS total_session_memory
FROM sys.dm_xe_database_sessions;

Pour trouver la mémoire totale de session d’événements pour un pool élastique, cette requête doit être exécutée dans chaque base de données du pool.

Contenu connexe

  • Last updated on