Grafana 最佳实践
Grafana 的质量取决于数据源、查询、Dashboard、权限和发布流程是否形成闭环。以下规范用于把个人临时看板发展为团队可维护的生产能力。
1. Dashboard 设计规范
- 每个 Dashboard 写明受众、负责人和故障处置目标。
- 首屏只放关键健康信号，详细维度通过链接和变量下钻。
- 面板标题包含对象、指标、统计方式和单位，避免含糊缩写。
- 颜色、单位、阈值和时间窗口在同一领域保持一致。
- Dashboard JSON、Folder、UID 和数据源 UID 进入 Git，变更经评审发布。
2. Metric 展示规范
展示前确认指标类型与单位：Counter 用速率或增量，Gauge 展示当前值和趋势，Histogram 使用适当分位数或 SLO 桶。比率表达式的分子、分母标签维度必须对齐。高成本查询优先改为 Prometheus Recording Rule。
3. 权限设计规范
使用 SSO/LDAP 群组映射 Team，通过 Folder 分配 Viewer、Editor、Admin；平台管理员数量保持最少。数据源、通知渠道、插件和全局配置使用更严格的权限与审计。对敏感环境在数据源和网络层实施隔离，不依赖 Grafana UI 权限。
4. 多环境管理
生产、预发、开发使用清楚的数据源名称和 UID，变量默认值不要指向生产全量数据。统一 cluster、environment、namespace、service 标签，避免同一 Dashboard 为不同环境维护多套分支查询。
5. 企业生产实践
| 领域 | 最低要求 |
|---|---|
| 部署 | 固定版本、HTTPS、SSO、持久化、外部数据库与备份 |
| 数据源 | 最小权限、Secret 管理、网络限制、变更记录与健康检查 |
| Dashboard | Provisioning/Terraform、代码评审、UID 稳定、可回滚发布 |
| 运维 | 监控 Grafana、数据库、数据源、插件与查询成本，定期恢复演练 |
| 安全 | 禁用匿名/注册、审计权限与密钥、控制插件与管理 API |
6. 告警与运维经验
Grafana Alerting 适合多数据源组合告警和统一通知视图；Prometheus 原生基础设施告警通常由 Prometheus Rule 加 Alertmanager 承担。对同一用户影响只能指定一个生产通知责任方，避免重复告警。每条关键告警应有责任团队、严重度、运行手册、测试通知与恢复通知演练。
定期清理无人负责的 Dashboard、过期变量、失效数据源和未使用插件。监控系统本身故障时，Dashboard 和告警可能同时失效，因此需要独立的外部健康检查与值班演练。