监控仪表板审计

对网络运维监控基础设施的结构化评估。

评估 Grafana 仪表板、PromQL 查询效率、告警规则配置、SLA/SLO 报告准确性以及 Prometheus 数据源健康状况。此技能读取监控配置和指标数据——不创建、修改或删除仪表板、告警或数据源。

参考 references/cli-reference.md 获取按审计步骤组织的 Grafana 和 Prometheus API 命令，参考 references/query-reference.md 获取涵盖网络接口利用率、错误率、BGP 对等状态及 SNMP 衍生指标评估的 PromQL 模式。

适用场景

• 监控覆盖缺口评估 — 验证所有关键网络基础设施是否具备仪表板覆盖和活跃告警
• 仪表板质量审查 — 评估现有 Grafana 仪表板是否向运维团队提供准确、可操作的数据
• 告警疲劳调查 — 当团队报告告警过多或无关告警，掩盖真实事件时进行审计
• SLA/SLO 合规性审查 — 验证错误预算计算和可用性指标是否反映实际服务交付情况
• 迁移前监控就绪检查 — 确认监控系统能够应对基础设施变更（新设备接入、拓扑调整、平台迁移）
• 事故后复盘 — 评估监控是否检测到事故、告警触发速度如何，以及哪些盲点导致了无声故障

前置条件

• Grafana 访问权限 — 具备至少 Viewer 角色的 API Token 或服务账户（确认 grafana_url 和 Authorization: Bearer <token> 头部正常工作）
• Prometheus 访问权限 — 可通过 prometheus_url/api/v1/status/config 访问 HTTP API（默认无需认证，或已配置相应认证头）
• 定义网络范围 — 须有设备清单、子网范围和关键服务列表，用于覆盖缺口分析
• 基线文档 — 现有的 SLA/SLO 目标、预期告警阈值和运维手册需准备就绪，以便对比
• 时间同步意识 — 确保监控栈中各节点 NTP 同步；Prometheus 采样时间戳和 Grafana 时间范围选择依赖一致的时钟

操作流程

按以下六个步骤顺序执行。每一步产生的发现将输入至第 6 步的监控覆盖评分卡与优化建议中。

步骤 1：仪表板清单

枚举所有 Grafana 仪表板，建立监控覆盖面，识别覆盖盲区、过时仪表板和组织问题。

通过 Grafana API 列出所有仪表板及其元数据：

GET /api/search?type=dash-db&limit=5000

对每个仪表板记录：uid、标题、文件夹、标签、最后更新时间戳。标记超过 180 天未更新的仪表板为过时候选——这些可能引用已废弃的指标或停用的基础设施。

检查文件夹组织结构。根目录下存在 50 个以上仪表板的扁平结构表明存在组织债务。检查命名规范遵守情况——缺乏统一前缀或标签的仪表板在事故期间难以发现。

获取每个仪表板的完整 JSON 模型：

GET /api/dashboards/uid/<uid>

记录面板数量、数据源引用和模板变量。标记使用硬编码时间范围（无相对时间选择器）的仪表板，以及引用不存在数据源的面板——这些会导致空面板，降低运维人员信任度。

构建覆盖矩阵：将仪表板面板映射到基础设施清单。存在于清单中但未被任何仪表板覆盖的设备、接口或服务即为监控盲点。

步骤 2：面板与查询分析

评估所有仪表板中 PromQL 查询的效率、面板阈值配置及可视化方式的合理性。

从仪表板面板 JSON 目标中提取所有 PromQL 表达式。对每个查询进行如下评估：

Rate 函数使用 — rate() 需要至少两个采集间隔宽度的范围向量。在长期趋势展示的仪表板中，应将 irate() 替换为 rate()；irate() 仅使用最近两个数据点，仅适用于波动剧烈、短窗口显示的场景。

记录规则候选 — 在多个仪表板中重复出现的复杂查询（同一表达式出现在 3 个及以上面板中）应作为记录规则的候选。通过哈希标准化后的 PromQL 表达式识别此类模式。常见候选包括：接口利用率计算、错误率比率、聚合可用性指标。

标签基数 — 在高基数标签上聚合而无明确过滤条件的查询会产生高开销计算。标记无标签匹配器的高基数指标查询，以及使用 {__name__=~".*"} 模式的查询。

面板阈值设置 — 确保仪表板中的仪表盘和统计面板配置了阈值。展示利用率或错误率但无颜色分级阈值的面板无法实现一目了然的严重性判断。将配置的阈值与运营业务标准对比（例如：接口利用率警告阈值 70%，临界值 90%）。

可视化合理性 — 将时间序列数据用于仪表盘会丢失时间上下文。对波动剧烈的指标使用单值统计容易误导运维人员。包含 100 行以上数据且未启用排序的表格面板在事故期间不可用。

步骤 3：告警规则验证

评估告警规则配置的检测覆盖范围、阈值准确性及通知可靠性。

从 Grafana 告警 API 获取所有告警规则：

GET /api/v1/provisioning/alert-rules

对于 Prometheus 原生告警，还需查询：

GET /api/v1/rules?type=alert

对每个告警规则，评估：

阈值合理性 — 告警阈值应与实际运维影响对齐，而非采用任意百分比。在 10Gbps 链路上设置 50% 的接口利用率告警过早；而在 100Mbps WAN 链路上 95% 才触发告警则已偏晚。需结合链路容量及 Prometheus 中的历史峰值使用情况交叉验证阈值。

评估间隔 — 每 5 分钟评估一次的告警规则无法检测小于 1 分钟的中断。对于关键基础设施（WAN 链路、核心路由器），评估间隔应等于或短于 Prometheus 的抓取间隔。标记那些评估间隔超过底层指标抓取间隔的告警组。

持续时间和等待时间 — for: 0s 的告警会因瞬时波动而触发，导致告警疲劳。在关键基础设施上使用 for: 30m 意味着 30 分钟内无法收到告警通知。推荐范围：严重告警 for: 2m-5m，警告告警 for: 5m-15m。

通知渠道 — 确保所有告警规则至少配置一个活跃的通知渠道。检查渠道健康状态：Slack Webhook 返回 200，PagerDuty 密钥有效，邮件 SMTP 可达。

路由与静默策略 — 审查 Alertmanager 路由树是否存在将所有告警统一发送至单一通道的兜底路由。确认静默规则设置了过期时间。无过期时间的活跃静默会无限期掩盖实际问题。

升级机制完整性 — 严重告警应在确认超时后从 Slack/邮件升级至 PagerDuty/电话通知。仅配置 Slack 通知的严重故障告警规则缺乏足够的升级深度。

步骤 4：SLA/SLO 报告验证

确保 SLA/SLO 仪表盘和计算结果真实反映服务交付准确性。

错误预算计算 — 验证公式：

error_budget_remaining = 1 - (actual_errors / allowed_errors)

常见错误包括：使用错误的时间窗口（日历月 vs 滚动 30 天）、未将计划内维护排除在停机时间计算之外，或仅基于单一数据源计算可用性，而服务涉及多个组件。

可用性 SLI — 检查正常运行时间百分比、MTTR（平均修复时间）、MTBF（平均故障间隔）所用输入是否正确。正常运行时间应基于探针式测量（如 blackbox exporter、合成检查），而非仅依赖设备上报状态。若 MTTR 排除检测时间，则会低估实际恢复时长。

燃烧速率告警 — 多窗口燃烧速率告警可在错误预算消耗加速时提供早期预警。验证燃烧速率告警至少使用两个时间窗口（例如 1 小时和 6 小时）。单窗口告警要么触发过晚，要么过于频繁。确保严重程度与预算消耗速度匹配：1 小时内 14.4 倍燃烧速率应触发页面级严重性。

多窗口告警模式 — 确认长窗口告警（6 小时、3 天）用于趋势检测，短窗口告警（5 分钟、1 小时）用于快速响应。验证严重程度随燃烧速率增大而提升。

步骤 5：数据源健康度评估

评估 Prometheus 抓取目标状态、指标基数、保留配置及远程写入健康状况。

抓取目标状态 — 查询 targets API：

GET /api/v1/targets?state=active

检查所有抓取目标的 up 指标。up == 0 的目标表示抓取失败——需排查网络可达性、导出器健康或认证问题。scrape_duration_seconds 超过抓取间隔的目标表示超时，会导致指标缺失并可能引发误报。

基数评估 — 查询 TSDB 状态：

GET /api/v1/status/tsdb

识别系列数最多的前 10 个指标。网络环境中，大型机框设备上的每接口 SNMP 指标常引发基数爆炸。单个指标名称下活跃系列数超过 10,000 时，需调查标签优化或聚合方案。

保留与存储配置 — 确保保留周期覆盖最长的 SLA 报告窗口。15 天保留周期搭配 30 天 SLA 仪表盘会导致报告不完整。检查 WAL 大小——若 WAL 超过总 TSDB 大小的 20%，可能表明高变更率导致写放大。

远程写入健康度 — 若 Prometheus 使用远程写入（Thanos、Cortex、Mimir、VictoriaMetrics），检查远程存储延迟指标。延迟超过 5 分钟意味着长期存储落后于实时数据。标记失败样本计数器为写入失败，可能导致数据缺失。

指标命名规范 — 确保指标遵循 Prometheus 命名规范：使用 snake_case，带单位后缀（_bytes、_seconds、_total），使用基本单位。命名不一致会使仪表盘制作易出错，且跨设备比较不可靠。

步骤 6：监控覆盖度报告

将发现整理为结构化的监控覆盖评分卡，并提出优先级优化建议。

覆盖评分卡 — 对每个基础设施类别（核心路由器、分布交换机、WAN 链路、防火墙、负载均衡器）按 1–5 分评分：

1 = 无监控，2 = 仅基础上下线状态，3 = 具备利用率仪表盘，4 = 仪表盘含告警，5 = 仪表盘含告警及 SLO 跟踪。

告警质量评估 — 计算告警质量指标：告警到事件比率、平均响应时间、每条告警规则的静默频率。高噪声告警（>80% 被静默或确认但无操作）应考虑调整阈值或移除。

PromQL 优化建议 — 针对步骤 2 中发现的低效查询，提供当前表达式与优化后的版本。优先为出现在 3 个以上仪表盘中的查询创建记录规则。

阈值表

监控仪表板审计技能

严重性等级与检查条件

决策树

监控审计入口点：
├─ 仪表板完整性未知？ → 从步骤1（资产清单）开始
├─ 报告存在告警疲劳？ → 从步骤3（告警验证）开始
├─ 存在SLA争议或报告不准确？ → 从步骤4（SLA/SLO）开始
├─ 缺失指标或图表存在空白？ → 从步骤5（数据源）开始
└─ 进行整体健康检查？ → 执行完整流程步骤1–6

面板查询优化：
├─ 查询无返回数据？
│  ├─ 指标存在于TSDB中？ → 检查标签匹配器
│  └─ 指标缺失？ → 严重：导出器或采集配置异常
├─ 查询执行缓慢（>10秒）？
│  ├─ 标签基数过高？ → 添加标签匹配器或聚合
│  ├─ 对原始指标使用宽时间范围？ → 使用记录规则
│  └─ 使用正则标签匹配？ → 尽可能替换为精确匹配
└─ 查询结果不符合预期？
   ├─ 在非计数指标上使用 rate()？ → 改用适用于仪表盘的函数
   └─ 聚合时丢失标签？ → 使用 by/without 子句补充

告警阈值校准：
├─ 告警从未触发？ → 阈值过高或指标缺失
│  ├─ 指标存在且正在采集？ → 根据P95降低阈值
│  └─ 指标缺失？ → 优先修复采集目标（步骤5）
├─ 告警频繁触发？ → 阈值过低或 for 持续时间过短
│  ├─ for: 0s？ → 添加最小等待持续时间
│  └─ 阈值低于正常基线？ → 提升至 P95 + 安全裕量
└─ 告警触发但团队忽略？ → 告警疲劳
   ├─ >80%被静音？ → 移除或重新定位告警
   └─ 信噪比过低？ → 增加 for 持续时间或添加抑制规则

报告模板

# 监控仪表板审计报告

## 执行摘要
- **范围：** [Grafana 实例地址、Prometheus 端点、设备数量]
- **评估日期：** [日期]
- **仪表板总数：** [总仪表板数 / 活跃数 / 过期数]
- **告警规则总数：** [总规则数 / 触发数 / 待处理数 / 无效数]
- **覆盖评分：** [各基础设施类别平均分，1–5 分制]

## 覆盖评分卡
| 类别 | 仪表板数 | 告警数 | SLO | 评分 |
|------|----------|--------|-----|------|
| 核心路由器 | [数量] | [数量] | [是/否] | [1-5] |
| 分发层设备 | [数量] | [数量] | [是/否] | [1-5] |
| WAN 链路 | [数量] | [数量] | [是/否] | [1-5] |
| 防火墙 | [数量] | [数量] | [是/否] | [1-5] |

## 告警质量指标
| 指标 | 数值 | 目标 |
|------|------|------|
| 告警与事件比率 | [比率] | <5:1 |
| 平均响应时间 | [时长] | <15分钟 |
| 静音频率（30天） | [次数] | 趋势下降 |
| 升级覆盖度 | [%] | 关键告警需100%覆盖 |

## 按严重性分类的问题发现

### 严重
| # | 领域 | 发现问题 | 影响 | 建议措施 |
|---|------|----------|------|----------|

### 高
| # | 领域 | 发现问题 | 影响 | 建议措施 |
|---|------|----------|------|----------|

### 中 / 低
[合并显示的问题表格]

## PromQL 优化建议
| 仪表板 | 面板 | 当前查询 | 推荐方案 | 成本降低 |
|--------|------|------------|------------|------------|

## SLA/SLO 准确性审查
| 服务 | 报告可用性 | 验证可用性 | 差异 |

## 附录
- 完整仪表板清单及过期日期
- 采集目标健康状态汇总
- 指标基数排名前10的指标

故障排查

Grafana API 返回 401/403 错误 — 确认 API Token 具备 Viewer 权限。服务账户必须对包含目标仪表板的所有文件夹拥有 Viewer 角色。读取审计无需管理员权限。

Prometheus API 不可达 — 检查网络连通性及反向代理配置。若 Prometheus 部署在子路径下，请确认基础 URL 包含正确的路径前缀。

空仪表盘清单 — Grafana API 搜索返回分页结果。请增加 limit 参数值或进行分页处理。文件夹级别的权限可能导致受限令牌无法查看某些仪表盘。

PromQL 查询引用了不存在的指标 — SNMP exporter 的指标名称在不同版本间可能发生变化。当仪表盘无数据时，请检查 exporter 版本及生成器配置。

无法获取基数数据 — TSDB 状态端点需要 Prometheus 2.14+ 版本。若不可用，可使用 count 查询估算基数，但在大规模部署中此类查询开销较大。

SLA 计算结果与业务报表不一致 — 时区处理是最常见的原因。Prometheus 存储的时间戳为 UTC 格式。请确保所有 SLA 仪表盘均使用明确的 UTC 时间范围，或统一使用一个时区变量。

Grafana 与 Prometheus 中均存在告警规则 — Grafana 统一告警（Unified Alerting）与 Prometheus 原生告警共存。需同时审计两个来源，避免重复或冲突的告警覆盖。应明确记录每类告警的权威系统。