凌晨三点的电话

使用者痛点：“服务器挂了使用者订单提交不了。说起来，”

我从床上弹起来SSH 连上服务器。df -h 一看，磁盘使用率已接近 100%。追查半天发现是 Nginx 的访问日志把磁盘写满了——logrotate 配置写错了日志三个月没清理。清理掉旧日志，服务恢复，其实，抬头看窗外天亮了。

这种被动告警的折磨做过后端的都懂。 出事了才知道，知道了就手忙脚乱。那次之后我把监控程序从“出事后通知”改成了“出事前预警”。不过，磁盘使用超过 80% 就告警，提前清理；CPU 持续高位就告警，提前扩容。半年了没再半夜被叫醒过，

至于第一步先，选型——为什么是 Promeus + Grafana

市面上监控方案很多，我评估过几种：

我们的服务跑在混合云上，Promeus 的 Pull 模式天然适合跨网络采集，而且社区 Exporter 非常丰富，MySQL、Redis、Nginx、Docker 都有现成的采集器。

接下来这方面，部署 Promeus + Grafana

# docker-compose.monitoring.yml
version: '3.8'
services:
promeus:
再看image，prom/promeus:v2.49.0
container_name: promeus
volumes:
- ./promeus.yml:/etc/promeus/promeus.yml
- promeus_data:/promeus
command:
- '--config.file=/etc/promeus/promeus.yml'
- '--storage.tsdb.path=/promeus'
- '--storage.tsdb.retention.time=30d' # 数据保留 30 天
- '--web.enable-lifecycle' # 支持热加载配置
再看ports，- "9090:9090"
restart: unless-stopped
grafana:
再看image。grafana/grafana:10.1.0
container_name: grafana
environment:
- GF_SECURITY_ADMIN_PASSWORD=changeme
- GF_SMTP_ENABLED=true
- GF_SMTP_HOST=smtp.example.com:587
volumes:
- grafana_data:/var/lib/grafana
- ./grafana/dashboards:/etc/grafana/provisioning/dashboards
- ./grafana/datasources:/etc/grafana/provisioning/datasources
再看ports，- "3000:3000"
restart: unless-stopped
alertmanager:
至于image，prom/alertmanager:v0.27.0
container_name: alertmanager
volumes:
- ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
从ports来看，- "9093:9093"
restart: unless-stopped
volumes:
promeus_data:
grafana_data: