Grafana告警规则实战：从CPU到SSL证书的全面监控方案

1. Grafana告警规则入门从零搭建监控体系第一次接触Grafana告警功能时我被它强大的可视化能力震撼了。但真正让我惊艳的是它不仅能展示漂亮的数据图表还能在系统出现问题时主动打电话通知你。想象一下凌晨三点服务器CPU飙到95%而你正在熟睡这时Grafana的告警短信把你叫醒——虽然这听起来不太美好但总比早上发现服务挂了强。Grafana的告警规则本质上是一组如果...就...的条件判断。比如如果CPU使用率超过90%超过5分钟就发邮件给运维团队。这套机制的核心在于数据源Prometheus、InfluxDB等时序数据库规则引擎基于PromQL或对应数据源的查询语言通知渠道邮件、Slack、Webhook等我建议新手从CPU监控开始练手因为这个指标最直观。在Grafana 8.0版本中告警配置入口藏在Alert菜单下。点击New alert rule后你会看到一个类似这样的界面100 - (avg by (instance,job)(irate(node_cpu_seconds_total{modeidle}[5m])) * 100) 90这条PromQL的意思是计算所有实例5分钟内非空闲CPU时间的百分比当平均值超过90%时触发告警。注意avg by (instance,job)这部分它确保我们能知道具体是哪台机器出了问题。2. 服务器基础指标监控实战2.1 CPU监控的进阶技巧很多人以为CPU监控就是简单设个阈值其实这里面有不少门道。去年我们有个服务频繁告警但登录服务器后发现CPU使用率明明只有60%。后来发现是PromQL写得太粗糙# 错误示范忽略多核因素 100 - (avg(irate(node_cpu_seconds_total{modeidle}[5m])) * 100) 80正确的做法应该考虑多核情况并区分不同工作模式。这是我优化后的方案# 按实例和任务分组计算 100 - (avg by (instance,job)(irate(node_cpu_seconds_total{modeidle}[5m])) * 100) 90 # 单独监控系统态CPUsy avg by (instance)(irate(node_cpu_seconds_total{modesystem}[5m])) * 100 30 # 监控CPU负载考虑核心数 avg by (instance)(node_load5 / on(instance) count by (instance)(node_cpu_seconds_total{modeidle})) 1.52.2 内存监控的隐藏陷阱内存告警最容易出现狼来了效应。早期我们直接用(node_memory_MemTotal_bytes - node_memory_MemFree_bytes) / node_memory_MemTotal_bytes 0.9这个公式结果频繁误报。后来发现Linux会主动利用空闲内存做缓存正确的姿势是# 可用内存占比含buffer/cache (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100 90 # 监控OOM风险当可用内存低于1GB时 node_memory_MemAvailable_bytes 1073741824对于Java应用还需要特别监控堆外内存# 监控JVM堆外内存需配合jmx_exporter sum(jvm_memory_bytes_used{areanonheap}) by (instance) / sum(jvm_memory_bytes_max{areanonheap}) by (instance) * 100 853. 磁盘与网络监控的实用方案3.1 磁盘空间预测性告警等到磁盘满了再告警就太晚了。我习惯设置三级预警# 紧急告警剩余空间不足5% 100 - (node_filesystem_avail_bytes{fstype~ext4|xfs} / node_filesystem_size_bytes{fstype~ext4|xfs} * 100) 95 # 重要告警剩余空间不足10% ... 90 # 提醒告警剩余空间不足20%且日增长超过5GB 100 - (node_filesystem_avail_bytes{fstype~ext4|xfs} / node_filesystem_size_bytes{fstype~ext4|xfs} * 100) 80 and predict_linear(node_filesystem_avail_bytes{fstype~ext4|xfs}[24h], 24*3600) 0更高级的玩法是监控inode使用率这个经常被忽略(node_filesystem_files_free{fstype~ext4|xfs} / node_filesystem_files{fstype~ext4|xfs} * 100) 103.2 网络流量异常检测单纯的带宽阈值监控太基础了。我们团队现在使用动态基线告警# 突发流量检测超过历史平均值的3倍标准差 ( rate(node_network_receive_bytes_total{device!~lo|docker.*}[5m]) avg_over_time(node_network_receive_bytes_total{device!~lo|docker.*}[7d]) 3 * stddev_over_time(node_network_receive_bytes_total{device!~lo|docker.*}[7d]) )对于云服务器特别要监控丢包率# 丢包率超过1% sum(rate(node_network_receive_drop_total[5m])) by (instance) / sum(rate(node_network_receive_bytes_total[5m])) by (instance) * 100 14. SSL证书与业务级监控4.1 SSL证书过期监控证书过期引发的故障太常见了。Grafana结合blackbox_exporter可以完美监控# 证书剩余有效期小于15天 probe_ssl_earliest_cert_expiry{jobblackbox} - time() 86400 * 15 # 多级提醒策略 probe_ssl_earliest_cert_expiry{jobblackbox} - time() 86400 * 30 # 30天提醒 probe_ssl_earliest_cert_expiry{jobblackbox} - time() 86400 * 7 # 7天警告建议在告警信息中直接带上证书详情{{ printf %.2f ($value / 86400) }}天后证书过期({{ $labels.instance }}) 域名{{ with query probe_ssl_earliest_cert_expiry{instance{{ $labels.instance }}} }}{{ . | first | label probe_ssl_issuer }}{{ end }}4.2 业务接口健康检查基础监控之外业务接口监控更重要# HTTP状态码非200 probe_http_status_code{jobblackbox} ! 200 # 响应时间超过1秒 probe_http_duration_seconds{phasetotal} 1 # 证书链不完整 probe_ssl_verified ! 1对于关键API可以设置成功率告警# 5分钟内成功率低于99.9% sum(rate(http_requests_total{status~2..}[5m])) by (endpoint) / sum(rate(http_requests_total[5m])) by (endpoint) * 100 99.95. 告警优化与实战经验5.1 告警分级与抑制告警风暴比没有告警更可怕。我们的分级策略是P0立即处理影响核心业务的基础设施故障P12小时内处理非核心业务异常P224小时内处理潜在风险提示在Grafana中可以通过标签实现# alertmanager.yml配置示例 route: group_by: [alertname] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - match: severity: critical receiver: pagerduty - match: severity: warning receiver: slack5.2 告警模板的人性化设计好的告警信息应该包含问题描述什么坏了影响范围影响多大修复建议怎么处理相关文档知识库链接示例模板[{{ .Status | toUpper }}] {{ .CommonLabels.alertname }} 故障实例: {{ .CommonLabels.instance }} 当前值: {{ printf %.2f .Value }}{{ .CommonLabels.unit }} 首次发生: {{ .StartsAt.Format 2006-01-02 15:04:05 }} 处理建议: {{ index .Annotations summary }} 详细文档: {{ index .Annotations runbook_url }}6. Windows服务器监控特别指南Windows监控有些特殊点需要注意# CPU使用率注意mode标签不同 100 - (avg by (instance)(rate(windows_cpu_time_total{modeidle}[2m])) * 100) 90 # 内存监控包含分页文件 (1 - (windows_os_physical_memory_free_bytes / windows_os_physical_memory_total_bytes)) * 100 90 # 磁盘队列长度监控预测性能瓶颈 avg by (instance)(windows_logical_disk_avg_disk_queue_length) 2对于IIS服务器建议添加这些监控项# 请求排队数 windows_iis_requests_queued 100 # 工作进程回收 changes(windows_iis_worker_process_restart_count[1h]) 0 # 应用程序池状态 windows_iis_app_pool_state ! 17. 告警规则维护建议维护告警规则就像修剪盆栽需要定期打理。我们团队的做法是每月审查所有告警规则的有效性对每个告警记录故障原因和处理方法删除三个月内从未触发的规则合并相似的告警规则一个实用的维护检查清单- [ ] 所有规则都有明确的负责人 - [ ] 每个告警都有对应的处理手册 - [ ] 没有重复的告警条件 - [ ] 告警阈值符合当前业务需求 - [ ] 通知渠道保持最新