为什么我作为独立开发者又构建了一个 Uptime 监控工具

Source: Dev.to

Overview

市面上已经有很多正常运行时间监控工具。有的功能强大，有的相当成熟，还有的几乎提供了你能想象的所有功能。

于是自然会出现一个问题：

为什么要再造一个？

对我来说，答案始于一次简单的挫败感。随着时间的推移，我注意到许多监控产品的复杂度增长速度快于其清晰度。用户往往只需要几件事：

• 知道服务何时宕机
• 明白到底是哪儿出了问题
• 快速收到警报
• 避免误报

然而在你甚至还没有创建第一个监控之前，很多仪表盘就已经显得信息过载。作为一个花了多年时间构建软件产品的人，我想要一个在技术上仍然强大，却保持简洁易懂的监控工具。这就是 UptimeTick 的起点。

The Problem I Wanted to Solve

最大的问题并不是检查网站是否有响应——那部分很简单。真正的挑战在于判断一次失败是否是真正的宕机。一次请求失败并不一定意味着停机，它可能是：

• 临时的丢包
• DNS 延迟
• 区域性路由问题
• 后端响应慢
• CDN 短暂抖动

如果警报触发得太早，信任度会迅速下降。这也是我在重试逻辑和信号质量上投入大量精力的原因。

How I Designed the Monitoring Flow

每一次检查在生成事件之前都会经过一个决策过程。一次失败的请求不会立即被视为宕机，而是：

• 自动进行重试
• 测量响应时间
• 评估状态历史
• 谨慎控制健康状态的转变

这大幅降低了误报的可能性。实际上，这比添加数十个额外功能更为重要。

Infrastructure Choices

后端采用分布式架构，旨在实现轻量但可扩展的检查。核心部分包括：

• Laravel 队列
• 隔离的检查任务
• 基于云的执行层
• 自定义响应处理

对于 HTTP 检查，我还需要保持请求身份的一致性，因此请求使用了专用的监控用户代理。这看似微不足道，却有助于透明度和过滤。

Why Simplicity Matters More Than Feature Count

很多产品通过增加选项来竞争。我尝试换一种思路：

如果更少的决策会产生更好的产品会怎样？

这意味着：

• 简洁的监控创建流程
• 可读的事件记录
• 易于理解的警报机制
• 没有不必要的噪音

尤其对于独立创始人和小团队来说，清晰往往更具优势。

Building as a Solo Developer

独自开发的一个优势是速度快。一个劣势是所有决策都由你一人承担。基础设施、用户体验、警报、定价逻辑、移动端行为、故障处理——所有东西都经过同一个大脑。这会带来压力，但也让产品决策保持高度一致。

What I Learned

监控不仅是技术问题，更是信任问题。用户必须相信警报是有意义的。如果信号不可靠，即使是最好的基础设施也会失去价值。这一教训影响了我几乎所有的决策。

Still Improving

产品仍在持续演进。有些改进体现在基础设施上，有些体现在界面细节上，还有一些是因为用户的使用方式与预期不同。这个反馈循环是公开构建过程中最好的部分之一。

如果你经常使用监控工具，我真的很想听听你的声音：

你认为大多数正常运行时间监控工具最常犯的错误是什么？