云原生监控实战：Prometheus+Alertmanager实现CPU与内存告警

一、云原生监控的核心价值与工具选型

在容器化、微服务架构盛行的云原生时代，传统监控方式面临三大挑战：动态资源调度导致IP频繁变更、服务实例数量指数级增长、监控数据需要支持自动化决策。Prometheus作为CNCF（云原生计算基金会）毕业项目，凭借其拉取式数据采集、时序数据库存储和PromQL查询语言三大特性，成为云原生监控的事实标准。

Alertmanager作为Prometheus的告警处理组件，通过分组（Grouping）、抑制（Inhibition）和静默（Silencing）机制，解决了告警风暴问题。两者结合可实现从数据采集到告警通知的全流程自动化。

二、Prometheus基础架构部署

1. 核心组件安装

以Ubuntu 20.04为例，使用二进制包安装：

# 下载Prometheus
wget https://github.com/prometheus/prometheus/releases/download/v2.47.0/prometheus-2.47.0.linux-amd64.tar.gz
tar xvfz prometheus-*.tar.gz
cd prometheus-*
# 配置基础参数
cat > prometheus.yml <<EOF
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets: ['localhost:9100']
EOF
# 启动服务
./prometheus --config.file=prometheus.yml

2. Node Exporter部署

Node Exporter是Prometheus的官方主机指标采集器，支持CPU、内存、磁盘等100+指标：

# 安装Node Exporter
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar xvfz node_exporter-*.tar.gz
cd node_exporter-*
nohup ./node_exporter &

关键指标说明：

• node_cpu_seconds_total{mode="system"}：系统态CPU时间
• node_memory_MemAvailable_bytes：可用内存
• node_memory_MemTotal_bytes：总内存

三、Alertmanager告警配置详解

1. 告警规则设计原则

采用金字塔模型设计告警规则：

1. 基础设施层：主机CPU/内存阈值（如>90%）
2. 平台服务层：K8s组件健康状态
3. 应用服务层：业务指标异常

示例CPU告警规则：

# alert.rules.yml
groups:
- name: cpu-alerts
  rules:
  - alert: HighCpuUsage
    expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "High CPU usage on {{ $labels.instance }}"
      description: "CPU usage is above 90% (current value: {{ $value }}%)"

内存告警规则需考虑缓存影响：

- alert: LowMemory
  expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 85
  for: 5m
  labels:
    severity: warning

2. Alertmanager配置实践

配置文件示例：

# alertmanager.yml
global:
  resolve_timeout: 5m
route:
  group_by: ['alertname']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h
  receiver: email
receivers:
- name: email
  email_configs:
  - to: 'ops@example.com'
    from: 'alert@example.com'
    smarthost: smtp.example.com:587
    auth_username: 'user'
    auth_password: 'password'

关键配置说明：

• group_wait：首次告警等待时间
• inhibit_rules：抑制规则（如磁盘满告警抑制文件服务告警）
• route：支持多级路由（按环境/团队分类）

四、进阶实践与优化

1. 动态告警阈值调整

通过Prometheus的record规则实现动态阈值：

- record: instance:cpu_usage:ratio
  expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

结合Grafana实现可视化阈值调整：

2. 多环境告警管理

使用K8s ConfigMap管理不同环境配置：

# production-alertmanager.yml
route:
  receiver: production-team
  routes:
  - match:
      env: staging
    receiver: staging-team

3. 告警历史分析

通过promtool分析告警历史：

promtool query instant "alerts{alertstate='firing'}"

五、常见问题解决方案

1. 告警延迟问题

• 现象：告警触发比预期晚5-10分钟
• 原因：scrape_interval与for时间不匹配
• 解决：调整scrape_interval为10s，for时间为1m

2. 内存告警误报

• 现象：缓存增长触发告警
• 优化：使用node_memory_MemFree_bytes替代直接计算

3. 高基数问题

• 现象：instance标签导致指标爆炸
• 解决：使用relabel_configs过滤无关实例

六、最佳实践总结

1. 分级告警：P0（5分钟响应）、P1（30分钟响应）、P2（24小时响应）
2. 告警收敛：相同实例的同类告警合并
3. 文档化：每个告警规则需附带解决手册链接
4. 演练：每月进行告警响应演练

通过Prometheus+Alertmanager的组合，可构建满足云原生环境需求的监控体系。实际部署时建议先在小规模环境验证告警规则，再逐步扩展到生产环境。对于超大规模集群，可考虑Thanos或Cortex方案实现水平扩展。