从40秒到10秒以内：在Kubernetes上基于OpenTelemetry、Apache Kafka和Apache Flink重建事件检测平台
内容提要
Atlassian团队用Kafka、Flink和OpenTelemetry重建自动事件检测平台AutoHOT，将事件到指标延迟从40秒降至10秒内，月成本从2万美元降至650美元。检测召回率从60%升至86%后回落至64%，精确率仍不理想。关键教训：召回率反映检测器质量，覆盖率取决于埋点选择，二者不可混淆；客户端遥测无法发现数据库宕机等沉默故障。
延伸解读
召回率与覆盖率：两个必须分开看的指标
文章反复强调，召回率反映检测器质量，覆盖率取决于埋点选择。Atlassian的in-scope召回率从60%提升到86%，但整体覆盖率并未改善：在263起重大事件中，仅44.5%落在已埋点的体验上，最终自动检测到的只占全部重大事件的30.4%。这意味着即使检测器完美，也只能覆盖不到一半的事件。团队曾把召回率当作覆盖率来庆祝，这是需要警惕的认知陷阱。
沉默故障：客户端遥测的盲区
客户端遥测只在页面加载时产生数据，因此数据库分片硬宕机或上游事件管道停滞时，系统看到的是“沉默”而非错误。文章指出，两个最严重的漏报都源于此：一个数据库分片宕机，一个自身管道停滞。修复手段包括流量下降检测、遥测新鲜度检查，以及引入边缘5xx率和合成探针等非客户端信号。任何只寻找失败的设计都会把沉默误读为健康。
成本与延迟的权衡：从40秒到10秒的代价
重建后事件到指标延迟从40秒以上降至10秒内，月成本从约2万美元降至650美元，计算资源从约90台虚拟机缩减到4个Kubernetes Pod。但文章也坦承，指标是至少一次语义，重启会导致2-3分钟的数据低谷和回放高峰；检测器读取预聚合存储而非原始计数器，因此接受了这一权衡。成本下降主要来自让总线做过滤、用HyperLogLog替代用户ID以及幂等写入设计。
精确率是一组数字，而非单一指标
文章指出，精确率因范围而异：核心产品覆盖范围内约90%，但包含低严重性早期预警的所有自动工单在2026年2月为79%、3月为68%。被拒绝的工单中48%是流程和记录问题，26%是低于事件门槛的真实信号，16%是监控错误。团队通过120秒最小延迟、模糊抑制和强制记录拒绝原因来提升精确率，并强调调优时必须区分“自动恢复”“维护窗口”和“误报”，否则会调错方向。
Q&A
Atlassian 重建 AutoHOT 事件检测平台后，延迟和成本具体改善了多少？
事件到指标延迟从超过40秒降至10秒以内；月度运行成本从约2万美元降至约650美元，降低约97%。
为什么客户端遥测无法检测数据库宕机等沉默故障？
客户端遥测只在页面加载时产生事件。数据库分片硬宕机时没有页面加载，也就没有事件，系统看到的是沉默而非错误。只检测失败的设计会把沉默误读为健康。
AutoHOT 的 Flink 作业如何保证重放时不重复计数？
使用幂等写入：键值存储的键由（产品、日、小时、作业）加上（窗口、租户、子产品、体验）组成，重放主题会重写相同的行；Parquet 文件在检查点时滚动，实现精确一次。
AutoHOT 如何计算跨维度的去重影响用户数？
使用 HyperLogLog 草图。每个60秒窗口携带 HLL 草图，Impact API 在读取时对草图做并集，支持按任意分组（分钟、租户、分片、区域）合并去重，避免逐行求和导致的双重计数。
AutoHOT 的检测召回率和覆盖率表现如何？
范围内召回率从约60%升至峰值86%，后回落至64%。但整体覆盖率未提升：2025年11月至2026年7月的263起重大事件中，仅44.5%落在已埋点体验上，检测到80起，占全部重大事件的30.4%。召回率反映检测器质量，覆盖率取决于埋点选择。
AutoHOT 的精确率表现如何？被拒绝的工单主要原因是什么？
精确率因范围而异：核心产品覆盖范围内约90%；所有自动创建工单（含低严重性预警）2026年2月为79%，3月为68%。2026年1月至8月被拒绝的工单中，48%是流程和记录问题（过期、重复、未记录原因），26%是低于事件门槛的真实信号，16%是监控错误，11%原因在服务之外。
AutoHOT 在架构设计上有哪些关键教训？
关键教训包括：在总线层过滤而非作业内过滤；先设计 sink 键再设计拓扑；使用草图而非 ID 做可合并去重；将算子 UID 和自动扩缩容设置视为生产配置；分别报告召回率和覆盖率；用 OpenTelemetry 和合成检查监控检测器本身；对沉默故障保持诚实，需搭配非客户端信号。
