看护 4000 个 Discord 服务器：Grafana、PostHog 以及它们告诉我们的事
一个悄悄制造了一半流量的循环、每天三百万次毫无意义的请求，以及一次一分钟后就结束的攻击。我们的监控能看到什么，又刻意不看什么。
AlphaCloud 运行在 4000 多个 Discord 服务器上，分布在四个分片中。这是四个进程，每个负责一部分服务器，全都与同一个 API 通信。
在这种规模下，问题很少通过让某个东西崩溃来暴露自己。更常见的是一切正常运行，只是比应有的更昂贵、更慢或更嘈杂。这就是我们在 2026 年 9 月重建监控的原因。本文展示它的样子，以及它在最初几周里告诉了我们什么。
两个工具，两个问题
Grafana 回答的问题是：机器人在做什么？机器人和 API 向 Prometheus 上报指标（请求、响应时间、错误率、Discord 的响应、AI 使用情况），日志则进入 Loki。每个服务器节点都有自己的一套，Grafana 只能通过私有网络访问，无法从互联网访问。
PostHog 回答的问题是：人们在我们的网站上体验到了什么？页面浏览、浏览器错误、加载时间，以及在获得同意的情况下录制的会话。PostHog 只会在你于 Cookie 横幅中同意后才启动。
这种划分是刻意的。Grafana 看机器，PostHog 看界面。把两者塞进一个工具，要么服务器日志里出现用户数据，要么产品分析里出现服务器负载。
它发现了什么
一个制造了一半流量的循环
带结束时间的投票由一个后台任务关闭，它每分钟检查一次是否有投票到期。它对每个服务器单独执行这一检查。每个分片大约 1000 个服务器，共四个分片，加起来约为每秒 70 个请求，几乎全部回答“没有到期的”。
我们是在 Grafana 中按路径拆分机器人发往 API 的请求后才注意到的：这一个端点占了全部流量的一半以上。一切都正常运行。它只是承担着一份没人要求的负载。
现在，每个分片每分钟只问一次：“到底哪些服务器有已到期的投票？”然后只为这些服务器获取详情。每分钟大约 4200 个请求变成了大约四个。
三百万次“未设置”
同样的模式，不同的地方：多个模块（支持记录、请假、团队列表、机器人统计、新闻通讯）在其循环中定期读取每个服务器的设置。在大多数服务器上，某个模块根本没有设置，所以回答是“未找到”。每天大约三百万次。
修复方法平淡无奇：现在“未设置”会被记住 30 分钟。这之所以安全，只是因为这些模块中的每一个在网页面板中保存时都会立即向机器人发送更新，所以设置一个模块永远不需要等待 30 分钟。
Discord 的故障不是我们的 bug
我们团队的错误频道会把每个失败的操作都作为“Runtime Error”发布，附带唯一引用等一应俱全。这也包括 Discord 自身返回服务器错误的时刻。这既不是我们的 bug，也不是我们能修复的东西，但它出现在频道里，看起来和真正的缺陷一模一样。
如今它被记录为警告，成员会被告知几秒后再试，而不是收到提交 bug 报告的链接。一个一半消息都不是错误的错误频道，终究会没人去看。然后你就会错过真正的那个。
一次持续了一分钟的攻击
九月底的一个下午，我们的首页在一分钟内收到了 50 多万个请求，同时来自许多国家。其中大部分在到达我们的服务器之前就被拦截了，一分钟后流量恢复正常。
我们看到它，并不是因为什么东西宕机了。我们看到它，是因为这个数字与图表的其余部分格格不入。这才是监控真正的工作：不是在一切都着火时拉响警报，而是指出哪里与平常不符。
我们的监控刻意不看什么
这里的规则和仪表盘一样重要：
- 日志中没有访客 IP 地址。 我们的隐私政策承诺了这一点，所以我们在两个地方删除它们：写入访问日志时，以及存储之前再删除一次。
- 指标中没有服务器、用户或消息 ID。 每个指标只按粗粒度属性（模块、状态类别、分片）拆分。这既保护了数据，也让指标数据库保持精简。
- 会话录制显示的是我们的界面，而不是你的内容。 只有与我们翻译文件中的文本一字不差的内容才保持可读。服务器、频道和用户名称、输入内容和预览都会被遮盖。如果允许文本的列表无法加载，所有内容都会被遮盖。
- 网站上的一切都只在同意之后。 这也意味着那里的数字只是下限。要了解真实的页面访问量，我们会查看网络服务商提供的匿名总数。
详情见隐私政策。
我们从中学到了什么
代价高的东西很少是坏掉的东西。 上面的发现没有一个产生错误。它们产生的是负载、成本和噪音，不做测量，这些你一样都看不到。
按服务器逐个询问无法扩展。 两个重大发现都是同一种模式：一个遍历每个服务器、逐个询问的循环。答案几乎总是同一个问题，对所有服务器只问一次。
警报必须罕见，否则就不算警报。 这就是为什么只有 Grafana 会通知团队，而且只针对需要有人介入的情况。来自 PostHog 的新错误类型会进入频道，但不会提醒任何人。