从‘它又挂了’到‘稳如老狗’：我是如何用Prometheus+Grafana给自家小破站做监控的
从“它又挂了”到“稳如老狗”：我是如何用Prometheus+Grafana给自家小破站做监控的
凌晨三点，手机突然响起钉钉告警——这已经是本周第三次被“502 Bad Gateway”的提示音吵醒。揉着惺忪睡眼重启Nginx时，我突然意识到：这个用业余时间维护的个人博客，正在消耗远超预期的精力。如果你也经历过服务器突然崩溃却找不到原因、或是流量小高峰时手忙脚乱调整配置的窘境，这套用Prometheus+Grafana搭建的轻量监控方案，或许能让你和我一样告别“救火队员”的角色。
1. 为什么个人项目更需要监控？
很多人认为监控是企业级应用的专利，直到某天发现：
- 隐性故障：数据库连接池悄悄耗尽，用户看到的是“偶尔抽风”
- 事后复盘：没有历史数据，故障排查变成“盲人摸象”
- 资源黑洞：某个跑偏的脚本吃光内存，连带拖垮整个服务
我的博客运行在2核4G的云服务器上，使用率长期低于30%。直到某天收到云厂商的流量超额账单，才发现被爬虫持续扫描漏洞。正是这次教训让我明白：监控不是成本，而是性价比最高的运维投资。
2. 监控方案选型：为什么是Prometheus+Grafana？
对比常见方案：
| 工具 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|
| Zabbix | 功能全面 | 资源占用高 | 企业级环境 |
| Nagios | 告警机制成熟 | 配置复杂 | 传统运维 |
| CloudWatch | 开箱即用 | 费用随数据量增长 | AWS深度用户 |
| Prometheus | 轻量、时序数据专业处理 | 需要自行搭建 | 容器/微服务/个人项目 |
Prometheus的多维度数据模型和Pull模式特别适合资源有限的场景。配合Grafana的可视化能力，不到1GB内存就能获得企业级80%的监控功能。
提示：如果你的服务器内存小于1G，可以考虑关闭Prometheus的TSDB压缩（storage.tsdb.retention.size参数）
3. 实战部署：从零搭建监控系统
3.1 安装Prometheus
用Docker快速启动（假设已安装Docker）：
mkdir -p /opt/prometheus/config cat <<EOF > /opt/prometheus/config/prometheus.yml global: scrape_interval: 15s scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['localhost:9090'] EOF docker run -d --name=prometheus \ -p 9090:9090 \ -v /opt/prometheus/config:/etc/prometheus \ prom/prometheus关键参数说明：
scrape_interval：抓取频率，个人站点建议15-30秒targets：监控目标地址，后续会逐步添加
3.2 接入基础指标
3.2.1 监控服务器本身
安装node_exporter采集主机指标：
docker run -d --name=node_exporter \ -p 9100:9100 \ --net="host" \ --pid="host" \ -v "/:/host:ro,rslave" \ prom/node-exporter然后在prometheus.yml中添加新job：
- job_name: 'node' static_configs: - targets: ['your_server_ip:9100']3.2.2 监控Nginx
启用Nginx stub_status模块：
server { listen 8080; server_name localhost; location /metrics { stub_status on; access_log off; allow 127.0.0.1; deny all; } }通过nginx-exporter转换指标格式：
docker run -d --name=nginx-exporter \ -p 9113:9113 \ nginx/nginx-prometheus-exporter \ -nginx.scrape-uri http://your_nginx_ip:8080/metrics3.3 配置Grafana仪表盘
启动Grafana容器：
docker run -d --name=grafana \ -p 3000:3000 \ grafana/grafana登录后：
- 添加Prometheus数据源（地址填http://prometheus:9090）
- 导入官方仪表盘：
- 主机监控：ID 1860
- Nginx监控：ID 12708
我的自定义看板重点关注：
- 黄金指标：请求错误率、响应时间、流量
- 资源水位线：CPU>80%或内存>90%持续5分钟告警
- 业务指标：每日活跃用户、热门内容排行
4. 告警配置：从被动响应到主动预防
4.1 基础告警规则
在prometheus.yml同级目录创建alert.rules文件：
groups: - name: host rules: - alert: HighCPU expr: 100 - (avg by(instance)(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80 for: 5m labels: severity: warning annotations: summary: "高CPU使用率 ({{ $value }}%)" description: "实例 {{ $labels.instance }} CPU持续高于80%" - alert: NginxDown expr: nginx_up == 0 for: 1m labels: severity: critical annotations: summary: "Nginx服务下线"4.2 对接钉钉告警
使用Prometheus Alertmanager + 钉钉机器人：
- 配置alertmanager.yml：
route: receiver: 'dingding' receivers: - name: 'dingding' webhook_configs: - url: 'https://oapi.dingtalk.com/robot/send?access_token=your_token' send_resolved: true- 启动Alertmanager容器：
docker run -d --name=alertmanager \ -p 9093:9093 \ -v /path/to/alertmanager.yml:/etc/alertmanager/alertmanager.yml \ prom/alertmanager5. 避坑指南：那些年我踩过的雷
指标爆炸：初期采集了太多无用指标，导致Prometheus存储暴涨
- 解决方案：用
metric_relabel_configs过滤
metric_relabel_configs: - source_labels: [__name__] regex: '(node_network_receive_bytes|node_cpu_seconds_total)' action: keep- 解决方案：用
告警疲劳：最初设置的阈值太敏感，半夜频繁被吵醒
- 优化方案：区分warning/critical级别，非核心服务设置工作时间告警
资源竞争：监控系统自身消耗过高
- 实测数据（2核4G服务器）：
- Prometheus：约300MB内存
- node_exporter：15MB内存
- Grafana：200MB内存
- 实测数据（2核4G服务器）：
6. 进阶技巧：让监控产生业务价值
除了基础运维指标，我还逐步添加了：
用户体验监控：通过Nginx日志分析慢请求
# 统计P99响应时间 histogram_quantile(0.99, sum(rate(nginx_http_request_duration_seconds_bucket[5m])) by (le))成本关联：结合云API获取费用数据，建立“流量-资源-成本”关联分析
自动化联动：当检测到爬虫特征时，自动触发WAF规则更新
现在我的早晨例行检查从SSH登录变成了打开手机看Grafana仪表盘。有次朋友问我：“你网站最近怎么这么稳定？”我笑着回答：“因为我知道它什么时候会出问题——在用户发现之前。”