Расширенные события в SQL Azure

Область применения:База данных SQL AzureУправляемый экземпляр SQL Azureбаза данных SQL в Fabric

Общие сведения о расширенных событиях см. в статье:

Набор функций, функциональные возможности и сценарии использования расширенных событий в Базе данных SQL Azure, базе данных SQL в Fabric и Управляемом экземпляре SQL Azure похожи на то, что доступно в SQL Server. Основные различия:

  • В База данных SQL Azure, SQL базе данных в Fabric и управляемом экземпляре Azure SQL всегда используются блобы в служба хранилища Azure, а не файлы на диске.
    • В SQL Server целевой event_file объект может использовать файлы на диске или блобы в службе хранилища Azure.
  • В Базе данных SQL в Azure и Базе данных SQL в Fabric сеансы событий всегда ограничены областью базы данных. Это означает, что:
    • Сеанс событий в одной базе данных не может собирать события из другой базы данных.
    • Событие должно происходить в контексте пользовательской базы данных, включаемой в сеанс.
  • В Управляемом экземпляре SQL Azure можно создавать сеансы событий с областью действия на уровне сервера и базы данных. Мы рекомендуем использовать сеансы событий уровня сервера для большинства сценариев.

Get started

Существует два пошаговых примера, которые помогут вам быстро приступить к работе с расширенными событиями:

Extended Events можно использовать для мониторинга реплик, доступных только для чтения. Дополнительные сведения см. в статье "Чтение запросов на реплики".

Лучшие практики

Следуйте приведенным ниже рекомендациям по безопасному и надежному использованию расширенных событий без ущерба для стабильности работы ядра СУБД и производительности рабочей нагрузки.

  • Если вы используете целевой event_file объект:
    • В зависимости от событий, добавленных в сеанс, файлы, созданные event_file целевым объектом, могут содержать конфиденциальные данные. Тщательно просмотрите назначения ролей RBAC и списки управления доступом (ACL) в учетной записи хранения и контейнере, включая унаследованный доступ, чтобы избежать предоставления ненужного доступа на чтение. Следуйте принципу наименьших привилегий.
    • Используйте учетную запись хранилища в том же регионе Azure, что и база данных или управляемый экземпляр, для которых вы создаете сеансы событий.
    • Приведите избыточность учетной записи хранения в соответствие с избыточностью базы данных, эластичного пула или управляемого экземпляра. Для локальных избыточных ресурсов используйте LRS, GRS или RA-GRS. Для ресурсов с избыточностью между зонами используйте ZRS, GZRS или RA-GZRS. Дополнительные сведения см. в разделе Избыточность службы хранилища Azure.
    • Не используйте уровень доступа к BLOB-объектам, кроме Hot.
    • Не включите иерархическое пространство имен для учетной записи хранения.
  • Если вы хотите создать непрерывно работающий сеанс событий, который автоматически запускается после каждого перезапуска ядра СУБД (например, после переключения при отказе или события обслуживания), включите параметр сеанса событий STARTUP_STATE = ON в инструкции CREATE EVENT SESSION или ALTER EVENT SESSION.
  • Напротив, используйте STARTUP_STATE = OFF для краткосрочных сеансов событий, например для нерегламентированного устранения неполадок.
  • В Базе данных SQL Azure не следует считывать события взаимоблокировки из встроенного сеанса событий dl. Если собрано большое количество событий взаимоблокировки, их чтение с помощью функции sys.fn_xe_file_target_read_file() может вызвать ошибку нехватки памяти в базе данных master. Это может повлиять на обработку входа и привести к сбою приложения. Сведения о рекомендуемых способах отслеживания взаимоблокировок см. в статье Сбор графов взаимоблокировок в Базе данных SQL Azure с помощью расширенных событий.

Целевые объекты сеанса событий

Дополнительные сведения о целевых объектах расширенных событий, поддерживаемых в базе данных SQL Azure, базе данных SQL в Fabric, Управляемом экземпляре SQL Azure и SQL Server, см. в разделе "Целевые объекты для расширенных событий".

различия Transact-SQL

При выполнении операторов CREATE EVENT SESSION, ALTER EVENT SESSION и DROP EVENT SESSION в SQL Server и Управляемый экземпляр SQL Azure используется предложение ON SERVER. В Базе данных SQL Azure вместо этого используется предложение ON DATABASE, так как в Базе данных SQL Azure сеансы событий ограничены областью базы данных.

Представления каталога расширенных событий

Расширенные события предоставляют несколько представлений каталога. Представления каталога содержат сведения о метаданных или определении сеанса события. Эти представления не возвращают сведения об экземплярах активных сеансов событий.

Список представлений каталога для каждой платформы см. в разделе "Представления каталога расширенных событий".

Динамические административные представления для расширенных событий

Расширенные события предлагают несколько динамических административных представлений (DMV). Динамические административные представления возвращают сведения о запущенных сеансах событий.

Список представлений динамического управления для каждой платформы см. в разделе "Представления динамического управления расширенных событий".

Часто используемые DMV

Существуют дополнительные динамические административные представления (DMV) расширенных событий, общие для Базы данных Azure SQL, Управляемого экземпляра Azure SQL и SQL Server:

Доступные события, действия и целевые объекты

С помощью этого запроса можно получить доступные события, действия и целевые объекты:

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

Смотрите разрешения для получения подробной информации по каждой платформе.

Авторизация и управление контейнером хранилища

При использовании целевой event_file настройки для двоичных объектов хранилища Azure, ядро СУБД, выполняющее сеанс событий, должно иметь определенный доступ к контейнеру BLOB-объектов. Этот доступ можно предоставить одним из следующих способов:

  • Назначьте роль Storage Blob Data Contributor RBAC для управляемого удостоверения логического сервера Azure SQL или управляемого экземпляра Azure SQL на контейнере и создайте учетные данные, чтобы указать ядру СУБД использовать управляемое удостоверение для аутентификации.

    Вместо назначения роли RBAC Storage Blob Data Contributor можно назначить следующие действия 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

  • Создайте маркер SAS для контейнера и сохраните маркер в учетных данных.

    В Базе данных SQL Azure необходимо использовать учетные данные уровня базы данных. В Управляемом экземпляре SQL Azure и SQL Server используйте учетные данные на уровне сервера.

    Создаваемый для контейнера служба хранилища Azure маркер SAS должен соответствовать следующим требованиям:

    • Иметь разрешения rwdl (Read, Write, Delete, List).
    • Укажите время начала и время окончания, которые охватывают весь срок действия сеанса события.
    • Нет ограничений IP-адресов.

Периметр безопасности сети (предварительная версия)

Периметр сетевой безопасности (предварительная версия) создаёт границу сетевого доступа для База данных SQL Azure и других ресурсов платформы Azure типа "платформа как услуга" (PaaS). Когда вы связываете логический сервер с сетевым периметром безопасности (NSP), исходящие соединения Extended Events с служба хранилища Azure подчиняются правилам доступа периметра.

Note

Сетевой периметр безопасности доступен только для База данных SQL Azure. Этот раздел не применяется к Управляемый экземпляр SQL Azure или SQL Database in Fabric. Будучи функцией предварительной версии, периметр сетевой безопасности подпадает под действие Дополнительных условий использования предварительных версий Microsoft Azure.

Как расширенные события используют доступ к сети

Extended Events осуществляет исходящие соединения с ядро СУБД с служба хранилища Azure в двух случаях:

  • Запись данных о событиях. Когда вы запускаете сеанс событий с целевым объектом event_file, указывающим на BLOB-объект, компонент ядро СУБД проверяет исходящий доступ до начала сеанса, а затем повторно при каждом сбросе буферов событий в BLOB-объект.
  • Чтение событийных данных. Когда вы вызываете sys.fn_xe_file_target_read_file или sys.fn_MSxe_read_event_stream с URL blob, ядро СУБД проверяет исходящий доступ при инициализации функции. SSMS вызывает sys.fn_MSxe_read_event_stream, когда вы открываете захваченные данные событий в просмотрщике событий.

Входящие TDS-соединения, используемые для управления сессиями событий через T-SQL, не требуют какой-либо NSP-конфигурации, специфичной для расширенных событий. Инструкции CREATE EVENT SESSION, ALTER EVENT SESSION и DROP EVENT SESSION, а также функции read выполняются через обычное клиентское подключение, поэтому они подчиняются тем же правилам входящего доступа, что и любое другое клиентское подключение к базе данных.

Поддерживаемые конфигурации

Поведение зависит от режима доступа периметра, от того, находится ли аккаунт хранения в том же периметре, что и логический сервер, и от того, связаны ли между собой два разных периметра.

логический сервер SQL NSP Аккаунт хранения NSP Behavior
Нет NSP Нет NSP Периметр не оценивает соединение. Extended Events подключается к учётной записи хранения, используя настроенные вами учётные данные и правила брандмауэра учётной записи хранения. Для получения дополнительной информации см . раздел «Авторизация и управление контейнером для хранения».
Нет NSP В одном NSP Периметр не оценивает исходящий доступ с логического сервера. Удастся ли установить соединение, зависит от правил входящего трафика собственного периметра учетной записи хранения.
В NSP (принудительно) Тот же NSP Доступ всегда разрешен. Вам не нужно исходящее правило.
В NSP (принудительно) Другие, но связанные NSP Доступ разрешён согласно межпериметровым правилам. Вам не требуется правило FQDN для исходящего трафика.
В NSP (принудительно) Разные несвязанные NSP или их отсутствие Доступ разрешен, когда вы используете управляемую личность или если исходящее правило FQDN в профиле периметра совпадает с именем хоста аккаунта хранения. Если вы используете токен SAS и нет совпадений правил, сессия события не начинается с ошибкой 25602, а функции чтения могут провалиться с ошибкой 25759.
в NSP (переходный режим) Any Периметр оценивает и фиксирует правила, но не блокирует движение.

Настройте исходящий доступ к аккаунту хранения

Когда вы настраиваете базу данных для использования расширенных событий, вы можете выбрать между управляемой идентичностью и аутентификацией токенов SAS . Выбранный вами механизм аутентификации определяет, потребуется ли вам правило исходящего доступа.

  1. Проверьте связь по периметру. В портале Azure выполните поиск по запросу Network Security Perimeter, выберите ваш периметр, а затем выберите Associated Resources в меню настроек, чтобы убедиться, что ваш сервер в списке. Для получения дополнительной информации см. Периметр сетевой безопасности.
  2. Выберите свой механизм аутентификации. Используйте управляемую аутентификацию личности. Токен управляемой идентификации включает утверждения, которые нужны периметру, поэтому вам не нужно добавлять правило для исходящего трафика, и вы можете пропустить следующий шаг.
  3. Добавьте правило исходящего доступа (только SAS-токен). Если вы используете токен SAS и периметр находится в режиме принудительного режима, добавьте правило исходящего доступа в профиль периметра. Используйте тип правила Полностью квалифицированные доменные имена (FQDN ) и имя хоста вашего аккаунта хранения в качестве значения, например myxedata.blob.core.windows.net.

В этом примере можно использовать *.blob.core.windows.net, чтобы разрешить доступ для всех учетных записей служба хранилища Azure, однако этот параметр разрешает исходящие подключения к учетным записям хранилища, которые вам не принадлежат. Используйте конкретное имя хоста, где можете.

Сохраняйте периметр в режиме перехода, пока не определите, какие правила исходящего трафика вам нужны. В режиме перехода периметр ведёт оценки правил без блокировки доступа, так что вы можете найти отсутствующие правила до того, как они вызовут сбои. Переключитесь в принудительный режим после настройки правил.

Ограничения и различия в поведении

  • ядро СУБД проверяет исходящий доступ при начале сессии и при каждом промывке буфера. Если убрать исходящее правило во время сессии, сессия не останавливается. Вместо этого начинают давать сбой отдельные буферные записи.
  • Управляемые идентичности и токены SAS не эквивалентны в пределах периметра. Управляемый идентификационный токен несёт претензии на периметр, поэтому ему не требуется правило выхода. Токен SAS не содержит этих утверждений, поэтому для него требуется соответствующее исходящее правило в принудительном режиме.
  • Заблокированная функция чтения может не выдавать ошибку. Когда периметр блокирует sys.fn_xe_file_target_read_file или sys.fn_MSxe_read_event_stream, функция может вызвать ошибку 25759 или 25717, или вернуть пустой набор результатов без ошибки. Если вы ожидаете данные, но не получаете ни одной строки и не видите ошибки, проверьте правила исходящего трафика.

Ошибки, когда периметр блокирует доступ

Ошибка 25602 означает, что целевой объект event_file не удалось инициализировать, поскольку периметр безопасности заблокировал исходящее подключение к учётной записи хранения:

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.

Ошибка 25759 означает, что периметр заблокировал функцию считывания:

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

Ошибка 25717 означает, что доступ был отозван во время выполнения функции чтения. Поскольку ядро СУБД читает данные blob частями, а не скачивает целые файлы, эта ошибка может возникнуть на середине набора результатов:

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

Чтобы устранить любую из этих ошибок, перейдите на управляемую аутентификацию идентичности, добавьте исходящее правило FQDN, совпадающее с именем хоста аккаунта хранилища, или переместите аккаунт хранения в тот же периметр, что и логический сервер.

Для получения дополнительной диагностической информации о инициализации цели и ошибках записи буфера запросите в журнал движка Extended Events:

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

Изменения связей периметра и режимов доступа отображаются в журнале активности Azure для логического сервера. Оценки входящих и исходящих правил отображаются в диагностических журналах сетевого периметра.

Управление ресурсами

В Базе данных SQL Azure потребление памяти сеансами расширенных событий динамически контролируется ядром СУБД, чтобы свести к минимуму конкуренцию за ресурсы.

Существует ограничение на память, доступную для сеансов событий:

  • В одной базе данных общий объем памяти сеанса ограничен 128 МБ.
  • В эластичном пуле отдельные базы данных ограничены ограничениями одной базы данных, и в общей сложности они не могут превышать 512 МБ.

Если вы получаете сообщение об ошибке, ссылающееся на ограничение памяти, можно выполнить следующие действия:

  • уменьшить количество одновременно запущенных сеансов событий;
  • При использовании инструкций CREATE и ALTER для сеансов событий уменьшите объем памяти, задаваемый в предложении MAX_MEMORY для сеанса.

Note

В Extended Events конструкция MAX_MEMORY встречается в двух контекстах: при создании или изменении сеанса (на уровне сеанса) и при использовании цели ring_buffer (на целевом уровне). Указанные выше ограничения применяются к памяти уровня сеанса.

В База данных SQL Azure существует ограничение на количество запущенных сеансов событий:

  • В одной базе данных ограничение равно 100.
  • В эластичном пуле лимит составляет 100 сеансов с областью действия базы данных для каждого пула.

В плотных эластичных пулах запуск нового расширенного сеанса событий может завершиться ошибкой из-за ограничений памяти, даже если общее количество запущенных сеансов ниже 100.

Чтобы найти общую память, потребляемую сеансом событий, выполните следующий запрос во время подключения к базе данных, в которой запущен сеанс событий:

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

Чтобы найти общую память сеанса событий для эластичного пула, этот запрос необходимо выполнить в каждой базе данных в пуле.

Связанный контент

  • Last updated on