全部文章

在知了里问它一句，观察它的内部：

新手最容易犯的错是"我想做一个啥都会的 Agent"——啥都会等于啥都不精。正确的做法是：从一个真实场景出发，把功能列成清单。

误解一：Agent 是某种神秘的高级 AI。 不是。

最后的冲刺：把开发机上的 8014 端口变成一个可以长期运行、HTTPS 加密、 宕机自愈的线上服务。三种形态按序讲：一键脚本（本机长期跑）、 Docker Compose 三角色（标准生产形态）、systemd + nginx（无 Docker 服务器）， 然后给生产安全清单，最后回顾整个系列。

到上一篇为止，功能全部写完。但"能跑"和"敢改"是两回事——没有测试的代码库， 每次改动都靠胆量。

平台的"观测"已经完整，这一篇补齐"处置"：拨测（黑盒视角）、故障单（告警聚合与 复盘）、巡检（定期体检）、SLO（错误预算）、自愈（告警后自动处置）、通知渠道（真实 邮件/企微/钉钉）、审计（谁在什么时候干了什么），以及全平台唯一"真删文件"的 清理加速中心——它的安全边界设计单独一节讲。

告警解决"出事有人喊"，这一篇解决"看懂数据"：

前七篇解决了"看得见"，这一篇解决"等不起"——告警是监控平台存在的理由： 数据再全，出事时没人盯着看就等于没有。

这一篇补齐四路采集的后两路：

请求指标回答"应用怎么样"，这一篇回答"机器怎么样"：CPU、内存、磁盘、网络—— 而且不止平台所在的这一台：自研 Agent 让任意多台服务器把指标推过来。 顺带完成两块基建：租约选主（多副本不重复采集）和令牌鉴权（匿名写入 401）。

上一篇结束时，每个请求的指标在响应返回之前同步写进了 SQLite。 演示没问题，但只要上点并发就会现出原形：SQLite 是单写者锁——同一时刻只允许一个 线程写库，所有请求线程排队抢锁、每条 INSERT 各自 fsync。

监控平台自己不产生业务——我们需要一个"被观测对象"。这一篇做两件事：