监控告警系统搭建 - 运维技术服务中心

案例 01

Prometheus 全栈监控体系从零搭建

背景描述

某互联网公司运维团队只有 3 人，管理 200+ 台服务器和 50+ 个微服务。之前靠"用户投诉才知道挂了"，需要搭建一套覆盖基础设施、中间件、应用的全方位监控体系。

解决方案

部署 Prometheus Server 集群（2 节点 HA）+ Thanos 实现长期存储和全局视图。Node Exporter 采集主机指标，Blackbox Exporter 做 HTTP/TCP 拨测，Spring Boot 应用接入 Micrometer。

技术要点

Prometheus 高可用：2 节点采集相同 Target，避免单点（非严格 HA 但满足大部分需求）
Thanos Sidecar + Store Gateway + Query 实现多集群全局视图和 S3 长期存储（保留 2 年）
告警规则分级：P0（致命，电话）→ P1（严重，短信+钉钉）→ P2（警告，钉钉）→ P3（通知，邮件）
Grafana Dashboard 模板化：基础设施概览、JVM 详情、业务大盘

# prometheus.yml 核心配置
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alert_rules/*.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['node1:9100', 'node2:9100', ...]
  - job_name: 'spring-boot'
    metrics_path: '/actuator/prometheus'
    static_configs:
      - targets: ['app1:8080', 'app2:8080', ...]
  - job_name: 'blackbox-http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets: ['https://api.example.com/health']
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - target_label: __address__
        replacement: blackbox:9115

# 告警规则示例（alert_rules/node.yml）
groups:
  - name: node_alerts
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 5m
        labels: { severity: critical }
        annotations:
          summary: "{{ $labels.instance }} CPU 使用率 > 90%"

案例 02

Zabbix 企业级监控迁移到 Prometheus

背景描述

某传统企业已使用 Zabbix 5.0 多年，监控 500+ 台服务器和网络设备。随着 K8s 和微服务引入，Zabbix 对容器环境的监控支持不足，需逐步迁移到 Prometheus 生态，同时保留对网络设备 SNMP 的支持。

解决方案

采用双轨并行策略：网络设备（交换机、防火墙）和传统物理机保留 Zabbix，K8s 集群和微服务接入 Prometheus。通过 Grafana 统一展示两个数据源，告警统一由 Alertmanager 管理。

技术要点

SNMP Exporter + generator 生成交换机 MIB 采集配置，替代 Zabbix SNMP 采集
Grafana 同时添加 Prometheus 和 Zabbix（通过 Zabbix 插件）数据源
告警平滑迁移：先双写（Zabbix Action + Alertmanager），确认无遗漏后关闭 Zabbix 告警
历史数据保留：Zabbix 数据库保留 1 年只读，新数据全量进 Prometheus + Thanos

# SNMP Exporter 配置生成
# 1. 下载对应设备 MIB
# 2. 使用 generator 生成 snmp.yml
cd snmp_exporter/generator
make generate
# 修改 generator.yml 指定需要采集的 OID

# snmp.yml（生成的关键内容示例）
modules:
  cisco_switch:
    walk:
      - 1.3.6.1.2.1.2.2.1.2   # ifDescr（接口名称）
      - 1.3.6.1.2.1.2.2.1.10  # ifInOctets（入流量）
      - 1.3.6.1.2.1.2.2.1.16  # ifOutOctets（出流量）

# prometheus.yml 添加 SNMP Target
- job_name: 'snmp'
  static_configs:
    - targets:
      - 192.168.1.1  # 核心交换机
      - 192.168.1.2  # 汇聚交换机
  metrics_path: /snmp
  params:
    module: [cisco_switch]
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - target_label: __address__
      replacement: snmp-exporter:9116

案例 03

Prometheus 海量数据下的性能优化与存储治理

背景描述

Prometheus 运行 6 个月后，磁盘占用从 50GB 膨胀到 800GB，查询速度严重下降（Dashboard 加载超过 30s），且 OOM 频繁。监控对象从最初 200 个 Target 增长到 2000+。

解决方案

通过降低 Scrape 间隔、优化 relabel_configs 减少 label 基数、实施 Recording Rules 预聚合、引入 Thanos 实现长期存储分离。最终磁盘占用降低 65%，查询延迟 < 2s。

技术要点

Relabel 优化：drop 掉高基数 label（如 user_id、session_id），减少时间序列数
Recording Rules：将常用聚合查询（如 QPS、错误率）预计算为新指标
Scrape Interval 分级：核心服务 15s，普通服务 30s，静态资源 60s
Thanos Compactor 对历史数据做降采样（5m → 1h）

# relabel_configs 优化 - 丢弃高基数 label
scrape_configs:
  - job_name: 'app'
    metric_relabel_configs:
      # 保留关键 label，丢弃高基数 label
      - regex: 'user_id|session_id|trace_id|request_id'
        action: labeldrop

# Recording Rules 示例（rules/recording.yml）
groups:
  - name: app_recording
    interval: 30s
    rules:
      - record: job:http_requests_total:rate5m
        expr: rate(http_requests_total[5m])
      - record: job:http_errors_total:rate5m
        expr: rate(http_requests_total{status=~"5.."}[5m])
      - record: instance:node_memory_usage:percent
        expr: (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes)) * 100

# Prometheus 启动参数优化
--storage.tsdb.retention.time=30d           # 本地仅保留 30 天
--storage.tsdb.retention.size=50GB           # 本地最大 50GB
--query.max-concurrency=20                   # 限制并发查询
--query.timeout=2m                           # 查询超时 2 分钟