logo

开发者热搜

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

作者：Nicky2025.09.18 12:20浏览量：0

简介：本文深入讲解云原生环境下如何通过Prometheus采集指标、Alertmanager配置告警规则，实现CPU和内存的自动化监控与告警，助力运维人员快速定位资源瓶颈。

云原生监控入门：使用Prometheus、Alertmanager实现CPU和内存的监控告警

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

在容器化、微服务化的云原生架构中，传统监控方式面临三大挑战：动态扩缩容导致的监控目标频繁变更、海量指标带来的存储与查询压力、以及多维度告警规则的灵活配置需求。Prometheus作为CNCF（云原生计算基金会）的毕业项目，凭借其拉取式（Pull-based）数据采集模型、时序数据库存储能力和PromQL查询语言，成为云原生监控的事实标准。配合Alertmanager的告警路由、去重与通知功能，可构建完整的监控告警体系。

1.1 Prometheus的核心优势

  • 服务发现集成：支持Kubernetes、Consul、DNS等多种服务发现机制，自动适配Pod/Service的动态变化。
  • 多维度数据模型：通过<metric_name>{<label_name>=<label_value>, ...}标签体系，支持按服务、实例、环境等维度聚合分析。
  • 高效压缩算法：采用时间戳压缩和增量编码技术，单节点可存储数百万时间序列。

1.2 Alertmanager的告警处理流程

  1. 接收告警：从Prometheus接收符合触发条件的告警事件。
  2. 分组与抑制：按告警名称、标签分组，避免”告警风暴”；通过inhibit_rules抑制冗余告警（如节点宕机时抑制该节点上所有服务的告警）。
  3. 路由与接收：根据route配置将告警路由至不同通知渠道（邮件、Slack、Webhook等）。

二、Prometheus部署与CPU/内存指标采集

2.1 单机部署Prometheus（以K8s为例）

  1. # prometheus-deployment.yaml
  2. apiVersion: apps/v1
  3. kind: Deployment
  4. metadata:
  5.   name: prometheus
  6. spec:
  7.   replicas: 1
  8.   selector:
  9.     matchLabels:
  10.       app: prometheus
  11.   template:
  12.     metadata:
  13.       labels:
  14.         app: prometheus
  15.     spec:
  16.       containers:
  17.       - name: prometheus
  18.         image: prom/prometheus:v2.47.0
  19.         args:
  20.           - "--config.file=/etc/prometheus/prometheus.yml"
  21.           - "--storage.tsdb.retention.time=30d"
  22.         ports:
  23.         - containerPort: 9090
  24.         volumeMounts:
  25.         - name: config-volume
  26.           mountPath: /etc/prometheus
  27.       volumes:
  28.       - name: config-volume
  29.         configMap:
  30.           name: prometheus-config

2.2 配置Node Exporter采集主机指标

Node Exporter是Prometheus官方推荐的节点级指标采集器，需在每个K8s节点或物理机上部署：

  1. # 下载并运行Node Exporter（以Linux为例）
  2. wget https://github.com/prometheus/node_exporter/releases/download/v1.6.1/node_exporter-1.6.1.linux-amd64.tar.gz
  3. tar xvfz node_exporter-*.tar.gz
  4. cd node_exporter-*
  5. ./node_exporter

2.3 Prometheus配置文件示例

  1. # prometheus.yml
  2. global:
  3.   scrape_interval: 15s
  4.   evaluation_interval: 15s
  6. scrape_configs:
  7.   - job_name: 'node-exporter'
  8.     static_configs:
  9.       - targets: ['node-exporter:9100']  # 替换为实际节点IP
  10.     relabel_configs:
  11.       - source_labels: [__address__]
  12.         target_label: instance
  14.   - job_name: 'kubernetes-pods'
  15.     kubernetes_sd_configs:
  16.       - role: pod
  17.     relabel_configs:
  18.       - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
  19.         action: keep
  20.         regex: true
  21.       - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port]
  22.         target_label: __address__
  23.         replacement: '$1:9090'

2.4 关键指标解析

  • CPU使用率：

    1. 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

    计算非空闲状态的CPU时间占比，按实例聚合。

  • 内存使用量：

    1. node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes

    通过总内存减去可用内存得到实际使用量。

三、Alertmanager配置与告警规则设计

3.1 Alertmanager部署与配置

  1. # alertmanager-config.yaml
  2. route:
  3.   group_by: ['alertname', 'cluster']
  4.   group_wait: 30s
  5.   group_interval: 5m
  6.   repeat_interval: 1h
  7.   receiver: 'email'
  9. receivers:
  10. - name: 'email'
  11.   email_configs:
  12.   - to: 'ops@example.com'
  13.     from: 'alert@example.com'
  14.     smarthost: smtp.example.com:587
  15.     auth_username: 'user'
  16.     auth_password: 'pass'
  18. inhibit_rules:
  19. - source_match:
  20.     severity: 'critical'
  21.   target_match:
  22.     severity: 'warning'
  23.   equal: ['instance']

3.2 告警规则编写（Prometheus Rule）

  1. # prometheus-rules.yaml
  2. groups:
  3. - name: cpu-memory-alerts
  4.   rules:
  5.   - alert: HighCPUUsage
  6.     expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
  7.     for: 10m
  8.     labels:
  9.       severity: critical
  10.     annotations:
  11.       summary: "High CPU usage on {{ $labels.instance }}"
  12.       description: "CPU usage is above 90% for more than 10 minutes."
  14.   - alert: LowMemory
  15.     expr: (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 > 85
  16.     for: 5m
  17.     labels:
  18.       severity: warning
  19.     annotations:
  20.       summary: "Low memory on {{ $labels.instance }}"
  21.       description: "Memory usage exceeds 85% for 5 minutes."

3.3 告警策略优化建议

  1. 分级告警：设置warning（80%阈值）和critical（90%阈值）两级告警，避免频繁打扰。
  2. 持续时长：通过for字段要求指标持续超阈值一定时间（如10分钟）才触发告警，减少误报。
  3. 标签聚合：利用group_by按服务、集群等维度聚合告警，便于批量处理。

四、进阶实践与故障排查

4.1 指标采集异常排查

  • 检查Target状态：访问http://<prometheus-server>:9090/targets，确认Node Exporter状态为UP。
  • 验证指标数据：执行node_cpu_seconds_total{mode="user"}查询，确认有数据返回。
  • 日志分析：查看Prometheus日志kubectl logs prometheus-<pod-id>，排查采集错误。

4.2 告警未触发问题

  • 规则加载检查：确认Prometheus配置中已加载prometheus-rules.yaml（通过/rules页面查看）。
  • 时间范围验证：在Prometheus UI中执行告警表达式，手动验证当前是否满足条件。
  • Alertmanager路由：检查Alertmanager的route配置是否正确匹配告警标签。

4.3 高可用部署方案

  • Prometheus联邦：通过--web.external-url和honor_labels参数实现多Prometheus实例联邦。
  • Alertmanager集群：部署3个Alertmanager实例，通过--cluster.*参数组建Gossip集群。
  • 持久化存储：使用Thanos或Cortex实现长期指标存储与全局查询。

五、总结与最佳实践

  1. 渐进式监控：先覆盖核心业务（如数据库、API网关）的CPU/内存指标，再逐步扩展至中间件、日志等。
  2. 告警收敛：通过inhibit_rules和group_wait减少告警噪音，避免”狼来了”效应。
  3. 自动化运维：结合Argo CD等GitOps工具实现Prometheus/Alertmanager配置的版本化管理与自动部署。
  4. 可视化增强：集成Grafana创建仪表盘，直观展示资源使用趋势与告警历史。

通过本文的实践，读者可快速搭建一套云原生环境下的CPU/内存监控告警体系，为系统稳定性保驾护航。实际生产环境中，建议结合具体业务场景调整阈值与通知策略，并定期复盘告警有效性。

相关文章推荐

发表评论

最热文章

关于作者

  • 被阅读数
  • 被赞数
  • 被收藏数