云监控与 SaaS 工具
前面几页的方案有一个共同前提：监控体系由你自己搭建与运维——采集器自己装、存储自己管、看板自己配。当数据库跑在云托管服务（RDS 类）上，或团队既缺 DBA 人力又想要开箱即用的深度监控时，云厂商自带的监控能力与商业 SaaS 监控平台就成了值得认真评估的第三条路。
这条路的形态有三类：云原生监控（AWS CloudWatch/Performance Insights、阿里云 RDS 监控与 DAS、GCP Cloud Monitoring/Query Insights——与托管数据库深度集成，开通即用）；SaaS 统一可观测性平台（Datadog、New Relic 等——一个 agent 覆盖主机、数据库、应用与中间件，跨云跨 IDC 统一）；开源自托管的托管化变体（Percona PMM——开源免费但提供「像 SaaS 一样完整」的数据库监控体验，可自托管也可用云服务形态）。三类各有清晰的适用边界，选错形态的代价不是「体验差点」，而是成本失控或被供应商锁定。
本页作为本章工具篇的收官，讲清三类形态的能力边界、接入方式、成本模型、数据主权与合规考量，以及混合架构下的组合策略。云厂商的具体指标名、SaaS 的具体配置项都随时间快速演进，本页以能力分类与决策方法论为主，具体清单以各厂商官方文档为准。
前置知识
建议先阅读：pgwatch 监控
基础概念
三类形态的全景定位
自建开源（前几页）
Prometheus / Zabbix / pgwatch
▲ 技能要求高，掌控力最强
│
┌───────────────┬──────────┴──────────┬──────────────────┐
│ 云原生监控 │ SaaS 统一平台 │ 开源+托管化 │
│───────────────│─────────────────────│──────────────────│
│ CloudWatch │ Datadog │ Percona PMM │
│ Performance │ New Relic │ （自托管形态） │
│ Insights │ │ │
│ 阿里云监控/DAS │ │ │
│ Cloud SQL 监控 │ │ │
├───────────────┼─────────────────────┼──────────────────┤
│ 跟数据库绑定 │ 跟组织全栈绑定 │ 跟数据库深度绑定 │
│ 开通即用 │ 一平台看全栈 │ 免费+完整功能 │
│ 出云即失效 │ 按量计费成本敏感 │ 自己运维 │
└───────────────┴─────────────────────┴──────────────────┘三类形态回答的是三个不同的问题：云原生监控回答「这个托管数据库自带什么」；SaaS 平台回答「全公司的技术栈能不能在一个平台看」；PMM 这类回答「要不要数据库专业级的监控但不想付 SaaS 账单」。评估时先问清楚自己的问题，再看产品。
云原生监控：与托管服务共生
数据库托管给云厂商后，监控分成了两层：
| 层 | 内容 | 谁负责 | 例子（概念层） |
|---|---|---|---|
| 平台层 | 实例资源、存储、连接、IOPS、主备状态等 | 云厂商采集，你消费 | 各云的监控指标体系 |
| 数据库层 | 数据库内部语义（查询性能、锁、复制细节） | 部分云提供增值能力，深度受托管边界限制 | 性能洞察类、查询洞察类产品 |
云原生监控的天然优势：零部署（控制台与告警开箱即用）、与计费/配额/运维事件同源（磁盘将满、配额超限、维护窗口这些事件只在云侧知道）、主备拓扑与故障切换自动可见。天然劣势：深度受限于托管边界（你拿不到操作系统层、扩展装不了或受限、统计视图的完整访问受权限模型约束）、出云即失效（多云或混合云场景每朵云一套监控，无法统一）、数据主权在云侧（监控数据的留存与导出受云平台规则约束）。
SaaS 统一可观测性平台
以 Datadog、New Relic 为代表的 SaaS 平台，核心价值主张是一个平台 + 一个 agent 看全栈：
- 采集：主机上装一个 agent，数据库集成通过 agent 的 PostgreSQL 集成（配置连接串）采集统计视图；更深入的 Database Monitoring（DM）类产品能做语句级、执行计划级分析（能力以厂商文档为准）。
- 统一：主机指标、数据库指标、APM 应用链路、日志在同一个平台，跨栈关联排障是杀手锏——「应用变慢」与「数据库连接池饱和」在同一个时间轴上对齐。
- 生态：告警、值班、仪表盘、SLO 管理全套企业级能力。
代价同样清晰：按量计费且单价不菲（主机数 × 数据量 × 功能模块，数据库监控通常是增值模块），以及数据出境（指标与采样语句发到厂商云，合规敏感组织必须过法务）。SaaS 的本质是用钱和信任换人力——适合工程团队强、自建意愿弱、预算充足的场景。
Percona PMM：开源世界的第三条路
Percona PMM（Percona Monitoring and Management）值得单独一类：开源免费、功能对标商业数据库监控、部署形态自选（自托管 Docker/容器编排，也有云服务形态）。对 PostgreSQL 的监控深度覆盖语句级分析（Query Analytics，配合 pg_stat_monitor/pg_stat_statements）、实例总览、副本与备份状态等——它本质上是「把 Datadog 数据库监控的开源等价物自己跑起来」，代价是运维一套 PMM Server（存储用类 Prometheus 的时序库 + 查询分析库）。
统一可观测性：metrics + logs + traces
本章前面的工具都聚焦 metrics（指标），SaaS 平台与新一代理念把三大支柱合流：
可观测性三支柱在数据库排障中的协同：
Metrics（指标）：发现异常
连接飙升、延迟劣化、缓存命中率下跌
↓ 定位到时间窗
Logs（日志）：还原过程
慢查询日志、错误日志、审计日志（第十七章日志篇的产出）
↓ 找到嫌疑语句
Traces（链路）：归因到应用
APM 显示该语句来自哪个服务哪个接口哪次调用
↓ 闭环
慢查询优化流程（本章慢查询篇的六步法）自建体系要做到三支柱合流需要 Prometheus + Loki/ELK + APM 三套系统拼装；SaaS 平台的卖点正是这套拼装的开箱即用。评估 SaaS 时把「数据库指标与 APM/日志的关联深度」作为核心考点——只能看数据库指标不能关联应用的 SaaS，价值减半。
语法与用法
云原生监控的接入与告警
云托管数据库的监控接入本质是「配置消费」而非「搭建采集」：
通用流程（各云的具体入口与产品名以官方文档为准）：
1. 控制台开通监控视图
实例详情页通常自带基础监控大盘（资源层）
2. 需要的增值能力单独开通/评估
性能洞察类（逐语句耗时分析）、审计日志类、
自动诊断类（DAS/顾问类产品）
3. 告警规则配置
在云监控服务里对关键指标配阈值告警，
通知渠道对接 IM/短信/电话（云方的通知体系）
4. 指标外送（重要）
云厂商普遍支持把指标转发到外部时序库
（如 CloudWatch 的导出、Prometheus 的云集成抓取）
——这是打破「数据锁在云里」的关键能力
5. 日志外送同理
RDS 类服务的数据库日志（慢查询/错误）可投递到
对象存储或日志服务，供 pgBadger 等自建工具消费第 4、5 步是云原生监控的正确打开姿势：云侧能力看事件与资源，自建侧能力看语义与长期基线，两者通过指标/日志导出衔接。
SaaS agent 的接入
以 Datadog/New Relic 为代表的接入模式高度一致：
通用接入流程（具体配置项以厂商文档为准）：
1. 主机上安装平台 agent（或容器化环境用集成方式）
2. 开启 PostgreSQL 集成：
配置监控账号的连接信息（host/port/user/password）
选择采集的指标集
3. 创建监控账号（权限模型与本章一贯要求一致）
CREATE ROLE saas_mon ... ; GRANT pg_monitor TO saas_mon;
4. 深度能力（如 Datadog Database Monitoring 类）
按厂商要求调整数据库端配置
（例如语句级分析通常依赖 pg_stat_statements 与
相关参数调整，以厂商文档为准）
5. 在 SaaS 控制台确认主机与数据库出现在资源目录，
数据入库后配置看板与告警安全三件事：监控账号用 pg_monitor 最小权限；agent 与 SaaS 的通信走 TLS（平台默认，但要核实）；SaaS 平台持有的连接凭据纳入凭据管理体系（多数平台支持密钥管理服务集成或配置文件加密）。
Percona PMM 的部署
PMM 的两个角色：
PMM Server：中心服务（Web UI + 存储 + 分析引擎）
——自托管用容器跑（官方提供 Docker/Compose/Helm 路径）
——或用 Percona 的云托管形态
PMM Client：装在被监控数据库主机
——注册数据库实例，采集指标与查询分析数据
部署主线（细节以官方文档为准）：
1. 启动 PMM Server 容器（配置数据卷与访问口令）
2. 数据库主机安装 PMM Client 并注册实例
3. 数据库侧准备监控账号（pg_monitor）与语句级扩展
（Query Analytics 依赖 pg_stat_monitor 或
pg_stat_statements，以官方版本要求为准）
4. Web UI 里查看实例总览、语句分析等看板
5. 配置告警（PMM 内置 Alertmanager 路径）PMM 与 pgwatch 的气质对比：PMM 是产品化程度高的完整套件（Server/Client/看板/查询分析一体），pgwatch 是可拼装的轻量采集器（Grafana 自由组合）。前者省事、后者灵活——两者的选择更多是团队气质问题而非能力差距问题。
告警与值班链路的接入
云/SaaS 形态的告警治理要回答「告警进哪条值班流程」：
决策树：
组织已有统一值班平台（企业 IM 集成/电话）
→ 云告警与 SaaS 告警通过 Webhook 对接进现有流程
→ 不要为云监控另建一套值班体系
没有统一值班平台
→ 小团队：直接用云方/SaaS 方的通知能力（IM/短信/电话）
→ 成长期：借 SaaS 平台的值班管理功能建立流程
多云 + 自建混合
→ 所有来源的告警 Webhook 汇聚到统一入口
（Alertmanager 或告警聚合网关）
→ 路由规则按「来源 + 严重度」统一分级无论哪条路，本章节反复出现的铁律不变：每条告警路径都要人为演练——云/SaaS 的告警链路多了厂商这一环，演练更显必要。
详细说明
云厂商能力概览（概念层）
三家主流云在 PostgreSQL 监控上的能力画像（产品名与能力以各家官方文档为准，此处只给决策视角）：
| 云 | 平台层监控 | 数据库语义层（概念） | 指标外送 |
|---|---|---|---|
| AWS（RDS/Aurora） | CloudWatch 指标体系（资源/连接/IO 等） | Performance Insights（逐语句负载分析）、Enhanced Monitoring（OS 级） | 支持（CloudWatch 集成/导出生态成熟） |
| 阿里云 RDS PostgreSQL | 云监控与控制台大盘（资源/会话/磁盘等） | 自诊断/自治服务类产品（DAS）提供 SQL 诊断与优化建议 | 支持（云监控数据导出体系） |
| GCP Cloud SQL | Cloud Monitoring 指标体系 | Query Insights（查询性能分析） | 支持（Cloud Monitoring 集成生态） |
选型视角的三个观察：语义层能力是云上监控的溢价点——Performance Insights/Query Insights 类产品把逐语句耗时分析做成了托管能力，这是自建时需要 pg_stat_statements + 存储 + 看板才能搭出来的东西；增值能力单独计费，开通前看清单与价格；三家能力不通用，多云组织的统一层只能靠指标外送 + 自建/SaaS 完成。
性能洞察类产品的方法论
不管叫 Performance Insights 还是 Query Insights，这类产品的核心是数据库负载画像（load profile）：把一段时间内数据库的负载按「等待事件 + 语句」拆解排序，回答「这段时间数据库在等什么、是谁在等」。
负载画像的使用方法（产品无关）：
1. 看 Top 等待事件：
IO 等待为主 → 缓存/I/O 问题方向（索引、内存配置、磁盘）
锁等待为主 → 并发冲突方向（长事务、热点行）
CPU 为主 → 计算过载方向（排序/哈希溢出、缺索引全扫）
2. 时间窗对比：
故障窗口 vs 正常基线，看哪个等待事件「长出来了」
3. 下钻到语句：
Top 等待事件 → 关联的具体 SQL → 单条语句的执行细节
4. 与本章慢查询篇的六步法衔接：
负载画像解决「发现与定位」，
后续复现/分析/假设/验证用常规手段这套方法论在自建体系里由 pg_stat_activity 采样 + pg_stat_statements 组合实现（pgwatch 的语句级看板、PMM 的 Query Analytics 都在做同一件事）。理解方法论后，换任何厂商的产品都能立刻上手。
Datadog：全栈统一视角下的数据库监控
Datadog 在 PostgreSQL 场景的能力分层（以官方文档为准）：
能力分层：
基础集成（Postgres Integration）
——统计视图指标、自定义查询能力，主机 agent 采集
Database Monitoring（DM，增值）
——语句级性能、执行计划、阻塞与锁分析、
查询样本与 host 指标关联
与 APM 的关联
——数据库查询耗时出现在应用链路的 span 上，
「哪个接口拖慢了数据库」与「哪条查询拖慢了接口」
在同一系统里互查评估 Datadog 的核心考点就一条：你的排障场景是否真的需要跨栈关联。纯 DBA 团队维护几十个库、应用排障归应用团队，Datadog 的溢价买不回来；微服务规模大、跨栈排障每周发生、预算充足——DM 与 APM 的联动通常能证明自己的账单。
New Relic 与其他 SaaS
New Relic 的 PostgreSQL 路线是 infrastructure agent + PostgreSQL 集成（指标采集与告警，深度能力以官方文档为准），平台强项在 APM 与全栈数据的统一查询能力。除此之外的 SaaS 选项按定位粗分：
| 产品/形态 | 定位 | 与 PostgreSQL 的关系 |
|---|---|---|
| Datadog / New Relic | 全栈统一可观测性 SaaS | 数据库是全栈的一环，深度看增值模块 |
| pganalyze | PostgreSQL 专注 SaaS | 语句级性能与索引顾问，DBA 向 |
| 各云自带监控 | 托管绑定 | 见云原生监控一节 |
| Percona PMM | 开源套件（自托管/云形态） | 数据库多引擎专业监控 |
pganalyze 这类「数据库专注型 SaaS」值得注意：规模小于 Datadog 但 PostgreSQL 语义更深，对纯 PostgreSQL 团队是高性价比选项（具体能力与定价以官方为准）。
PMM 的运维要点
选择 PMM 自托管等于选择「自己运维一套监控系统」，运维清单：
PMM Server 运维要点（概念层，操作以官方文档为准）：
1. 容量：查询分析数据的留存是主要增长点，
留存期与磁盘预算显式配置
2. 升级：跟随官方版本节奏（镜像更新路径），
升级前备份数据卷
3. 访问控制：Web UI 的账号与口令、
网络层限制（只暴露给需要的网段）、TLS
4. 高可用：单实例形态的恢复预案
（数据卷备份 + 快速重建流程）
5. 客户端版本同步：PMM Client 与 Server 版本配套升级PMM 的「开源免费」不等于「零成本」——成本从 SaaS 订阅转移到了自己的运维工时与基础设施。给 PMM 的 TCO 建模时把这些算进去（下一节成本模型的通用方法同样适用）。
成本模型：三类形态的账怎么算
监控成本从来不只是许可证价格，完整的账本：
自建开源（Prometheus/pgwatch/Zabbix）：
直接成本 ≈ 0（软件） + 基础设施（虚机/存储）
隐性成本 = 人力（搭建 + 升级 + 故障处理 + 演练）
特征：前期人力投入大，边际成本低，规模越大越划算
云原生监控：
直接成本 = 增值模块订阅 + 指标量/日志量计费（各云不同）
隐性成本 = 较低（零部署），但出云迁移成本高
特征：与数据库账单绑定，库越多线性增长
SaaS 平台：
直接成本 = 主机数 × 模块单价 + 数据量计费
隐性成本 = 人力（较低） + 数据出境的合规成本
特征：单位价值高（人力节省），基数大了账单惊人
决策公式（直觉版）：
库少团队小 + 有 DBA → 自建
库少团队小 + 无 DBA → 云原生/PMM 云形态
库多 + 全栈统一需求强 + 预算足 → SaaS
库多 + 无预算 + 有运维力 → 自建或 PMM 自托管两个常见的账单陷阱：SaaS 的「自定义指标」与「语句采样」通常单独计费——开了 DM 之后指标量翻几倍是常态，上线前用小范围试点估算；云监控的日志外送费用（投递到日志服务按量计费）——慢查询日志全量外送的成本可能超过监控模块本身，采样与过滤先行。
数据主权与合规
监控数据看似低敏感，实则不然——语句级采样里可能包含用户数据（查询参数），云监控与 SaaS 都要求把这件事过一遍合规：
合规检查清单（云/SaaS 形态通用）：
□ 数据落在哪里（区域/数据中心），留存多久
□ 语句采样的参数化程度（能否只存语句模板不存参数）
□ 谁能访问（平台侧权限模型、加密方式）
□ 出口合规（跨境传输的法规适配：个保法/GDPR 等按组织要求）
□ 删除与导出权（合同终止后数据如何处理）
□ 审计能力（平台操作日志可否导出进自己的审计体系）敏感行业的标准姿势：参数级数据不出域——云形态用区域内部署/专用版，SaaS 形态选支持参数脱敏或本地采样的产品（能力以厂商文档为准），实在不行语句级能力自建（本章自建方案全部适用）。
混合架构：自建 + 云/SaaS 的组合策略
现实中的最优解常常是混合，成熟的组合模式：
模式一：云上库用云原生 + 自建深度层
托管库的资源/事件告警 → 云监控
语义深度（语句级/对象级）→ pgwatch/PMM 远程采集
（云厂商指标外送 + 远程采集都不违反托管边界）
模式二：统一 SaaS + 自建专业层
全栈指标/APM/值班 → SaaS 平台
PostgreSQL 深度排障 → 自建看板（pgwatch sink 选
Prometheus 汇入 SaaS 可兼容的存储，或直接双轨）
模式三：多环境分治
云上环境 → 云原生监控为主
IDC/自管环境 → 自建开源为主
统一层 → 告警汇聚 + 总览看板（轻量）选择模式的判断标准就两条：告警必须单入口（值班同学面对一个系统）；深度能力的成本在自己手里（不被单一供应商绑架语义层数据）。
供应商锁定与退出策略
选云/SaaS 时就要想好「不用的那天怎么走」：
退出评估清单：
□ 指标数据可导出（格式/工具/历史深度）
□ 看板可迁移（Grafana 兼容的代价小，私有格式代价大）
□ 告警规则可重建（规则即代码的厂商友好度高）
□ 语句分析数据是否可持续自采
（退出后用 pg_stat_statements + 自建看板接住基线）
降低锁定的实操：
长期基线自己存一份（指标外送到自建时序库）
告警规则用 Terraform/配置化方式管理，不点控制台手搓
语义层自建能力保持「温热」
（哪怕主力用云监控，pgwatch 的轻量采集留着）「监控数据的所有权」是本章反复出现的主题，到这里可以给出本章的收束判断：工具可以买，语义与基线必须留一份在自己手里。
日志与审计的外送衔接
本章节日志篇（logging）搭建的日志管道与云/SaaS 监控不是竞争关系，衔接方式决定了排障体验：
日志的三种去处（可并存）：
1. 留在云侧：RDS 类服务的日志投递到云日志服务
——零部署，检索能力强，按量计费
2. 外送到自建管道：日志投递到对象存储/Kafka，
由 pgBadger/Loki 等自建工具消费
——成本可控，与慢查询篇的分析流程无缝
3. 外送到 SaaS：日志进 Datadog Logs 等
——与指标/APM 在同一平台关联
审计日志的特殊性：
合规要求的审计日志（pgaudit 类）通常有独立留存期要求
——与性能日志分开管理，别混在同一条管道里衔接的核心决策点是慢查询日志的归属：云上库的 log_min_duration_statement 配置在参数组里，日志外送到哪一层决定谁来做慢查询分析（云方工具/pgBadger/SaaS）。与本章慢查询篇的解析方案对齐，避免同一个能力在三处重复建设。
监控覆盖与 SLA 治理
工具选完只是开始，覆盖治理决定监控体系的长期有效性：
覆盖台账（每季度盘点一次）：
实例清单 × 覆盖状态：
□ 平台层监控（可用性/资源告警）——覆盖率应 100%
□ 语义层监控（pgwatch/PMM/DM）——按重要度分层
□ 语句级能力——生产核心库必须，其余按需
□ 复制拓扑视角——所有有备库的集群
□ 备份监控——备份成功/可恢复性验证（易漏项）
每个实例的「监控画像」：
env=prod cluster=orders role=primary
platform=rds monitor=cloudwatch+pgwatch
——画像清晰，覆盖率盘点才可自动化SLA 治理的另一半是对监控体系自身的 SLA：告警送达时延（实测 P99）、指标断流容忍度、监控组件的恢复时间目标。这些数字进值班手册，监控体系才能从「工具集合」升级为「有质量承诺的服务」。
评估云/SaaS 监控的 Checklist
把本章方法论收成一张可带走的评估清单（采购/立项评审时逐项打分）：
产品评估 Checklist（按权重排序）：
数据能力（40%）
□ PostgreSQL 语义深度：统计视图覆盖、语句级、执行计划
□ 新版本跟进速度：PG 大版本发布后多久支持
□ 指标粒度与采集频率选项
□ 数据导出能力（格式、工具、无额外费用）
工程能力（25%）
□ 与 APM/日志的关联深度（跨栈排障实测）
□ 告警能力：路由/静默/升级链/通知渠道
□ API 与基础设施即代码支持
商务与合规（35%）
□ 成本模型可预测性（试点账单外推）
□ 数据区域与合规认证
□ 退出条款与数据归还
□ 支持响应（SLA 级别、中文支持）打分时把「销售演示」与「POC 实测」分开记——数据库监控产品的演示环境都漂亮，POC 时带上自己的最复杂实例（表最多、并发最高、托管边界最紧的那个）才能测出真实水位。
实战示例
示例一：托管 PostgreSQL 的监控基线（云原生 + 自建组合）
环境：AWS RDS for PostgreSQL × 5 实例（生产），
团队有 2 名 DBA，无 SaaS 预算。
1. 云侧（当天完成）：
□ CloudWatch 告警：CPU/存储/连接数阈值告警
（具体指标名以 AWS 文档为准）
□ 维护窗口与事件通知对接 IM
2. 语义侧（一周内完成）：
□ pgwatch 采集器部署在自有跳板机/容器平台
□ 为 5 个 RDS 实例配置 pg_monitor 监控账号
（RDS 的角色授予方式按 AWS 文档）
□ preset：生产实例标准档，语句级指标开启
（pg_stat_statements 通过 RDS 参数组启用）
3. 告警汇聚：
□ 云告警 + Grafana（pgwatch sink）告警
统一 Webhook 进 IM 值班群
4. 验收：
□ 人为制造连接饱和触发两侧告警
□ 语句级看板能看到 Top 查询
□ 采集账号负载 < 总负载 1%这套组合的成本：一台采集器虚机 + pgwatch 免费开源 + 云侧增值模块按需；换来的是资源告警与语句级排障的完整覆盖。
示例二：Datadog 接入混合云数据库
环境：应用全容器化在云上（已用 Datadog APM），
数据库一半云托管一半 IDC 自建，团队 20 名工程师。
1. IDC 自建库接入：
□ 数据库主机装 Datadog agent（复用已有主机 agent 纳管）
□ PostgreSQL 集成配置监控账号（pg_monitor）
□ 评估 DM 模块：先开 2 个最关键的生产库试点
2. 云托管库接入：
□ 优先用云方指标 + Datadog 云集成抓取
（避免为托管库强行装 agent）
3. 统一视图：
□ 数据库总览看板：按环境/集群分组
□ APM ↔ 数据库联动验证：找一个慢接口，
从 trace 下钻到具体 SQL 耗时
4. 成本控制：
□ 试点一个月后复盘 DM 的语句采样量与账单增量
□ 按库的重要度决定 DM 的覆盖范围（不要全开）示例三：Percona PMM 自托管落地
环境：金融行业，数据不出域，20 个自建 PostgreSQL 实例，
无 SaaS 采购通道（审批周期长），有 1 名运维。
1. 部署（一天内）：
□ PMM Server：容器化部署在内网虚机，
数据卷 500GB，访问限内网
□ PMM Client：20 台数据库主机安装并注册
2. 数据库侧：
□ 监控账号 pg_monitor（走账号审批与轮转流程）
□ pg_stat_monitor 按官方要求启用（语句分析数据源）
3. 告警：
□ PMM 内置告警能力对接企业 IM 网关
□ 关键规则：实例存活/连接/复制延迟/磁盘
4. 合规收尾：
□ 语句采样的参数留存策略按合规要求配置
□ Web UI 访问纳入统一认证（若版本支持 LDAP/SAML）
□ 数据卷备份进既有备份体系
5. 演练：
□ 停 PMM Server 验证团队发现路径（meta-monitoring）
□ 人为制造慢查询验证 Query Analytics 捕获示例四：多云组织的统一监控策略
环境：AWS + 阿里云 + IDC 三地都有 PostgreSQL，
值班体系唯一（企业统一平台）。
策略：分层分治 + 单告警入口
1. 每朵云/IDC 内：
平台层监控各自用云方能力/自建 agent
2. 语义层统一：
自建 pgwatch，采集器分区部署（每环境一个），
sink 统一指向 IDC 的 PostgreSQL（TimescaleDB）
——跨云专线流量按最小 metric 集控制
3. 告警单入口：
云方告警 Webhook → 统一告警网关
Grafana 告警 → 同一网关
→ 企业值班平台
4. 数据主权：
全部指标原始数据落在 IDC 自有存储，
云侧只留实时告警所需的最小集
结果：值班一个入口、语义一套体系、
任一云的退出成本只是平台层告警重建。示例五：SaaS 账单失控的复盘
背景：某团队接入 SaaS 平台的数据库监控，
三个月后账单为预期的 4 倍。
复盘发现（逐条排查法，供同类场景自查）：
1. 语句采样未配置采样率——全量语句样本上送，
高流量库的样本量爆炸
→ 按厂商指引配置采样率与留存
2. 自定义 SQL 指标失控——三个月里随手加了几十条
高频自定义查询
→ 自定义指标清理，间隔放宽，纳入评审
3. 测试环境全量开启——测试库与生产库同策略
→ 测试环境降档，非核心库关闭深度模块
4. 历史留存选了最长档——默认最长留存
→ 按排障实际需要（通常 90 天足够）缩短
整改结果：账单回落至 1.5 倍预期水平，
剩余溢价被跨栈关联的排障收益覆盖，续约通过。
教训：SaaS 的成本治理与本章自建方案的
「preset 分层 + 间隔治理」是同一个方法论，
账单就是你的指标基数账本。注意事项
云/SaaS 的具体能力以厂商当前文档为准，本章不背书任何具体指标名与配置项。 云厂商的产品形态半年一变，接入前逐项核对官方文档是流程的一部分，不是可选动作。
托管环境的能力边界先摸清再承诺。 RDS 类服务拿不到 OS 层完整视图、扩展安装受限、部分统计函数无权限——「自建时能做到的」在托管上未必，SLA 与监控覆盖的对外承诺按托管边界写。
SaaS 语句采样的数据敏感性最容易被忽视。 查询参数可能带用户数据，合规评审要前置到采购阶段而不是出了事再补救；参数化/脱敏能力逐厂商核实。
「按量计费」的四倍账单是真的会发生。 采样率、自定义指标数量、留存期三个旋钮在上线前全部显式配置并试点验证，别用默认值直接全量铺开。
云监控的告警延迟与配额要测试。 云指标有采集粒度（分钟级常见）与告警评估延迟，用人为故障实测端到端时延——SLA 承诺的是「发现时间」，别拿控制台刷新时间当告警时延。
PMM 自托管也是一套要运维的系统。 容量、升级、备份、访问控制一样不能少，「开源免费」转移成本而不是消灭成本。
告警必须单入口，无论来源有多少个。 云告警、SaaS 告警、自建告警各自为政是多云组织的通病——Webhook 汇聚 + 统一分级是最低标准的治理。
退出策略在签约时就写清楚。 数据导出的格式与深度、看板迁移的代价、合同终止后的数据处理——这些谈判筹码只在付款前有效。
托管数据库的监控账号同样要走最小权限与轮转。 云控制台创建的账号不等于可以超配权限；pg_monitor 原则在任何形态下不变。
统一可观测性是手段不是目的。 三支柱合流的价值在排障闭环，为「架构先进」而上 SaaS 大平台、却只有一两个团队在用，是最常见的采购失误——先盘点真实排障场景再定形态。
最佳实践
- 先分类需求再选形态：资源告警、语义深度、跨栈关联三层分别决策。 三层可以来自不同形态（云原生 + 自建 + SaaS 的任意组合），不必一家通吃。
- 云托管库的正确姿势是「云侧看资源与事件，自建/远程采集看语义」。 指标与日志外送能力是云监控的必要配套，签约前确认。
- SaaS 试点先行：小范围开启深度模块，用一个月的真实账单外推全量成本。 采样率、自定义指标、留存期三个成本旋钮显式管理。
- 语句级能力的合规评审前置。 参数留存、区域、加密、访问控制四项过完法务再上线，别让监控成为合规事故源。
- 长期基线数据在自己手里存一份。 指标外送到自建时序库，供应商可换、基线不断——这是反锁定的核心动作。
- 告警规则配置化（Terraform/API），禁止控制台手搓。 规则即代码才能评审、迁移与重建，云/SaaS/自建一视同仁。
- PMM/自托管形态照搬本章自建方案的全部纪律。 meta-monitoring、容量规划、演练、账号轮转——换形态不换原则。
- 跨栈关联（metrics+logs+traces）按排障场景的真实频率付费。 每周都发生的跨域排障才值得 SaaS 溢价；偶发场景用自建方案的时间轴对齐也能解决。
- 多云环境分区采集、统一汇聚。 采集器靠近数据库（省流量）、存储与告警单点收敛（保一致），专线带宽给监控留预算。
- 每季度复盘监控成本与使用率。 看板没人看的模块、采样没人查的库、留存没人用的历史——监控体系的「死库存」与业务系统一样需要清理。
- 把本章作为整个监控工具篇的收官决策页使用。 Prometheus（云原生）、Zabbix（企业纳管）、pgwatch（PG 深度）、pgAdmin（桌面）、云/SaaS（托管与人力替代）——选型的全景对比表见本章各页，决策顺序建议：先定组织主平台，再补语义深度层，最后填托管环境的空白。
下一节
继续学习：连接管理