Azure Log Analytics查询Postgres灵活服务器user_id_s列报错

该报错和功能配置无关，核心是两个问题叠加导致：

1. Azure Database for PostgreSQL Flexible Server不同迭代版本的Query Store日志Schema存在差异，部分新版本实例输出的QueryStoreRuntimeStatistics类别日志已经移除了user_id_s字段，内置模板没有做跨版本兼容。
2. 原内置模板本身存在语法疏漏：summarize聚合语句中对执行时间做了类型转换嵌套，不会自动生成avg_mean_time_s的默认列名，就算解决字段不存在的问题，后续执行也会触发找不到avg_mean_time_s列的报错。

• 验证当前日志实际字段结构
  在Log Analytics中执行以下查询，拉取近1小时该类别的日志字段清单，确认实际输出字段：

  AzureDiagnostics
  | where ResourceProvider == "MICROSOFT.DBFORPOSTGRESQL"
  | where Category == "QueryStoreRuntimeStatistics"
  | where TimeGenerated > ago(1h)
  | take 1
  | getschema
  

  如果返回结果中无user_id_s字段，属于新版本的正常变更：系统用户（user_id=10）的查询已经在日志采集侧做了默认过滤，不需要手动加排除条件。如果存在该字段，属于日志解析临时异常，等待15分钟后重试即可。
• 验证实例侧Query Store运行状态
  连接PostgreSQL实例执行以下SQL，确认Query Store相关参数开启：

  SELECT name, setting FROM pg_settings WHERE name LIKE 'pg_qs.%';
  

  确认pg_qs.enabled、pg_qs.track_utility参数值为on，如果为off，调整参数后重启实例，等待30分钟让日志同步到Log Analytics即可。

以下版本做了Schema兼容，同时修复了原模板的别名疏漏，可在所有版本的Flexible Server上正常运行：

// Slowest queries 
// Identify top 5 slowest queries, compatible with all PostgreSQL Flexible Server log schema versions
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DBFORPOSTGRESQL"
| where Category == "QueryStoreRuntimeStatistics"
// 仅当user_id_s字段存在时，执行Azure系统内置用户过滤逻辑
| where isnull(columnifexists('user_id_s')) or user_id_s != "10"
| summarize avg_mean_time_s = avg(todouble(mean_time_s)) by event_class_s, db_id_s, query_id_s
| top 5 by avg_mean_time_s desc

• 如果需要查看query_id对应的具体SQL文本，需要在实例的诊断设置中同时开启QueryStoreRuntimeStatistics和QueryStoreWaitStatistics两个日志类别，否则只能拿到查询ID无法匹配语句内容。
• PostgreSQL实例侧生成的日志同步到Log Analytics存在5-15分钟的延迟，查询时建议将时间范围设置为距当前时刻15分钟之前，避免因数据未同步导致结果为空。

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