Azure GP托管实例扩展事件停止记录新事件，求排查方向

我在GP托管实例上运行一个扩展事件，配置和本地环境完全一致：捕获severity>10的error_reported事件，保留10MB历史数据，本地已稳定运行一年以上。但本周Azure环境中该事件突然停止记录新事件——昨日还记录了144条“Cannot insert duplicate key”错误，之后再无任何记录，即使执行select 1/0（可触发该事件）也无日志输出。

疑问：是创建语句存在疏漏？还是托管实例的ring buffer特性导致？或是遇到了Bug？

事件创建语句 #

CREATE EVENT SESSION
severity_10plus_errors_XE_memory
ON server
ADD EVENT sqlserver.error_reported
(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_hostname,
sqlserver.database_id,sqlserver.sql_text,sqlserver.tsql_stack,sqlserver.username,
sqlserver.client_pid)
WHERE ([severity]> 10) 
)
    ADD TARGET
        package0.ring_buffer
            (SET
                max_memory = 10000  ) -- Units of KB.
WITH (MAX_DISPATCH_LATENCY = 60SECONDS,STARTUP_STATE = on)
GO

DMV查询语句 #

SELECT *
    FROM sys.dm_xe_session_targets        AS st  --For Azure SQL DB, use dm_xe_database_session_targets
    INNER JOIN sys.dm_xe_sessions       AS se --For Azure SQL DB, use dm_xe_database_sessions
         ON CAST(se.address AS BINARY(8)) = CAST(st.event_session_address AS BINARY(8))
WHERE
se.name = 'severity_10plus_errors_XE_memory' AND st.target_name = 'ring_buffer'

查询结果 #

bytes_written              : 0
address                    : {0, 0, 1, 160...}
name                       : severity_10plus_errors_XE_memory
pending_buffers            : 0
total_regular_buffers      : 3
regular_buffer_size        : 1441587
total_large_buffers        : 0
large_buffer_size          : 0
total_buffer_size          : 4324761
buffer_policy_flags        : 0
buffer_policy_desc         : drop_event
flags                      : 2049
flag_desc                  : flush_on_close
dropped_event_count        : 0
dropped_buffer_count       : 0
blocked_event_fire_time    : 0
create_time                : 4/28/2023 9:37:41 PM
largest_event_dropped_size : 0
session_source             : server
buffer_processed_count     : 2249
buffer_full_count          : 0
total_bytes_generated      : 290056170
total_target_memory        : 10240000

问题排查分析 #

1. 创建语句无明显疏漏 #

你的扩展事件创建语句完全符合Azure SQL托管实例的要求：

• 针对服务器级事件使用ON server，托管实例原生支持该语法；
• ring_buffer目标的max_memory=10000（对应10MB）配置准确；
• STARTUP_STATE = on确保实例重启后事件会话自动恢复运行；
• WHERE子句过滤severity>10错误的逻辑和本地环境一致，无语法或逻辑错误。

2. Ring Buffer特性并非直接原因 #

从DMV查询结果的关键指标来看：

• dropped_event_count和dropped_buffer_count均为0，说明没有因为内存不足丢弃事件；
• buffer_full_count为0，意味着ring buffer从未被填满，不存在循环覆盖导致的旧数据替换；
• total_target_memory=10240000（10MB）与配置一致，内存分配正常。
  因此ring buffer的机制本身不是停止记录的原因。

3. 重点排查方向 #

（1）确认事件会话运行状态

虽然DMV显示会话存在，仍需确认其是否处于运行状态：

SELECT name, status, startup_state 
FROM sys.dm_xe_sessions 
WHERE name = 'severity_10plus_errors_XE_memory';

如果status不是running，说明会话已意外停止，可手动启动：

ALTER EVENT SESSION severity_10plus_errors_XE_memory ON server STATE = START;

（2）检查会话内部状态异常

即使会话显示运行，也可能存在内部缓冲阻塞。可尝试重启会话重置状态：

ALTER EVENT SESSION severity_10plus_errors_XE_memory ON server STATE = STOP;
ALTER EVENT SESSION severity_10plus_errors_XE_memory ON server STATE = START;

重启后执行select 1/0测试，查看是否恢复记录。

（3）排查托管实例环境变更

检查托管实例近期是否有以下变更：

• 平台补丁升级或服务层级调整；
• 服务器级权限或配置变更；
  这些操作可能导致扩展事件会话出现异常。

（4）托管实例特定Bug可能性

如果上述操作均无效，需考虑是否遇到Azure SQL托管实例的扩展事件相关Bug：

• 查看Azure门户的服务健康面板，确认是否有已知的平台问题；
• 收集会话详细状态（如查询sys.dm_xe_session_events），提交Azure支持工单进一步排查。

内容的提问来源于stack exchange，提问作者mbourgon