网站运维监控告警体系搭建：Prometheus指标采集与告警分级设计

网站运维的监控体系如果只接一个”服务存活”的告警，那故障恢复速度依然靠运气。真正可用的监控告警体系至少覆盖资源指标、业务指标、日志事件三个层面，告警规则还要按影响面分级，不能把磁盘80%和支付链路故障混在同一个通知渠道里。Prometheus加Alertmanager是社区最成熟的开源组合，适合大多数中小规模业务的网站运维场景。

Prometheus指标采集架构：Exporter与抓取配置

Prometheus通过拉取模式采集指标，被监控对象只要暴露一个/metrics接口就行。基础设施层用node_exporter采集CPU内存磁盘网络，中间件用mysql_exporter、redis_exporter，应用层直接在代码里用客户端库暴露自定义指标。抓取配置在prometheus.yml里按job分组定义，配合relabel_configs做标签归并，让同一套告警规则能按服务、环境维度区分。

# prometheus.yml 采集配置示例
scrape_configs:
  - job_name: node
    static_configs:
      - targets: ['10.0.0.11:9100']
  - job_name: app
    metrics_path: /metrics
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        target_label: app

告警规则与分级：PromQL表达式与Alertmanager收敛

告警规则写成PromQL表达式，Alertmanager负责收敛与分发。表达式要避免”一抖就报”，例如CPU使用率用5分钟均值超过90%持续10分钟，比瞬时超过阈值可靠。分级设计上，P1级故障（站点不可用、数据丢失）直接电话或企业微信@值班，P2级（延迟升高、磁盘快满）进值班群30分钟内处理，P3级（低水位）只进周报。Alertmanager的group_by按告警名称分组，抑制规则防止一条根因故障连带弹出十几个衍生告警。

# 典型告警规则：错误率突增触发
groups:
  - name: app_alerts
    rules:
      - alert: HighErrorRate
        expr: rate(http_requests_total{code=~"5.."}[5m]) > 0.05
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "错误率超过5%"
          description: "服务{{ $labels.app }} 5分钟错误率超过阈值"

监控数据与混沌工程：先让故障可控发生

告警体系搭完，必须靠故障注入验证链路：断一台节点看告警能否准时触发，拔掉网络看指标是否丢失。混沌工程的价值是提前暴露监控盲区——节点间的隐藏依赖、慢速故障、恢复抖动，这些在正常情况下看不到。日志与指标双轨并行：ELK收集应用日志与错误栈，指标负责定级，日志负责复盘，两者不能互相替代。

告警噪音是监控体系的死敌。每季度做一次规则治理，删掉从没人响应的规则，把误报率高的阈值调掉。SRE的最终目标不是把告警做多，而是让每个告警都有明确的处置动作和责任人。