技术教程

服务器监控实战：从0到1搭建企业级监控系统

监控不是"有了问题再查"，而是"问题发生前就发现"。

一、为什么需要监控系统？

1.1 真实场景

凌晨3点，服务器宕机了

没有监控：

• 用户投诉才发现
• 排查花了2小时
• 损失无法估算

有监控：

• 1分钟内告警
• 自动重启服务
• 故障自愈

1.2 监控的价值

指标 | 无监控 | 有监控
---|---|---
故障发现 | 被动等待 | 主动感知
定位时间 | 30分钟+ | 5分钟
MTTR | 2小时 | 20分钟

二、监控体系架构

2.1 四层监控

┌─────────────────────────────────────┐
│ 应用层监控 │
│ 接口响应 / 错误率 / 业务指标 │
├─────────────────────────────────────┤
│ 中间件监控 │
│ MySQL / Redis / Nginx / MQ │
├─────────────────────────────────────┤
│ 系统层监控 │
│ CPU / 内存 / 磁盘 / 网络 │
├─────────────────────────────────────┤
│ 基础设施监控 │
│ 机房 / 服务器 / 网络设备 │
└─────────────────────────────────────┘

2.2 核心指标

系统层 （必监控）：

• CPU使用率 > 80% 告警
• 内存使用率 > 85% 告警
• 磁盘使用率 > 90% 告警
• 网络流量异常

应用层 （按需）：

• 接口响应时间
• QPS / 错误率
• JVM / 连接池状态

三、方案选型

3.1 主流方案对比

方案 | 优点 | 缺点 | 适用规模
---|---|---|---
Prometheus + Grafana | 功能强大，生态丰富 | 学习成本高 | 中大型
Zabbix | 功能全面，中文友好 | 配置复杂 | 传统企业
夜莺(Nightingale) | 国产化，开箱即用 | 社区活跃度一般 | 中小型
云监控(阿里云/腾讯云) | 无需部署，免运维 | 费用较高 | 云上业务

3.2 推荐方案

小型团队（ <50台服务器）：

• 云监控 + 自建夜莺

中型团队（50-500台） ：

• Prometheus + Grafana

大型团队（500+台） ：

• 多套 Prometheus + Thanos 集群

四、实战：搭建 Prometheus + Grafana

4.1 部署 Prometheus

# 下载
wget https://github.com/prometheus/prometheus/releases/download/v2.45.0/prometheus-2.45.0.linux-amd64.tar.gz
tar xzf prometheus-2.45.0.linux-amd64.tar.gz
cd prometheus-2.45.0.linux-amd64

# 配置 prometheus.yml
global:
scrape_interval: 15s

scrape_configs:

static_configs:

• job_name: 'node'
• targets: ['localhost:9100']

# 启动
./prometheus --config.file=prometheus.yml

4.2 部署 Node Exporter

# 在被监控服务器上
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar xzf node_exporter-1.6.0.linux-amd64.tar.gz
cd node_exporter-1.6.0.linux-amd64

# 启动
nohup ./node_exporter &

# 访问 http://服务器IP:9100/metrics 查看指标

4.3 部署 Grafana

# Docker 方式
docker run -d \
--name=grafana \
-p 3000:3000 \
grafana/grafana

# 访问 http://服务器IP:3000
# 默认账号 admin/admin

4.4 配置仪表盘

1. 添加 Prometheus 数据源
2. 导入 Node Exporter 仪表盘（ID: 8919）
3. 查看监控面板

五、告警配置

5.1 AlertManager 部署

# alertmanager.yml
global:
resolve_timeout: 5m

route:
group_by: ['alertname']
receiver: 'wechat'

receivers:

wechat_configs:

agent_id: 'your_agent_id'
api_secret: 'your_secret'
to_user: 'user1|user2'

• name: 'wechat'
• corp_id: 'your_corp_id'

5.2 告警规则

# rules.yml
groups:

rules:

expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "CPU使用率超过80%"

• name: node_alerts
• alert: CPU使用率过高

expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
for: 5m
labels:
severity: critical
annotations:
summary: "根分区磁盘空间不足10%"

• alert: 磁盘空间不足

六、监控最佳实践

6.1 告警分级

级别 | 含义 | 通知方式 | 处理时效
---|---|---|---
P0 | 服务不可用 | 电话 + 短信 | 5分钟
P1 | 服务降级 | 短信 + 微信 | 30分钟
P2 | 性能下降 | 微信 + 邮件 | 4小时
P3 | 潜在风险 | 邮件 | 24小时

6.2 避免告警风暴

# 配置告警静默
# 同一告警 10 分钟内不重复发送
group_wait: 30s
group_interval: 5m
repeat_interval: 10m

6.3 常用监控指标

基础指标 ：

• node_cpu_seconds_total \- CPU 使用时间
• node_memory_MemAvailable_bytes \- 可用内存
• node_filesystem_avail_bytes \- 磁盘可用空间
• node_network_receive_bytes_total \- 网络接收流量

业务指标 ：

• http_request_duration_seconds \- 接口响应时间
• http_requests_total \- 请求总数
• active_connections \- 活跃连接数

七、故障排查案例

案例1：服务器响应慢

现象 ：用户反馈网站打开慢

监控排查 ：

1. Grafana 查看 CPU 使用率 → 正常
2. 查看内存 → 正常
3. 查看 I/O 等待 → 飙升
4. 定位：磁盘 I/O 问题

解决 ：发现日志文件过大，清理后恢复

案例2：数据库连接池耗尽

现象 ：应用报错"连接数不足"

监控排查 ：

1. 查看 MySQL 连接数 → 已达上限
2. 查看慢查询日志 → 发现慢 SQL
3. 定位：某个查询未走索引

解决 ：添加索引，连接数恢复

八、监控进阶

8.1 日志监控（ELK）

应用日志 → Filebeat → Kafka → Logstash → Elasticsearch → Kibana

8.2 链路追踪（Jaeger）

请求 → 服务A → 服务B → 服务C
↓ ↓ ↓ ↓
Jaeger Agent → Jaeger Collector → UI

8.3 APM 监控

推荐：

• SkyWalking（国产，功能全面）
• Pinpoint（性能影响小）
• Elastic APM（与 ELK 集成）

九、总结

监控三原则 ：

1. 监控先行 ：上线前先搭监控
2. 分层监控 ：从应用到基础设施
3. 告警有效 ：减少噪音，精准告警

推荐路线 ：

第1周：部署 Prometheus + Grafana
第2周：配置告警规则
第3周：接入应用监控
第4周：优化仪表盘

相关阅读

• Prometheus 官方文档
• Grafana 仪表盘市场
• 告警最佳实践指南

本文由AIIT数字工坊原创，专注IT运维实战干货。