故障排除指南本身不会收集遥测数据。 他们会读取你分别启用的遥测数据，然后将其联接起来。 如果你知道每个数据源背后对应的是什么，就能更轻松地预测在未启用某项功能时哪些图表会变为空白，也能更好地判断某个数字的可信程度。
诊断日志类别
在服务器上的诊断设置中配置这些类别，并将其路由到Log Analytics工作区。 门户显示这些名称。
| 类别 | 它捕获的内容 | 基础源 | 备注 |
|---|---|---|---|
| PostgreSQL 服务器日志 | 错误、警告、连接和断开连接消息、锁定等待、autovacuum 完成记录、检查点记录。 | PostgreSQL 服务器日志 | 内容完全取决于参数 log_* 。 如果 log_lock_waits 处于关闭状态，则即使启用了此类别，也不会有锁定数据到达指南。 |
| 会话数据 | 每个后端进程在某一时刻的快照：PID、状态、等待事件，以及用于推导连接、事务和查询时长的时间戳。 | pg_stat_activity |
离散采样，而非连续。 持续时间短于采样间隔的活动可能无法被检测到。 需要 metrics.collector_database_activity。 |
| 查询存储运行时 | 按时间桶聚合的每个查询统计信息：调用次数、平均耗时和总耗时、行数、共享块命中次数和读取次数、临时块以及 I/O 耗时。 | 查询存储 | 以查询 ID 作为键，绝不要以文本作为键。 受 pg_qs.query_capture_mode 限制。 |
| 查询存储等待统计信息 | 将采样的等待事件归因于处于等待状态的查询 ID。 | pgms_wait_sampling |
通过此数据，可以回答“导致此等待的查询”。 受 pgms_wait_sampling.query_capture_mode 限制。 |
| Autovacuum 和模式统计信息 | 每个表的存活元组数和死元组数、插入/更新/删除活动，以及最后一次清理和分析的时间戳。 | pg_stat_user_tables |
指南中的每项膨胀量计算都以此为依据。 |
| 剩余事务 | 每个数据库的事务 ID 年龄，以及在回卷保护启动前剩余的事务数。 | 数据库 XID 年龄 | 在两个 autovacuum 指南中触发回卷警告。 |
| AllMetrics | 平台指标：CPU、内存、存储、IOPS 和增强指标。 | Azure Monitor | 不是 PostgreSQL 数据。 此数据是平台自己的主机视图。 |
指南所依赖的服务器参数
某些选项卡需要一个参数集，然后才能显示任何内容，独立于诊断设置。
| 参数 | 需要方 | 取消设置时的效果 | 重启 |
|---|---|---|---|
pg_qs.query_capture_mode |
每个查询选项卡 | 任何地方都没有查询归属信息。 设置为 TOP 或 ALL。 |
否 |
log_line_prefix |
仅 CPU 查询、本机日志记录视图 | 基于日志的查询图表保持空。 使用 查询存储 时不需要这样做，因为它在主副本和副本上都是主要来源。 必须与预期的格式完全匹配。 | 否 |
log_min_duration_statement |
仅 CPU 查询、本机日志记录视图 | 没有来自日志的语句持续时间数据。 使用查询存储时不需要。 不使用 0。 |
否 |
pgms_wait_sampling.query_capture_mode |
等待 选项卡 | 不会对等待事件进行采样，因此无法进行等待分析。 设置为 ALL。 |
否 |
metrics.collector_database_activity |
会话、 工作负荷、增强指标 | 没有会话快照，也没有各数据库的活动情况。 | 否 |
track_io_timing |
IOPS 查询选项卡 |
blk_read_time 并且 blk_write_time 保持零，因此无法按 I/O 对查询进行排名。 |
否 |
log_autovacuum_min_duration |
每个表的自动清理 | 没有各表的 autovacuum 记录。 必须是非负数。 | 否 |
log_lock_waits |
CPU 锁定和阻塞 | 锁等待绝不会被记录。 当等待超过 deadlock_timeout时记录消息。 |
否 |
pg_qs.emit_query_text |
从遥测而不是数据库解析查询文本 | 无法从Log Analytics读取查询文本。 仅在回退路径中需要，因为 查询存储 会直接在主副本和副本上解析文本。 | 否 |
pgbouncer.enabled、metrics.pgbouncer_diagnostics |
PgBouncer 指标 | 无池器可见性。 Burstable 不支持。 | 否 |
保留期因源而异
在查找昨天看到的查询 ID 后面的 SQL 文本时，这种差异可能会导致混淆。
- Log Analytics 中的遥测数据会根据你的工作区保留设置进行保留，通常会长得多。
-
数据库中的 查询存储 数据按
pg_qs.retention_period_in_days保留。
后果是：这些指南可能会向你显示某个查询 ID，但它对应的文本已经从 azure_sys 中消失了。
当历史文本很重要时，启用pg_qs.emit_query_text查询文本类别并将其路由到Log Analytics，以便文本与统计信息一起保留。
准确读出数字
| 特性 | 它为何重要 |
|---|---|
| 会对会话和等待数据进行采样 | 在样本之间运行 200 毫秒的查询不会留下任何跟踪。 在会话选项卡中没有相关记录，并不意味着相关情况不存在。 |
| 已存储查询存储数据 | 统计数据被聚合到时间桶中。 桶中的平均值会掩盖方差，因此在断定某个查询始终很快之前，请先检查最小值和最大值。 |
| Autovacuum 参考线 筛选器 | 仅显示实时元组和死元组阈值上方的表，因此计数不会与直接 pg_stat_user_tables 查询协调。 |
| 已分析的 Autovacuum 指南 上限数据库 | 超过上限的服务器按创建 （OID） 顺序以无提示方式排除数据库。 本指南会在发生这种情况时发出警告。 |
| 数据使用量可能超过物理内存 | 在执行期间被反复固定的页面，每次都会被计入，因此查询报告的数据使用量确实可能超过 shared_buffers 或总内存容量。 |
| 显示的参数值是 服务器级 | 每个表的存储参数 ALTER ROLE ... SET 和每个会话的 SET 都不会被反映出来。 指南可能显示的是一个看起来正常的默认设置，而某个特定的表或角色实际运行的却完全是另一套东西。 |