指标与可视化：容量、录制规则与面板发布

维护Prometheus 指标与 Grafana 面板前先保存指标类型/单位、抓取窗口与数据源 UID，恢复后以原始序列、rate 聚合、空数据和面板单位验收。具体配置见配套示例。

核对日期2026-10-17；适用范围：机制按核对时Prometheus 3.x官方文档的稳定共同子集说明；示例另固定Prometheus 2.55与Grafana OSS 11.6教学配置族，归档族不是生产安装建议。新版新增或实验功能未默认启用，实际升级仍需独立兼容与安全评估。示例未执行；真实环境仍需验证产品配置、权限、连通与恢复结果。先读起点理解前置，再按章节完成推演。

采集容量与留存

指标采集容量由活跃序列、抓取间隔、保留时间与查询并发共同决定。把15秒改为1秒增加采样量，却不保证发现一秒内所有事件；在抓取间隔间发生又消失的Gauge尖峰仍可能遗漏。先制定可接受延迟与资源预算，再设置间隔和保留策略。高基数失控时定位新增label维度，修正源头，不直接删除整个TSDB以掩盖问题。

录制规则和统计口径

指标录制规则将昂贵且稳定的表达式周期性保存为新序列，适合共享QPS或错误比率；它不自动回填规则启用前历史。命名应带业务含义和窗口，修改聚合维度前通知面板与告警消费者。分子与分母用同一过滤条件和窗口，整体错误率应先求错误总数与请求总数之比，不是平均各实例错误率，否则低流量实例被过度加权。

面板版本与权限

指标面板发布先在副本检查数据源UID、变量、单位和空数据，再记录JSON版本。provisioning提供可追溯文件来源，allowUiUpdates=false防止误以为UI保存会更新仓库文件；disableDeletion=true也意味着移除配置文件可能保留数据库面板。Viewer、Editor、Admin职责不同，面板可见性不能替代数据源后端授权。导出JSON前检查URL、账号标识与注释，不公开秘密。

本篇练习与参考解答

练习：平均每实例错误率能代表全站错误率吗？

参考解答

不能。分母流量不同会引入权重错误，应先汇总相同窗口的失败请求与全部请求，再相除。

核对资料与相邻阅读

• Prometheus 3.x当前规则文档核对

• Grafana provisioning核对

• PromQL函数2.55

• Grafana数据源

• 指标类型官方教程

继续阅读机制、完整实践、运维、诊断与复习。

监控编排的角色、挂载与采集范围

为什么监控 Compose 已列齐服务仍不能证明采集、告警和数据持久化完整？ 监控系统要分别画出采集、查询和告警链路：应用/Exporter 提供指标，Prometheus 抓取并保存，Grafana 查询，规则与 Alertmanager 再把告警路由到通知接收器。旧 Compose 虽同时列出 Prometheus、Alertmanager、Grafana、node-exporter、cAdvisor 和钉钉 Webhook，但 prometheus.yaml 只有文件名占位，告警规则、接收器配置与模板也未完整给出；容器清单不能证明链路闭合。依次核对 scrape target、规则文件路径、告警接收端和通知身份，不能把导入 dashboard 的数字 ID 当成采集配置。

采集范围必须从实际挂载和命名空间判断。node-exporter 在容器中暴露一个端口，并不自动证明采到了目标宿主的全部指标；cAdvisor 旧例把宿主根目录、/sys 与运行时目录挂入容器，其路径依赖真实 daemon 数据根且扩大读取范围。先声明要观察宿主、容器还是应用，再核对目标产品要求的挂载/权限；node-exporter 官方指南解释了宿主指标角色。不能用另一台机器的 /data/docker_containers 路径填补该前置。

持久化与标签也各有责任：Grafana 的 /var/lib/grafana 保存面板等应用状态，不保存 Prometheus 时序数据；只挂 prometheus.yml 与 rules 不能证明 TSDB 被持久化。MySQL Exporter 需要数据库地址、受控采集身份和网络，旧 DATA_SOURCE_NAME 含 root 示例且未锁定版本，不能直接复用。跨 node/MySQL Exporter 的 instance 常含不同端口，面板联接前需明确共同主机标识，不能把数据库服务地址同时当作 Prometheus 数据源地址。恢复计划要覆盖采集配置、规则、面板与指标数据各自的位置，实际导入/查询和通知仍需另行验证。Prometheus 存储是数据边界核对入口。