告警与渠道
渠道就是告警可以发往的地方。你想加多少就加多少，然后为每个监控项分别选择哪些用于日常通知、哪些用于告警升级。
你可以添加什么
这些由你自己在「设置 → 通知」中添加：
- 电子邮件——任意地址。
- Slack、Teams、Discord——来自对应应用的传入 webhook URL。
- Telegram——一个聊天，通过我们的机器人关联。
- PagerDuty 和 Jira Service Management——一个集成密钥。
- Webhook——你自己的端点。仅支持 HTTPS，带签名，详见下文。
这些由接收的人自己添加，而不是由别人替他填写：
- 推送——安装手机应用并允许通知。
- 短信——登记你自己的号码，并确认我们发到该号码的验证码。
- WhatsApp——同样的流程，走 WhatsApp。
- 卫星——Iridium、Inmarsat 或 Thuraya 手持终端，经网络运营商的网关以电子邮件送达。
渠道属于谁
每个渠道要么属于团队，要么属于某一个人，这个区别决定了有人离开时会发生什么。
共享渠道——一个 #alerts webhook、一个 PagerDuty 服务、一个邮件组——属于组织，任何人离开它都会保留下来。
个人渠道——一台手机、一个私人 Telegram 聊天、一个手机号——属于登记它的那个人，并且在这个人被移出组织时会被删除。在这条规则生效之前，被移除的同事的 Telegram 聊天会无限期地继续收到宕机通知，尽管其成员身份和 API 密钥早已被吊销。
所以在路由告警时，要看清你把它发往的渠道属于谁。配置呼叫的人通常并不是被它叫醒的人。
地址必须先同意，才会收到任何内容
电子邮件、短信、WhatsApp 和卫星都要先确认。添加一个电子邮件渠道后，该地址只会收到恰好一条消息——询问它是否愿意成为告警接收地址——在它同意之前不会再收到别的。登记手机号时，则由你把收到的验证码填回来。
之所以这样，是因为电子邮件渠道是别人在别人的账户里填进去的一个地址。没有这道关卡，一个编辑者就能把一个不断抖动的监控项指向陌生人的收件箱，而我们会照送不误。测试发送按钮在地址确认之前同样会被拒绝，理由相同：否则它就是一种无限次向未经同意的地址发信的办法，只是顶着一个看起来很贴心的名字。
聊天渠道和推送渠道不会询问，这并不是例外。粘贴 Slack webhook URL 的人必须先持有它，而推送渠道是由手机的主人自己注册的——这两者都无法靠填一个地址指向陌生人。
已经属于你所在组织中某位已验证成员的地址会自动确认。他们在注册时就已经证明了该地址是自己的。
短信与 WhatsApp
两者都需要 Pro 及以上套餐，并且共用同一份配额——Pro 为每天 10 条、每周 15 条、每月 30 条；Business 和 Enterprise 为 15、50 和 100 条。它们共用一份配额，是因为两者都按条计费，也都送到同一台手机上，所以上限要防的那件事——一个抖动的监控项在一小时内花光一个月的预算——不论走哪条路都是同一件事。
用三个窗口而不是一个，是因为只用一个的形状不对。只有月度上限，一个抖动的监控项一个下午就能把额度花光；只有日上限，慢慢滴漏的告警能花掉你预期的三十倍。
上限在消息入队时就会生效，因此被拦下的消息根本不会占用队列位置；计数依据的是实际发出的消息，而不是一个计数器——计数器没法在调用别人的 API 这件事上保持诚实。
短信并非哪里都能送达，我们会在你登记之前说清楚
短信的可达性取决于收件人所在的国家或地区。有些网络根本不承载来自我们这类发送方的消息；另一些只接受来自已在当地监管机构注册的发送方名称的消息。国家选择器只会列出我们认为能送达的目的地，价格页面上有完整清单。
凡是发送方名称可能被替换成本地号码的地方，我们都会在登记时告知你，而不是让你从一条来自陌生号码的消息里发现这件事。WhatsApp 没有这些限制，在任何地方都不需要注册，并且能送到短信送不到的每一个国家和地区。
告警绝不包含链接。运营商会过滤未知 URL，而被过滤掉的告警就是你永远收不到的告警——所以名为 acme.com 的监控项会以 acme com 的形式送达。
卫星
适用于完全没有蜂窝网络覆盖的手持终端。消息经运营商的网关以电子邮件发出，因此你付的是电子邮件的费率而不是短信的费率——但运营商把投递上限定为每台手持终端每天五条，那是他们的限制而不是我们的，并且每条消息会被截断到 160 个字符。
响应异常缓慢
一个监控项可能每次检查都通过，却仍然有问题。一旦它积累了至少一天的历史数据，我们就会把它现在的响应速度与它在同一测量点的平常速度相比较，当它明显慢于平常时通知你——走的是该监控项发生事件时会用的同一批渠道。速度恢复正常后，我们也会告诉你。所有套餐都提供此功能。
这不是事件。没有任何东西宕机，所以它不计入可用率、不会出现在状态页上，也不会升级。比平常更快永远不会告警；变慢必须至少达到 100 毫秒，并且明显超出该监控项的正常波动；监控项暂停、处于维护窗口内或已有未关闭的事件时，不做任何判断。
Webhook 会以 latency_anomaly 和 latency_recovered 事件接收这些通知，并附带以毫秒计的平常响应时间和实测响应时间。
Webhook
仅支持 HTTPS。每个请求都会签名，方便你验证它确实来自我们。私有地址和链路本地地址在你保存 URL 时会被拒绝，并且在告警发送时会再被拒绝一次——因为保存时解析到公网地址的主机名，之后可能解析到别处，而通过了校验的 URL 也可能用一个指向任意位置的重定向来响应。重定向不会被跟随。
值班
需要 Pro 及以上套餐。建立轮班、设置告警升级步骤，未被确认的事件就会沿着这些步骤逐级上升。确认会停止告警升级；解决则会将其关闭。
告警升级正是个人渠道值得添加的理由：第一级可以是团队聊天，最后一级可以是某个人凌晨四点的手机。
事后复盘
所有套餐均可使用。事件解决后，任何有权解决事件的人都可以撰写事后复盘——发生了什么、原因是什么、要做哪些改变——并随着调查推进继续修改。每个事件一份，用 Markdown 撰写：标题、粗体和斜体、列表、代码、引用和链接。HTML 会按原文显示，绝不会被执行。
事后复盘仅限内部。它绝不会出现在状态页上，因为其中通常会提到人员、系统和失误。保存操作会记入审计日志，记录的是长度而非内容。
什么都送不出去时会发生什么
失败的渠道会把原因用服务商自己的说法记在自己身上，而不是默默地失败。被拒绝的短信会写明网络方说了什么。被接受几分钟后又遭拒绝的 WhatsApp 消息会写明是哪个模板、哪种语言。
这件事比听上去更重要。这些服务商每一家都会立刻回答「已接受」，而把真正的结果留到稍后再报——所以如果不去读那份报告，渠道看起来是已验证的，消息看起来是已发送的，而任何人听到的第一个消息，将是一次没人被告知的宕机。