通向真正良好的监控堆栈的 3 年历程

2022 年初开始构建Phare：最初计划架构时以为获取网站进行运行状况检查是主要扩展瓶颈，实际不然，此假设导致过去三年的架构选择不佳。构建运行状况监测服务时，不希望监测基础设施效率低下或不准确，维护和规划优先于其他，否则产品将停止发展。
- 第一个版本：AWS Lambda 上的 Python：AWS Lambda 很合适，可轻松在多个区域运行代码且无前期成本和维护成本，用 Python 编写 Lambda 代码，通过 AWS SDK 支持的并行调用解决数据协调问题，大部分业务逻辑基于此结果集，此设置早期运行良好，但 2024 年 5 月收到约 25 欧元的 AWS 发票，Lambda 持续时间（GB-Seconds）花费大，请求定时准确性也有问题。
进入 Cloudflare Workers：Cloudflare Workers 比 AWS Lambda 便宜，仅按实际 CPU 时间付费，空闲时间等待超时免费，可构建最便宜的运行状况监测服务并提供 180 个区域，但设置不简单，需用 JavaScript 重写代码且无法在特定区域调用 Worker，通过一个 Worker 调用另一个 Worker 解决区域问题，虽有局限性但运行平稳，生态快速增长，但 2024 年 11 月 14 日区域调用被修补，整个运行状况基础设施下线。
Bunny.net Edge Scripts 救援：Bunny.net 推出 Edge Scripts 服务，与 Cloudflare Workers 竞争，定价相似，迁移看起来即插即用，用 Deno 重写脚本并采用双调用策略，迁移初期运行良好，后出现新瓶颈，如后端代码调用 Edge Scripts 导致 502/503 错误，队列等待时间增加，虽 Bunny 技术团队帮助很大但仍面临限制。
明显答案：Bunny Magic Containers：2025 年初 Bunny 宣布 Magic Containers，可在其全球网络部署完整 Docker 容器，已集成 Bunny 生态系统且对其支持团队有信心，缓慢构建几个预览区域测试，新的运行状况监测代理用 Go 编写，完全解耦后端与监控代理，从 API 获取监控列表，异步发送结果，数据交换最小，容错且自我修复，匹配 Edge Script 版本，新预览区域运行良好，作者可休假一个月且无问题，目前所有检查都在 Bunny Magic Containers 上运行，可专注于新功能开发。
未来计划：当前基础设施虽运行良好但不完美，容器重启时有短暂重叠，区域离线无重新路由，通过 API 每分钟获取监控列表效果好但仍在探索减少 HTTP 调用的方法，可能靠近容器设置只读副本，从外部看在基础设施混乱期间 Phare 增长到近千用户，用户对服务质量很满意，此篇主要是对过去自己的抱怨，过去因走太多捷径导致公司发展受限，也许这就是初创公司的常态，未来三年可能会有关于 Phare.io 监测栈 v8 的博客文章，可能用 Rust 重写。