当API宕机时获取电话警报

API故障的标准推送通知会在噪音中丢失。了解如何设置真正的电话警报，让您在关键服务故障时真正被唤醒。

当API宕机时获取电话警报

您的API在凌晨3点宕机不是问题。问题是直到上午9点才发现，那时您的用户已经淹没了您的支持邮箱。

大多数监控工具擅长检测故障。但它们不擅长确保有人在正确的时间看到警报。标准推送通知会留在锁屏上，直到有人恰好拿起手机。Slack消息会埋没在夜间无人查看的频道中。电子邮件会未被阅读直到周一早上。

电话警报改变了这个等式。当您的API健康检查失败时，您的手机真的会响——就像其他紧急电话一样。您接听，听到是什么问题，可以立即开始修复，而不是几小时后。

为什么推送通知对关键服务失效

普通智能手机每天接收50到100条推送通知。您的API故障警报与应用更新、社交媒体通知、新闻警报和设备上的每个其他应用竞争。当一切都紧急时，就没有什么感觉是紧急的了。

这创造了一个危险的模式：

  1. 您的监控工具检测到API返回500错误
  2. 向您的手机发送推送通知
  3. 您的手机放在桌子上，面朝下，启用了勿扰模式
  4. 警报静默地待在那里，直到有人注意到——几小时后

对于非关键微服务，这种延迟很烦人。对于支付API、身份验证服务或您主要产品的后端，这种延迟会浪费真正的金钱和信任。

Echobell的电话警报如何工作

Echobell以三种紧急级别交付通知：

  • 普通（活跃）： 标准推送通知
  • 时间敏感： 穿透iOS勿扰模式但不响铃
  • 来电： 像普通电话一样响铃

对于影响用户的API故障，来电级别是合适的。它反映了您如何处理任何其他紧急电话——您接听是因为手机在响。

设置很简单：

  1. 在Echobell中创建频道
  2. 将通知类型设置为来电
  3. 通过Webhook连接您的监控工具
  4. 当健康检查失败时，Echobell会呼叫您

从监控工具设置来电警报

大多数监控平台可以在检查失败时发送Webhook。以下是连接方法。

使用您现有的健康检查

如果您已有健康端点（如/health或/status），请将监控器配置为定期检查它。当响应不是200时，触发Webhook。

Echobell接受带有标题和正文的Webhook负载：

curl -X POST https://hook.echobell.one/YOUR_CHANNEL_ID \
  -H "Content-Type: application/json" \
  -d '{
    "title": "API宕机: payment-service",
    "body": "健康检查失败 - 500错误 于 03:42 UTC",
    "notificationType": "calling",
    "externalLink": "https://your-dashboard.example.com/incidents/123"
  }'

notificationType: calling字段是触发手机响铃的原因。

警报中应包含的内容

保持警报内容可扫描。当您在凌晨3点接听电话时，您需要立即理解问题：

  • 服务名称 - 哪个API或微服务宕机
  • 错误类型 - 超时、5xx、连接拒绝
  • 时间戳 - 故障何时开始
  • 链接 - 立即调查的位置

这不是冗长消息的地方。目标是即时上下文，这样您可以决定是完全醒来还是只是确认然后回去睡觉。

选择正确的紧急级别

并非每个API故障都需要电话。使用来电警报：

  • 支付和计费服务
  • 身份验证和登录端点
  • 用户直接交互的主要产品API
  • 其他关键系统依赖的服务

使用时间敏感通知：

  • 重要但对收入不关键的非生产服务
  • 开发或预发布环境
  • 警告信号（高错误率但尚未完全故障）

使用普通通知：

  • 非关键的后台作业
  • 不需要操作的信息指标

这种分级方法可让您保持警觉而不会产生警报疲劳。

扩展到多个服务

如果您运行多个API，请为每个服务或服务组创建单独的频道：

  • production-payment-api - 来电级别
  • production-user-api - 来电级别
  • production-analytics-api - 时间敏感
  • staging-all - 时间敏感

这让您可以按服务调整紧急程度。您的支付API值得一个电话；您的分析管道可能不值得。

相关

作者：

Nooc

发布于

2026年3月13日