从监控到告警：Prometheus+Grafana+Alertmanager+告警通知服务全链路落地实践

一、引言

1.1 监控告警的必要性

在现代分布式系统和微服务架构中，服务数量众多、依赖复杂，任何一个环节的异常都可能影响整体业务的可用性。监控与告警系统的核心价值体现在：

• 业务连续性保障：及时发现服务异常，减少故障影响时间，提升系统可用性。
• 故障快速定位与响应：通过自动化告警和丰富的监控指标，第一时间定位问题根因，缩短MTTR（平均修复时间）。
• 自动化运维与降本增效：自动化监控和告警减少人工巡检，提升运维效率，降低人力成本。

对比：传统 vs. 现代监控告警

方式	优点	缺点	适用场景
人工巡检	简单、无门槛	延迟高、易遗漏、不可扩展	小型、低频变更系统
日志轮询	可自动化、实现简单	误报多、粒度粗、无实时性	早期单体应用
SNMP/Nagios	适合基础设施、网络设备监控	配置繁琐、扩展性差	传统IT运维
Prometheus	云原生、自动发现、指标丰富	需服务端暴露接口、学习曲线	微服务、云原生

1.2 监控告警的基本原理

1.2.1 指标采集与存储

监控系统通过采集各服务暴露的指标（如CPU、内存、QPS、错误率等），并将其存储在时序数据库中。以 Prometheus 为例，服务需暴露 /metrics HTTP 接口，Prometheus 定期拉取数据。

1.2.2 告警规则与触发机制

监控系统根据预设的规则（如“CPU使用率>80% 持续5分钟”），实时评估采集到的指标，若满足条件则触发告警。

1.2.3 多渠道通知与闭环

告警触发后，系统可通过邮件、短信、IM机器人等多种渠道通知相关责任人，实现自动化闭环。

---

二、技术选型与架构设计

2.1 为什么选择 Prometheus 及其生态

2.1.1 Prometheus 优势分析

Prometheus 是云原生时代的事实标准监控系统，具备如下优势：

• 拉模式采集：服务端暴露 /metrics，Prometheus 定期拉取，天然适配动态扩缩容。
• 多维度指标：支持标签（Label）体系，灵活聚合、筛选。
• 强大的查询语言 PromQL：可自定义复杂的聚合、计算、告警规则。
• 生态丰富：与 Grafana、Alertmanager、各种 Exporter 无缝集成。

2.1.2 Grafana 可视化能力

Grafana 是业界最流行的可视化平台，支持多数据源（Prometheus、Elasticsearch等），可自定义仪表盘、告警面板，极大提升监控可观测性。

2.1.3 Alertmanager 灵活告警

Alertmanager 支持多种告警路由、分组、抑制、静默等高级特性，并可通过 Webhook 与自定义服务（如本项目的 base 服务）集成，实现多渠道通知。

2.1.4 对比：主流监控告警方案

方案	优点	缺点	适用场景
Zabbix	适合基础设施、图形丰富	扩展性差、云原生支持弱	传统IT运维
Prometheus+Grafana	云原生、自动发现、灵活告警	需服务端配合、学习曲线	微服务、K8s
云厂商监控（如阿里云云监控）	免运维、集成度高	依赖厂商、定制性弱，收费	公有云

2.2 系统整体架构图与组件说明

2.2.1 架构图

2.2.2 组件说明

• Prometheus：定期拉取各服务 /metrics，存储时序数据，评估告警规则。
• Grafana：连接 Prometheus，展示可视化大盘。
• Alertmanager：接收 Prometheus 告警，路由、分组、抑制，并通过 Webhook 通知 base 服务。
• base 服务：实现邮件、短信、钉钉、企业微信等多渠道通知，作为告警通知的统一出口。

2.2.3 项目配置举例

以 docker-compose.yml 为例，定义了 Prometheus、Grafana、Alertmanager、base 服务的容器编排：

services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./build/prometheus/server/prometheus.yml:/etc/prometheus/prometheus.yml
      - ./build/prometheus/server/rules.yml:/etc/prometheus/rules.yml
      - ./data/prometheus/data:/prometheus
    ports:
      - "8892:9090"
    networks:
      - chatgpt-wechat_network

  grafana:
    image: grafana/grafana:latest
    ports:
      - "8891:3000"
    networks:
      - chatgpt-wechat_network

  alertmanager:
    image: prom/alertmanager:latest
    volumes:
      - ./build/alertmanager/alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "8896:9093"
    networks:
      - chatgpt-wechat_network

  base:
    build: ./base
    ports:
      - "8897:8897"
    networks:
      - chatgpt-wechat_network

---

三、Prometheus 与 Grafana 配置实践

3.1 被监控服务如何暴露采集数据接口

3.1.1 /metrics 接口规范与实现方式

Prometheus 采用“拉模式”采集监控数据。每个被监控服务需通过 HTTP 暴露 /metrics 接口，返回 Prometheus 格式的文本数据。例如：

# HELP go_gc_duration_seconds A summary of the GC invocation durations.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0.000023
go_gc_duration_seconds{quantile="0.25"} 0.000031
...

每一行代表一个指标（Metric），可带有多维标签（Label），便于后续聚合和筛选。

3.1.2 go-zero 框架的 /metrics 实现

在本项目中，所有被监控服务（如 base、knowledge、wellness 等）均基于 go-zero 框架开发。go-zero 内置了 Prometheus 监控能力，开发者无需手动实现 /metrics，只需在服务启动时开启监控配置即可。

go-zero 的原理简述：

• go-zero 在服务启动时自动注册 /metrics 路由。
• 内部集成了 Prometheus 官方的 go client（promhttp），自动采集 Go 运行时指标（如 GC、内存、协程数等）。
• 支持自定义业务指标埋点（如 QPS、错误率等）。

项目代码举例：

假设 base 服务的 main.go 片段如下（伪代码）：

import (
    "github.com/zeromicro/go-zero/rest"
    "github.com/zeromicro/go-zero/rest/httpx"
)

func main() {
   
   
    server := rest.MustNewServer(config.RestConf)
    defer server.Stop()

    server.Start()
}

配置文件示例：

# base/etc/base.yaml
Name: base
Host: 0.0.0.0
Port: 8897
DevServer:
  Enabled: true
  Port: 8894
  MetricsPath: /metrics
  EnableMetrics: true

这样，Prometheus 就可以通过 http://base:8897/metrics 采集到 base 服务的运行时和业务指标。

3.1.3 采集指标的设计建议

• 运行时指标：如 go_gc_duration_seconds、go_memstats_alloc_bytes、go_goroutines 等，自动采集。
• 业务指标：如接口 QPS、错误率、延迟分布等。go-zero 支持自定义埋点，可通过 prometheus client 库注册自定义指标。
• 标签设计：合理使用 label（如 job、app、env、instance），便于多维度聚合和筛选。

---

3.2 Prometheus 配置详解

3.2.1 采集目标配置（scrape_configs）

Prometheus 通过 scrape_configs 配置采集目标。以项目中 build/prometheus/server/prometheus.yml 为例：

scrape_configs:
  - job_name: 'base'
    metrics_path: '/metrics'
    static_configs:
      - targets: [ 'base:8897' ]
        labels:
          job: base
          app: base
          env: pro

• job_name：采集任务名，便于分组和查询。
• metrics_path：采集路径，通常为 /metrics。
• targets：目标服务地址（可为容器名:端口）。
• labels：为采集到的所有指标自动打标签，便于后续聚合。

项目完整配置片段：

scrape_configs:
  - job_name: 'knowledge'
    metrics_path: '/metrics'
    static_configs:
      - targets: [ 'knowledge:8894' ]
        labels:
          job: knowledge
          app: knowledge
          env: pro
  # ... 其他服务同理

3.2.2 告警规则配置（rule_files）

Prometheus 支持自定义告警规则，规则文件通过 rule_files 引入。例如：

rule_files:
  - "rules.yml"

rules.yml 示例（项目中的 build/prometheus/server/rules.yml）：

groups:
  - name: example
    rules:
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "服务 {
   
   { $labels.job }} 已停止"
          description: "服务 {
   
   { $labels.job }} 在 {
   
   { $labels.instance }} 已停止超过 1 分钟"

• expr：PromQL 表达式，up == 0 表示服务不可达。
• for：持续时间，避免瞬时抖动误报。
• labels/annotations：自定义标签和告警描述。

3.2.3 数据持久化与性能优化

• --storage.tsdb.retention.time=15d：数据保留15天。
• --storage.tsdb.retention.size=10GB：最大占用空间10GB。
• 建议将数据目录挂载到独立磁盘，提升读写性能。

docker-compose.yml 配置片段：

volumes:
  - ./data/prometheus/data:/prometheus
command:
  - '--storage.tsdb.retention.time=15d'
  - '--storage.tsdb.retention.size=10GB'

---

3.3 Grafana 配置与仪表盘搭建

3.3.1 数据源接入 Prometheus

Grafana 通过 Web UI 添加 Prometheus 数据源，配置 Prometheus 服务地址（如 http://prometheus:9090）。

3.3.2 常用监控大盘模板

• 系统资源监控（CPU、内存、磁盘、网络）
• 服务健康状态（up、QPS、错误率）
• 告警面板（当前活跃告警、历史告警趋势）

3.3.3 自定义告警面板

Grafana 支持基于 PromQL 查询自定义图表和告警。例如：

sum(rate(http_requests_total{job="base"}[5m]))

可用于展示 base 服务的 QPS。

---

3.4 流程时序图