Eventos extendidos en Azure SQL

Se aplica a:Azure SQL DatabaseAzure SQL Managed InstanceBase de datos SQL en Fabric

Para obtener una introducción a los eventos extendidos, consulte:

• Eventos extendidos
• Inicio rápido: eventos extendidos

El conjunto de características, la funcionalidad y los escenarios de uso para eventos extendidos en Azure SQL Database, SQL Database en Fabric e Instancia administrada de Azure SQL son similares a lo que está disponible en SQL Server. Las diferencias principales son:

• En Azure SQL Database, SQL Database en Fabric y Azure SQL Managed Instance, el destino event_file siempre utiliza blobs en Azure Storage, en lugar de archivos en disco.
  • En SQL Server, el event_file destino puede usar archivos en disco o blobs en Azure Storage.
• En Azure SQL Database y SQL Database en Fabric, las sesiones de eventos siempre tienen ámbito de base de datos. Esto significa que:
  • Una sesión de eventos en una base de datos no puede recopilar eventos desde otra base de datos.
  • Debe producirse un evento en el contexto de una base de datos de usuario que se incluirá en una sesión.
• En Azure SQL Managed Instance, puede crear sesiones de eventos con ámbito de servidor y ámbito de base de datos. Se recomienda usar sesiones de eventos con ámbito de servidor para la mayoría de los escenarios.

Get started

Hay dos ejemplos detallados para ayudarle a comenzar rápidamente con Eventos Extendidos.

• Cree una sesión de eventos con un destino de event_file en Azure Storage. En este ejemplo se muestra cómo capturar datos de eventos en un archivo (blob) en Azure Storage mediante el event_file destino e incluye instrucciones para solucionar problemas de errores comunes. Úselo si necesita conservar los datos de eventos capturados o si desea usar el visor de eventos en SQL Server Management Studio (SSMS) para analizar los datos capturados.
• Cree una sesión de eventos con un destino de ring_buffer en memoria. En este ejemplo se muestra cómo capturar los eventos más recientes de una sesión de eventos en la memoria mediante el destino ring_buffer. Úselo como una manera rápida de examinar los eventos recientes durante investigaciones ad hoc o solución de problemas, sin tener que almacenar datos de eventos capturados.

Los eventos extendidos se pueden usar para supervisar las réplicas de solo lectura. Para obtener más información, consulte Consultas de lectura en réplicas.

procedimientos recomendados

Adopte los siguientes procedimientos recomendados para usar eventos extendidos de forma segura, confiable y sin afectar al rendimiento de la carga de trabajo y el estado del motor de base de datos.

• Si usa el destino event_file:
  • En función de los eventos agregados a una sesión, los archivos generados por el event_file destino pueden contener datos confidenciales. Revise cuidadosamente las asignaciones de roles de RBAC y las listas de control de acceso (ACL) en la cuenta de almacenamiento y el contenedor, incluido el acceso heredado, para evitar conceder acceso de lectura innecesario. Siga el principio de privilegios mínimos.
  • Use una cuenta de almacenamiento en la misma región de Azure que la base de datos o la instancia administrada donde se crean sesiones de eventos.
  • Alinee la redundancia de la cuenta de almacenamiento con la redundancia de la base de datos, el grupo elástico o la instancia administrada. Para los recursos con redundancia local, use LRS, GRS o RA-GRS. Para los recursos con redundancia de zona, utilice ZRS, GZRS o RA-GZRS. Consulte Redundancia de Azure Storage para más detalles.
  • No use ningún nivel de acceso de blob distinto de Hot.
  • No habilite el espacio de nombres jerárquico para la cuenta de almacenamiento.
• Si desea crear una sesión de eventos en ejecución continua que se inicie automáticamente después de cada reinicio de Motor de base de datos (por ejemplo, después de una conmutación por error o un evento de mantenimiento), incluya la opción de sesión de eventos de STARTUP_STATE = ON en las instrucciones CREATE EVENT SESSION o ALTER EVENT SESSION.
• Por el contrario, use STARTUP_STATE = OFF para sesiones de eventos a corto plazo, como las que se usan en la solución de problemas ad hoc.
• En la base de datos de Azure SQL, no leas los eventos de interbloqueo de la sesión de eventos integrada dl. Si se recopila una gran cantidad de eventos de interbloqueo, leerlos con la función sys.fn_xe_file_target_read_file() puede provocar un error por falta de memoria en la base de datos master. Esto puede afectar al procesamiento de inicio de sesión y provocar una interrupción de la aplicación. Para conocer las formas recomendadas de supervisar interbloqueos, consulta Recopilación de gráficos de interbloqueo en la base de datos de Azure SQL con eventos extendidos.

Objetivos de sesión de eventos

Para obtener más información sobre los destinos de eventos extendidos admitidos en Azure SQL Database, SQL Database en Fabric, Azure SQL Managed Instance y SQL Server, consulte Destinos para eventos extendidos.

Diferencias de Transact-SQL

Al ejecutar las instrucciones CREATE EVENT SESSION, ALTER EVENT SESSION y DROP EVENT SESSION en SQL Server y en Azure SQL Managed Instance, se usa la cláusula ON SERVER. En Azure SQL Database, se utiliza en su lugar la cláusula ON DATABASE, porque las sesiones de eventos de Azure SQL Database tienen ámbito de base de datos.

Vistas de catálogo de eventos extendidos

Los eventos extendidos proporcionan varias vistas de catálogo. Las vistas de catálogo le indican los metadatos o la definición de la sesión de eventos. Estas vistas no devuelven información sobre instancias activas de sesiones de eventos.

Para obtener una lista de vistas de catálogo para cada plataforma, consulte Vistas de catálogo de eventos extendidos.

Vistas de administración dinámica de eventos extendidos

Los eventos extendidos proporcionan varias vistas de administración dinámica (DMV). Las DMV devuelven información sobre las sesiones de eventos iniciadas.

Para obtener una lista de DMV para cada plataforma, consulte Vistas de administración dinámica de eventos extendidos.

DMV comunes

Hay DMV de eventos extendidos adicionales que son comunes a Azure SQL Database, Azure SQL Managed Instance y SQL Server:

• sys.dm_xe_map_values
• sys.dm_xe_object_columns
• sys.dm_xe_objects
• sys.dm_xe_packages

Eventos, acciones y destinos disponibles

Puede obtener eventos, acciones y destinos disponibles mediante esta consulta:

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

Consulte permisos para obtener permisos detallados por plataforma.

Autorización de contenedor de almacenamiento y control

Cuando se utiliza el event_file como destino con blobs de Azure Storage, el motor de base de datos que ejecuta la sesión de eventos debe tener un acceso específico al contenedor de blobs. Puede conceder este acceso de una de las maneras siguientes:

• Asigne el rol RBAC de colaborador de datos de Storage Blob a la identidad administrada del servidor lógico de Azure SQL o de la instancia administrada de Azure SQL en el contenedor y cree una credencial para indicar al motor de base de datos que use la identidad administrada para la autenticación.

  Como alternativa a la asignación del rol RBAC de colaborador de datos de Storage Blob, puede asignar las siguientes acciones de RBAC:

  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

• Cree un token de SAS para el contenedor y almacene el token en una credencial.

  En Azure SQL Database, debe usar una credencial de ámbito de base de datos. En Azure SQL Managed Instance y SQL Server, use una credencial con ámbito de servidor.

  El token de SAS que cree para el contenedor de Azure Storage debe cumplir los siguientes requisitos:

  • Tenga los permisos rwdl (Read, Write, Delete, List).
  • Defina la hora de inicio y la de finalización para que cubran toda la duración de la sesión del evento.
  • No tener restricciones de direcciones IP.

Perímetro de seguridad de red (versión preliminar)

El perímetro de seguridad de red (preview) establece un límite de acceso a la red alrededor de Azure SQL Database y otros recursos de la plataforma Azure como servicio (PaaS). Cuando asocias un servidor lógico con un perímetro de seguridad de red (NSP), las conexiones salientes que Extended Events realiza a Azure Storage están sujetas a las reglas de acceso del perímetro.

Cómo utiliza Extended Events el acceso a la red

Extended Events realiza conexiones salientes desde Motor de base de datos a Azure Storage en dos casos:

• Escritura de datos de eventos. Cuando se inicia una sesión de eventos con un destino event_file que apunta a un blob, el Motor de base de datos comprueba el acceso saliente antes de que se inicie la sesión y, de nuevo, cada vez que vacía los búferes de eventos en el blob.
• Leyendo datos de eventos. Cuando se llama a sys.fn_xe_file_target_read_file o sys.fn_MSxe_read_event_stream con una dirección URL de blob, el Motor de base de datos comprueba el acceso saliente al inicializarse la función. SSMS llama a sys.fn_MSxe_read_event_stream al abrir los datos de eventos capturados en el visor de eventos.

Las conexiones TDS entrantes usadas para gestionar sesiones de eventos vía T-SQL no necesitan ninguna configuración NSP específica de eventos extendidos. Las CREATE EVENT SESSIONsentencias , ALTER EVENT SESSION, y DROP EVENT SESSION y las funciones de lectura se ejecutan todas sobre una conexión cliente normal, por lo que siguen las mismas reglas de acceso entrante que cualquier otra conexión cliente a la base de datos.

Configuraciones compatibles

El comportamiento depende del modo de acceso del perímetro, de si la cuenta de almacenamiento está en el mismo perímetro que el servidor lógico y de si dos perímetros diferentes están vinculados entre sí.

Configurar el acceso saliente a la cuenta de almacenamiento

Cuando configuras una base de datos para usar Eventos Extendidos, puedes elegir entre identidad gestionada y autenticación de token SAS . El mecanismo de autenticación que elijas determina si necesitas una regla de acceso saliente.

1. Verifica la vinculación del perímetro. En el portal de Azure, busca Perímetro de Seguridad de Red, selecciona tu perímetro y luego selecciona Recursos Asociados en el menú de Configuración para confirmar que tu servidor está listado. Para más información, consulte perímetro de seguridad de red.
2. Elige tu mecanismo de autenticación. Utiliza autenticación de identidad gestionada. Un token de identidad administrada incluye las declaraciones que necesita el perímetro, por lo que no es necesario añadir una regla de salida y puede omitirse el siguiente paso.
3. Añadir una regla de acceso saliente (solo con token SAS). Si usa un token SAS y el perímetro está en modo de aplicación, agregue una regla de acceso de salida en el perfil del perímetro. Utiliza un tipo de regla de nombres de dominio totalmente calificados (FQDN) y el nombre de host de tu cuenta de almacenamiento como valor myxedata.blob.core.windows.net, por ejemplo.

En este ejemplo, puedes usar *.blob.core.windows.net la opción de permitir todas las cuentas de Azure Storage, pero esa configuración permite conexiones salientes a cuentas de almacenamiento que no posees. Usa el nombre de host específico cuando puedas.

Mantén el perímetro en modo transición hasta que confirmes qué reglas de salida necesitas. En modo transición, el perímetro registra las evaluaciones de reglas sin bloquear el acceso, por lo que puedes encontrar reglas faltantes antes de que causen fallos. Cambia a modo forzado una vez que las normas estén en vigor.

Limitaciones y diferencias de comportamiento

• El Motor de base de datos comprueba el acceso saliente cuando comienza una sesión y en cada vaciado del búfer. Si eliminas una regla de salida mientras la sesión está en marcha, la sesión no se detiene. En su lugar, empiezan a fallar las operaciones individuales de escritura en el búfer.
• Las identidades gestionadas y los tokens SAS no son equivalentes dentro de un perímetro. Un token de identidad administrada incluye reclamaciones perimetrales, por lo que no necesita una regla de salida. Un token de SAS no incluye esas declaraciones, por lo que necesita una regla de salida coincidente en modo de aplicación.
• Una función de lectura bloqueada puede no generar un error. Cuando un perímetro bloquea sys.fn_xe_file_target_read_file o sys.fn_MSxe_read_event_stream, la función puede generar el error 25759 o 25717, o devolver un conjunto de resultados vacío sin error. Si esperas datos pero no se devuelve ninguna fila y no aparece ningún error, revisa tus reglas de salida.

Errores cuando un perímetro bloquea el acceso

El error 25602 significa que el event_file objetivo no pudo inicializarse porque el perímetro bloqueó la conexión saliente con la cuenta de almacenamiento:

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.

El error 25759 significa que un perímetro bloqueó una función de lectura:

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

El error 25717 significa que el acceso fue revocado mientras una función de lectura estaba leyendo. Como el Motor de base de datos lee los datos de blob en bloques en lugar de descargar archivos completos, este error puede ocurrir a mitad de un conjunto de resultados:

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

Para resolver cualquiera de estos errores, cambia a autenticación de identidad gestionada, añade una regla FQDN saliente que coincida con el nombre de host de la cuenta de almacenamiento, o mueve la cuenta de almacenamiento al mismo perímetro que el servidor lógico.

Para obtener más información de diagnóstico sobre la inicialización del destino y los errores de escritura en el búfer, consulta el registro del motor de Extended Events:

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

Los cambios en la asociación de perímetros y los cambios en el modo de acceso aparecen en el registro de actividad de Azure para el servidor lógico. Las evaluaciones de reglas entrantes y salientes aparecen en los registros de diagnóstico del perímetro de seguridad de red.

Gobernanza de recursos

En Azure SQL Database, el consumo de memoria por sesiones de eventos extendidos se controla dinámicamente mediante el Motor de base de datos para minimizar la contención de recursos.

Hay un límite en la memoria disponible para las sesiones de eventos:

• En una base de datos única, la memoria total de sesión se limita a 128 MB.
• En un grupo elástico, las bases de datos individuales están limitadas por los límites de base de datos única y, en total, no pueden superar los 512 MB.

Si recibe un mensaje de error que hace referencia a un límite de memoria, las acciones correctivas que puede realizar son:

• Ejecute menos sesiones de eventos simultáneas.
• Use las instrucciones CREATE y ALTER para las sesiones de eventos y reduzca la cantidad de memoria especificada en la cláusula MAX_MEMORY de la sesión.

Hay un límite en el número de sesiones de evento iniciadas en Azure SQL Database:

• El límite es de 100 en una base de datos única.
• En un grupo elástico, el límite es de 100 sesiones con ámbito de base de datos por grupo.

En grupos elásticos densos, puede producirse un error al iniciar una nueva sesión de eventos extendidos debido a las restricciones de memoria incluso cuando el número total de sesiones iniciadas es inferior a 100.

Para buscar la memoria total consumida por una sesión de eventos, ejecute la consulta siguiente mientras está conectada a la base de datos donde se inicia la sesión de eventos:

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

Para buscar la memoria total de la sesión de eventos de un grupo elástico, esta consulta debe ejecutarse en todas las bases de datos del grupo.

Contenido relacionado

• Eventos extendidos
• Inicio rápido: Eventos extendidos
• Perímetro de seguridad de red para Azure SQL Database (vista previa)