烽火台 Beacon Tower：全栈可观测平台实战

先看成品，再决定要不要花时间跟着做——这是最负责任的学习方式。

写代码之前，先把"我要做一个监控平台"这句话翻译成一张能指导开发的清单。 这一篇不写一行代码，但它决定了后面 11 篇代码的质量——需求想不清，代码全是还债。

需求清单有了，这一篇把它翻译成三样东西：一张数据流架构图、9 个 app 的职责边界、 一组关键设计决策（每个都带"为什么选它、放弃了什么"）。设计做到这个颗粒度就够了—— 剩下的细节交给开发时按需决定，过度设计和没有设计一样危险。

这一篇从空文件夹开始，把骨架立起来：虚拟环境 → Django 工程 → settings 逐段精讲 → 9 个 app → 核心数据模型 → 整站登录门禁 → 跑通第一个页面。 做完这一篇，你就拥有一个"需要登录、带健康检查、数据库就绪"的空平台。

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

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

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

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

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

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

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

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

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