监控不是摆设：一个独立开发者的血泪实战指南
上周五晚上十一点，我正瘫在沙发上刷B站，突然手机“叮”一声——不是女朋友消息（毕竟单身狗），而是Grafana发来的告警：“CPU使用率 > 95% 持续5分钟”。我瞬间从“躺平模式”切换到“战备状态”，抄起MacBook就往书房冲。远程办公的自由背后，是随时可能被线上事故叫醒的宿命。
我是谁？一个坐标北京、通勤一小时但基本不用去公司的独立开发者。白天写分布式系统，晚上调Vim配置，偶尔接点爬虫或前端的小活儿贴补家用。没有团队支持，没有运维兜底，所有服务都得自己盯——监控，就成了我活下去的命脉。
今天这篇文章，不讲高大上的SRE理论，就说说像我这样的“一人团队”怎么低成本、高效率地把监控搞起来。顺便聊聊那些让我半夜惊醒的坑，以及为什么面试官总爱问“你怎么设计监控系统”。
一开始，我连日志在哪都找不到
去年双11前，我接了个小项目：给一家电商做数据采集。说白了就是写个爬虫，每天抓几百万商品信息，存进数据库，再用前端展示趋势图。听起来简单？上线第三天，爬虫突然停了，客户电话打爆：“数据断了！你们技术是不是在摸鱼？”
我当时一脸懵。代码跑得好好的啊？后来才发现，爬虫因为反爬机制被封IP，默默退出了进程，而我连它挂了都不知道。更惨的是，前端页面加载超时，用户看到一片空白，还以为我们跑路了。
那一刻我悟了：没有监控的系统，就像没装刹车的车——跑得越快，翻得越惨。
于是痛定思痛，开始研究监控。但网上教程动不动就Prometheus+Alertmanager+Loki全家桶，配置文件比我的Vimrc还长。作为一个习惯了vim ~/.bashrc就解决问题的人，我真的不想为了看个CPU占用率搭一套K8s集群。
怎么办？从最痛的点切入。
爬虫挂了？先让它“会说话”
爬虫是我第一个要监控的对象。核心需求就两个：
- 它还在跑吗？
- 它抓了多少数据？
最简单的办法：让程序定期写心跳。我在爬虫主循环里加了几行代码：
import time
import json
from pathlib import Path
HEARTBEAT_FILE = "/tmp/crawler_heartbeat.json"
def update_heartbeat(count):
with open(HEARTBEAT_FILE, "w") as f:
json.dump({
"last_update": int(time.time()),
"item_count": count,
"status": "running"
}, f)
然后写个Shell脚本每分钟检查一次：
#!/bin/bash
# check_crawler.sh
if [ ! -f /tmp/crawler_heartbeat.json ]; then
echo "Crawler not started!" | send_alert.sh
exit 1
fi
last_update=$(jq -r '.last_update' /tmp/crawler_heartbeat.json)
now=$(date +%s)
if [ $((now - last_update)) -gt 300 ]; then # 超过5分钟没更新
echo "Crawler stuck!" | send_alert.sh
fi
配合cron，每分钟跑一次。告警方式？直接用微信机器人（别笑，真香）。虽然土，但成本低、见效快。客户再也没因为数据中断骂我了。
开发心得：监控的第一原则不是“全”，而是“有用”。先解决最痛的问题，再慢慢扩展。
前端也不能裸奔
很多人以为监控只是后端的事，前端？F12看看Console不就行了？天真！
有一次我给客户做的数据看板，用户反馈“页面打不开”。我本地测试一切正常。后来发现是某个CDN资源加载失败，导致整个React应用白屏。而我的后端API毫发无损——问题出在前端，但后端监控根本看不到。
于是我在前端加了基础监控：
- 页面加载性能（用
performance.timing） - JS错误捕获（
window.onerror） - 关键API请求成功率
代码片段如下：
// 简易前端监控SDK
window.addEventListener('error', (e) => {
fetch('/api/log', {
method: 'POST',
body: JSON.stringify({
type: 'js_error',
message: e.message,
stack: e.error?.stack,
url: window.location.href,
ua: navigator.userAgent
})
});
});
// 记录页面加载时间
window.addEventListener('load', () => {
const perf = performance.timing;
const loadTime = perf.loadEventEnd - perf.navigationStart;
// 上报...
});
后端收到这些日志后，统一存到Elasticsearch（其实是个单机版，别告诉别人），用Kibana看个大概。虽然比不上Sentry专业，但至少知道用户是不是在骂我写的代码。
面试题挑战：如果你去面大厂，八成会被问“如何监控前端异常？” 别只答Sentry，可以说说你的轻量化方案——毕竟不是每个公司都愿意为前端监控付几千美金/月。
分布式系统的“眼睛”：指标监控
作为对分布式系统有点研究的人，我深知：微服务越多，盲点越多。一个请求跨5个服务，到底卡在哪？
这时候就需要指标（Metrics）监控了。我试过Zabbix，太重；试过Datadog，太贵。最后选了 Prometheus + Grafana 这个开源组合。
为什么？
- Prometheus拉模型适合我的小规模部署
- Grafana画图漂亮，老板看了直呼“高级”
- 配置简单，YAML比JSON友好多了（Vim党狂喜）
我的prometheus.yml精简到极致：
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'backend'
static_configs:
- targets: ['localhost:9090'] # 应用暴露/metrics端点
- job_name: 'node'
static_configs:
- targets: ['localhost:9100'] # Node Exporter
应用侧用Python的prometheus_client库暴露指标：
from prometheus_client import Counter, start_http_server
REQUEST_COUNT = Counter('http_requests_total', 'Total HTTP requests')
start_http_server(9090) # 开个端口
@app.route('/')
def home():
REQUEST_COUNT.inc()
return "OK"
Grafana里建个Dashboard，CPU、内存、请求量、错误率一目了然。上周我发现某个接口错误率突增，点进去一看，是第三方API改了返回格式——立刻回滚，避免了一场事故。
| 监控维度 | 工具选择 | 成本 | 上手难度 |
|---|---|---|---|
| 进程存活 | 自研心跳 + cron | 0元 | ⭐ |
| 前端异常 | 自研SDK + ES | ~200元/月（云ES） | ⭐⭐ |
| 系统指标 | Prometheus + Node Exporter | 0元 | ⭐⭐⭐ |
| 日志分析 | Loki + Promtail | 0元 | ⭐⭐⭐⭐ |
注：Loki我后来也加上了，专门收应用日志。比ELK轻量太多，查询语法类似LogQL，配合Grafana无缝集成。
告警不是越多越好，而是越准越好
早期我犯了个大错：CPU>80%就告警。结果夏天办公室空调坏了，服务器温度升高，CPU飙到85%，手机疯狂震动。我顶着38度高温跑去机房（其实是家里路由器旁边），发现一切正常。
告警疲劳是真实存在的。现在我的告警策略很克制：
- 只监控关键路径（如爬虫是否运行、核心API是否可用）
- 设置合理阈值（比如错误率连续5分钟>1%才告警）
- 告警分级：P0级微信+电话，P1级只微信，P2级只记日志
Grafana的告警规则示例：
# grafana-alert.yaml
- name: critical
rules:
- alert: CrawlerDown
expr: up{job="crawler"} == 0
for: 2m
labels:
severity: critical
annotations:
summary: "爬虫进程挂了！"
另外，告警必须带上下文。以前只发“CPU高”，现在改成：“服务A的CPU使用率达92%，过去10分钟平均85%，关联日志见[链接]”。这样我一眼就知道要不要立刻处理。
写在最后：监控的本质是“减少不确定性”
远程办公三年，我越来越觉得：自由的前提是可控。没有团队帮你盯着系统，你就得靠工具武装自己。监控不是为了应付面试，也不是为了炫技，而是为了睡个安稳觉。
现在的我，手机里装着Grafana App，地铁上刷到告警能立刻SSH进去排查。上周客户夸我系统“稳如老狗”，其实哪有什么魔法，不过是把每一个可能出错的环节都“照亮”了而已。
如果你也是独立开发者、小团队成员，或者正在准备跳槽面试，不妨从今天开始：
- 给你的爬虫加个心跳
- 在前端埋个错误上报
- 用Prometheus看看你的服务到底在干嘛
成本不高，收益巨大。毕竟，线上不出事，才是最大的KPI。
对了，最近在刷LeetCode准备面试，发现“设计一个监控系统”居然成了高频题。看来，这不仅是生存技能，还是涨薪利器啊（笑）。
—— 一个在北京出租屋里和Vim、Prometheus相依为命的独立开发者
评论 0