监控告警

PromQL（Prometheus Query Language）是 Prometheus 监控系统的查询语言，也是整个云原生监控体系的核心。无论是构建 Grafana 仪表盘、编写告警规则，还是进行故障排查时的临时查询，都离不开 PromQL。我将从数据模型出发，逐步深入到聚合操作、常用函数和实战查询，最后覆盖子查询等高级技巧。 参考来源：Prometheus 官方文档 — Querying basics 一、PromQL 数据模型 PromQL 有四种基本数据类型，理解它们是写对查询的前提： 类型 说明 示例 即时向量（Instant Vector） 一组时间序列在当前时刻的采样值 node_cpu_seconds_total 范围向量（Range Vector） 一组时间序列在过去一段时间内的所有采样值 node_cpu_seconds_total[5m] 标量（Scalar） 一个简单的数值 3.14、1024 字符串（String） 字符串值（较少使用） "hello" 最常用的两种： 即时向量：仪表盘和告警中最常见，返回"当前这一刻"各序列的值。 范围向量：用于 rate()、increase() 等函数计算，必须带时间窗口 [...]。 # 即时向量：返回当前所有序列 up # 范围向量：返回过去5分钟内的所有采样点 up[5m] # 标量 1 - 0.3 二、基础查询 2.1 Metric 选择与标签过滤 通过标签选择器可以精确过滤目标序列： # 选择名为 node_cpu_seconds_total 的所有序列 node_cpu_seconds_total # 按 mode 标签过滤 node_cpu_seconds_total{mode="idle"} # 多标签组合（AND 关系） node_cpu_seconds_total{instance="node-1:9100", mode="idle"} # 标签正则匹配 node_cpu_seconds_total{instance=~"node-[0-9]+:9100"} # 标签反向匹配（排除某些值） node_cpu_seconds_total{mode!...

在 Prometheus 生态中，Prometheus 负责根据告警规则产生告警，而 Alertmanager 负责告警的后续全生命周期管理：分组、路由、抑制、去重和通知发送。一个配置不当的 Alertmanager 会让值班人员在凌晨被海量重复告警淹没，而精心设计的路由与抑制策略能确保"正确的人、在正确的时间、收到正确的告警"。 参考来源：Prometheus 官方文档 — Alertmanager 一、Alertmanager 架构 Alertmanager 的处理流水线分为五个阶段： Prometheus 告警规则触发 │ ▼ ┌───────────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ 接收 Receive │ ──→ │ 分组 Group │ ──→ │ 路由 Route │ ──→ │ 抑制 Inhibit│ ──→ │ 去重 Dedup │ └───────────────┘ └───────────┘ └───────────┘ └───────────┘ └─────┬─────┘ │ ▼ ┌───────────────┐ │ 发送 Notify │ │ 邮件/微信/钉钉 │ └───────────────┘ 阶段 作用 关键配置 接收 接收来自 Prometheus 的告警 receivers 分组 将相同特征的告警合并为一批 group_by 路由 根据标签匹配决定告警去向 route、matchers 抑制 当某告警触发时，静默相关低优先级告警 inhibit_rules 去重 多个 Alertmanager 实例间的告警去重 HA 模式 + Gossip 发送 通过配置的渠道发送通知 webhook / email / 等 二、路由树设计 2....

方案架构 Exporter → Prometheus（存储） → Grafana（可视化） ↓ Alertmanager（告警分发） Docker Compose 部署 version: '3.8' services: prometheus: image: prom/prometheus:v2.52.0 ports: ["9090:9090"] volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - ./rules:/etc/prometheus/rules - prom_data:/prometheus command: - '--storage.tsdb.retention.time=30d' restart: unless-stopped grafana: image: grafana/grafana:10.4.2 ports: ["3000:3000"] volumes: [grafana_data:/var/lib/grafana] restart: unless-stopped alertmanager: image: prom/alertmanager:v0.27.0 ports: ["9093:9093"] volumes: [./alertmanager.yml:/etc/alertmanager/config.yml] restart: unless-stopped node-exporter: image: prom/node-exporter:v1.8.1 ports: ["9100:9100"] restart: unless-stopped volumes: prom_data: grafana_data: 核心配置 # prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s rule_files: - "rules/*.yml" alerting: alertmanagers: - static_configs: - targets: ['alertmanager:9093'] scrape_configs: - job_name: 'node' static_configs: - targets: ['node-exporter:9100'] 常用 PromQL # CPU 使用率 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) # 内存使用率 (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes * 100 # 磁盘使用率 (node_filesystem_size_bytes - node_filesystem_avail_bytes) / node_filesystem_size_bytes * 100 告警规则示例 groups: - name: host-alerts rules: - alert: HighCPU expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80 for: 5m labels: severity: warning annotations: summary: "CPU 使用率过高 ({{ $labels....

概述 在监控系统领域，Zabbix 和 Prometheus 是两座大山。Zabbix 从传统运维时代走来，在物理机/虚拟机环境中叱咤风云近二十五年；Prometheus 则在云原生时代崛起，成为 Kubernetes 生态的事实标准。很多团队在做监控选型时都会面临一个问题：到底该选 Zabbix 还是 Prometheus？ 答案不是非此即彼。很多成熟团队在实际生产中同时运行两套系统——Zabbix 负责基础设施层（网络、硬件、操作系统），Prometheus 负责应用层和云原生层。从架构、数据模型、告警、生态、适用场景等维度全面对比两者，帮你做出合理的选型决策。 参考来源：Zabbix 官方文档、Prometheus 官方文档 一、架构对比 1.1 Zabbix 架构 Zabbix 采用经典的 C/S 架构，核心组件包括 Server、Database、Web Frontend 和 Agent。 ┌──────────────────────────────────────────────────────────┐ │ Zabbix 架构 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Agent │ │ SNMP │ │ JMX │ ← 被监控端 │ │ │ (主动/被动)│ │ 设备 │ │ Java │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ └──────────────┼──────────────┘ │ │ ▼ │ │ ┌─────────────┐ │ │ │ Zabbix Server│ ← 采集引擎 + 告警引擎 │ │ │ (C 语言) │ │ │ └──────┬──────┘ │ │ │ │ │ ▼ │ │ ┌─────────────┐ │ │ │ Database │ ← MySQL/PostgreSQL │ │ │ (关系型) │ │ │ └──────┬──────┘ │ │ │ │ │ ▼ │ │ ┌─────────────┐ │ │ │ Web Frontend│ ← PHP 前端 │ │ │ (Dashboard) │ │ │ └─────────────┘ │ │ │ │ ┌──────────────┐ │ │ │ Zabbix Proxy │ ← 分布式采集代理（可选） │ │ │ (区域汇聚) │ │ │ └──────────────┘ │ └──────────────────────────────────────────────────────────┘ Zabbix 架构特点：...