Dashboard 和 Alert 走到尽头，可观测性正在被 AI 接管

传统可观测性的问题

行业经历了三段演进：instrumentation（插桩）→ data platform（数据平台）→ intelligence（智能）。NRDB 这一代解决了"任意规模、任意查询"的问题，让你能问那些原本不知道该问的问题。但十年过去，dashboard 的本质没变：90 年代是 Tcl/Tk 画 CPU/内存，今天是 NRQL 画 300 张图，"区别只是从 3 个图变成了 300 个图"。

核心矛盾：没有任何一个 dashboard 小到可以让你"看见一切"。数据多到你不知道该问什么，更不用提配置覆盖所有故障模式的 alert 规则。

而 alert 这条路也已经死循环了：

每次复盘的结论永远是"下次给 xxx 加更多 alert"，几年下来"宇宙里每件事都有 alert"。
增加 alert 并不会提升响应能力，反而会训练人产生"先等一下，看它会不会自愈"的反应，噪音越多响应越慢，但团队却误以为越多越安全。
没人真心想写 alert，也没人真心想搭 dashboard，大家只想知道：系统到底怎么了。

Nic 的提法很犀利：observability 应该叫 "understandability 系统" —— 没人想"观察"，大家要的是"理解"。

AI 接管的几种姿势

Nic 把相关技术分成三层，强调一个好产品必须三者都有，而不是把所有问题塞给 OpenAI：

统计方法 —— signal analysis、baseline deviation，本质就是公式。
Machine Learning —— 动态阈值、hyperparameter 调参、抑制重复告警，撑起了过去几年的 MLOps。
Neural Networks / LLM —— 当下"AI"的真身，作为决策层去理解模式、做语义判断。

自动异常检测 / 根因分析

直接把 petabyte 级数据喂给 LLM 不现实，成本爆炸且上下文窗口（哪怕 100 万 Token）也不够装 10 亿级数据点。可行路径是 降维 pipeline：

原始数据(10亿级) → 统计方法找 anomaly → 结构化片段(万级) → LLM 做语义判断/归因

LLM 的角色被精准定位为 "总结天才" —— 干它擅长的（解释庞大系统里发生了什么），不干它不擅长的（在 PB 级原始数据上做精确计算）。

支撑根因分析还需要三样东西：海量数据输入、结构化数据（指标 ↔ 系统的对应）、空间和时间上的关联图谱（用户操作 → 服务调用 → 基础设施依赖）。

Agent 化运维与对话式查询

终极形态是 on-call 这个职位消失：检测、响应、修复都跑在机器尺度上（毫秒级而不是人类的分钟级）。具体路径：

已知模式 → 直接自动处理（rollback / 重启 / 重调度），可参考今天 Kubernetes 自愈 pod，已经"理所当然到不被当成技术"。
还不紧急 → 建 ticket。
紧急但不确定 → 才 page 人。

模糊场景（IP 耗尽、证书过期、上游异常）无法穷举写 runbook，由 reasoning system（LLM）做"这看起来和之前那个很像"的判断 来兜底。结果是大量曾经被算作 incident 的事，未来只是 log 里一行"刚发生了点事，处理完了"。

LLM 与已有 trace/log/metrics 体系的结合

反过来看，AI 系统自己也是个新的被观测对象 —— "observability for AI"。AI 的 golden signals 和传统 web 不一样：

token 使用量与成本
response 质量与用户情绪 (sentiment)
答案正确性 / 幻觉率
模型版本切换带来的语义漂移（如 Sonnet 4.5 → 4.6 后某个购买流程的回答变奇怪）

质量评估的工程做法很有意思："虚拟呼叫中心 + 主管巡视" —— 大部分请求走便宜模型，每 1000 个抽 1 个交给更贵更强的模型做 judge。语义质量在 AI 时代等价于过去的 response time / error rate。

New Relic 正在和 OpenTelemetry 社区一起把这些信号标准化，因为 AI 能力大量"API 外包"，你甚至不运行那些系统，只能依赖它们。

工程落地与挑战

成本：LLM 调用成本与数据量正相关，必须靠统计/ML 先把数据从 10 亿级降到万级再上 LLM，否则烧不起。
误报与"非确定性"：AI 输出是 non-deterministic 的，幻觉、漂移、对相同输入产生不同输出都需要专门信号去追踪。
解释性：reasoning system 给出的"这跟那个像"必须能被工程师审计，否则自动 rollback 反而引入新的 incident。
数据隐私：质量评估涉及把生产数据发给外部 judge 模型，厂商目前更倾向"给工具不替你做"。
OpsTeam 协作变形：runbook 自动化让 SRE 从"救火"转成"定义可定义部分 + 监督模糊部分"，on-call 形态会被结构性改写。
总工作量并不会减少：AI 让单人产出变多，于是组织顺势让你做更难的事。Nic 的判断很冷："历史上从来没有哪次技术进步让人类真的减少工作量。"

案例与厂商动作

New Relic 自己的演进主线：NRDB（数据平台）→ Intelligence 层 → Action 层；AI monitoring 从自家 agent 迁到 OpenTelemetry + GenAI 标准。
OpenTelemetry 社区 正在把 AI 的 golden signals 标准化，让新框架"出生即可观测"。
Kubernetes / container orchestrator 被反复点名为"自愈自动化"的最佳现存模板，作为 AIOps 的近端基线。
OpenAI / Anthropic / Gemini 被定位为"决策层"，但厂商强调不要把所有问题外包给它们，传统 ML 和统计在很多场景仍然更合适。

文中没有提到 Datadog / Honeycomb / Grafana 或国产厂商，但 Nic 的方法论（降维 + 多模型 judge + golden signals 标准化）和这几家公开的产品方向是一致的。

我的判断

站在 PC 前端 + 全栈工程化视角，泼几盆冷水：

"on-call 消失"是营销话术，"toil 重新定义"才是真趋势。 真正会被自动化掉的是已经能写 runbook 的部分（重启、扩容、回滚），这部分 Kubernetes 时代就在做。LLM 的边际增量是把"模糊场景归类"这一步做掉，但 reasoning 错了谁背锅、自动 rollback 引发的次生事故怎么 observe，文章没回答 —— 这恰恰是落地最大的坑。
"dashboard 走到尽头"言过其实，对前端尤其如此。 后端可观测性数据是机器看的没错，但前端可观测性（RUM、Core Web Vitals、用户路径、AB 实验）天然是给人看的，因为决策者是产品经理和设计师，他们要的是图不是 Agent 对话。"AI 总结 + 人看图"会长期共存，别被"Agent 接管一切"忽悠掉自己的 dashboard 工程能力。
降维 pipeline（统计 → ML → LLM）才是工程上真正可落地的范式。 这条对前端业务监控直接可用：sentry / 自建监控里先用 z-score / 同环比这类廉价方法捞 anomaly，再把结构化片段（错误堆栈聚合 + 业务上下文）喂给 LLM 做归因摘要。别一上来就 RAG 全量日志，那是给老板演 demo 用的，不是给自己用的。
"业务指标才是 source of truth"这条最值钱。 那个办公室电视只显示"每分钟销售额"的故事，是整篇里最反 AI 炒作的判断。前端工程师的启示：别只盯白屏率和 JS 错误数，把核心业务转化漏斗接入同一套监控，AI 归因才有锚点。否则你做出来的是"高级 dashboard"，不是 understandability。
"observability for AI"对前端的具体启示：把 LLM 调用当成新的"外部依赖"对待。 Prompt 版本、模型版本、token 成本、回答相似度漂移，都应该像 API 错误率一样进监控埋点。前端如果要做 AI 功能（智能搜索、对话式 UI、AI 表单填充），不建立这套，上线第二周就会被 PM 追着问"为什么用户说回答变蠢了"——而你查不出来。

一句话总结：方向对（理解 > 观察、降维 > 全量喂 LLM、业务指标 > 系统指标），但"AI 接管"目前仍是叙事，前端别盲目跟 SRE 厂商打鸡血，先把自家业务监控的 source of truth 收敛清楚，再谈让 Agent 接管。