我如何使用 FastAPI 构建分布式正常运行时间监控系统

I’m happy to translate the article for you, but I need the full text of the post in order to do so. Could you please paste the content you’d like translated (excluding the source line you already provided)? Once I have the article text, I’ll translate it into Simplified Chinese while preserving the original formatting, markdown, and code blocks.

实时监控的真正问题

大多数正常运行时间监控工具的工作方式如下：

• 单个服务器每隔几分钟向你的端点发送一次请求。
• 如果请求失败，系统会判定为停机。

简单。但也非常错误。

单个监控点无法可靠地判断应用是否真的宕机。网络路由问题、DNS 延迟或临时拥塞都可能导致误报停机，即使服务实际上运行正常。在生产环境中，误报会带来严重问题：

• 工程师对监控系统失去信任。
• 警报不再有用。

当我开始构建 TrustMonitor 时，首要的设计约束很简单：

• 监控系统本身必须足够可靠，值得信赖。

架构概览

系统不再依赖单一监视器，而是采用分布式验证方法。监控流程如下：

Scheduler
   ↓
Primary Monitor
   ↓
Secondary Verification
   ↓
Incident Recording
   ↓
Signed Incident Report

每个阶段都降低误报的概率，并确保事件在记录后无法被修改。

监控调度

系统使用调度器负责在定义的间隔时间内分发监控任务。

每个任务包含：

• endpoint URL
• expected_status 状态码
• timeout 阈值

示例结构：

{
  "endpoint": "https://api.example.com/health",
  "expected_status": 200,
  "timeout": 5
}

调度器将这些任务推送到队列中，由工作节点执行实际检查。将调度与执行分离，可防止因工作节点变慢或暂时不可用而导致监控延迟。

主监视器

主监视器向目标端点发送初始请求。在当前实现中，这通过运行异步 HTTP 检查的 FastAPI 工作进程来处理。

简化检查示例：

import httpx

async def check_endpoint(url):
    async with httpx.AsyncClient(timeout=5) as client:
        response = await client.get(url)
        return response.status_code

如果响应符合预期条件，监视器会记录一次成功检查。如果不符合，系统不会立即声明宕机——这正是大多数监控工具失效的地方。

二次验证

在记录事件之前，二次验证监视器会重复检查。此步骤确认故障是真实的还是由临时网络状况引起的。

验证逻辑:

Primary Monitor detects failure
        ↓
Secondary Monitor runs verification check
        ↓
If failure confirmed → incident recorded
If success → ignore false positive

这一简单机制显著降低了误报的停机警报。

事件记录

一旦故障得到验证，系统会记录一个包含以下内容的事件：

• 时间戳
• 端点
• 故障原因
• 验证结果

示例事件结构:

{
  "endpoint": "api.example.com",
  "status": "DOWN",
  "timestamp": "2026-03-05T10:20:15Z",
  "verified": true
}

仅记录事件是不够的；监控系统还必须确保数据完整性。

加密事件签名

TrustMonitor 的一个关键设计决定是对事件记录进行加密签名。这可以防止事件随后被篡改。每个事件都使用加密摘要进行哈希。

概念流程:

incident_data → SHA256 → incident_signature

签名证明该事件在特定时间存在且未被修改。这对于以下情况很有用：

• 事后审计
• SLA 验证
• 基础设施调试

经验教训

单点监控不可靠
网络问题持续发生。单一监控无法确定服务健康状况。验证层是必不可少的。

监控系统必须值得信赖
如果警报产生过多误报，工程师最终会忽视它们。一个不被信任的监控系统比根本没有监控更糟。

事件完整性很重要
监控数据应具备防篡改性。签名的事件可创建可验证的基础设施事件记录。

最终思考

监控基础设施在纸面上听起来很简单。在实践中，可靠性需要围绕以下方面进行精心设计：

• 验证
• 分布式检查
• 事件完整性

TrustMonitor 仍在发展中，但其构建已经显现出围绕监控准确性和系统信任的有趣工程挑战。

未来的改进将侧重于：

• 多区域验证
• 异常检测
• 提升警报可靠性

因为在监控系统中，信任就是一切。