可观测性 on Tony老师的博客

Agent 可观测性：日志、Trace 与 Replay 调试

Sun, 12 Oct 2025 10:00:00 +0800

LLM Agent 在生产环境出问题时的第一反应是什么？看 log？不够。看 metrics？不够。看 prompt？没用。你需要的是完整的 trace 重放——从用户输入到最终输出，每一步 LLM 调用、每个工具调用、每个决策点的中间结果。

传统微服务的 observability（metrics / logs / traces）已经成熟。但 LLM Agent 的可观测性是另一回事：

同样的输入可能产生不同输出——随机性是基本属性
每一步都是 LLM 调用——成本不只是延迟
失败原因多样——模型幻觉、工具报错、context 超限、用户指令歧义
难以重现——不同时间的模型版本可能给出不同结果

这篇文章讲怎么搭一套真正能 debug LLM Agent的可观测性体系。

Go 语言 Goroutine 泄露：实战案例分析与排查指南

Sat, 01 Mar 2025 10:00:00 +0800

在 Go 语言开发中，Goroutine 泄露是一个非常隐蔽但致命的问题。它通常发生在一个 Goroutine 被启动后，因为某种逻辑阻塞（比如等待一个永远不会关闭的 Channel 或获取不到锁）而永远无法结束，导致内存逐渐耗尽。

和内存泄漏不同，Goroutine 泄露更难发现——因为 Goroutine 本身占用很小（通常只有几 KB），但成千上万个泄露的 Goroutine 会形成"蚂蚁搬家"效应，最终拖垮整个服务。

本文将分享 4 个实战中非常典型的 Goroutine 泄露案例，并提供排查工具和预防原则。

《SRE：Google 运维解密》读书笔记：错误预算与事后总结

Wed, 25 Sep 2024 10:00:00 +0800

上一篇（《SRE》读书笔记：SLI 与 SLO）聊了 SLI/SLO 的概念，这篇继续聊 SRE 的另外两个核心实践：错误预算（Error Budget） 和 事后总结（Postmortem）。这两个实践一起，把"故障"从追责对象变成了改进机会。

《SRE：Google 运维解密》读书笔记：SLI 与 SLO

Thu, 30 Nov 2023 10:00:00 +0800

Google 的 SRE 团队在 2016 年公开了《Site Reliability Engineering》（《SRE：Google 运维解密》），这本书影响了过去十年整个互联网行业的运维实践。它的核心思想是用工程化的方法解决可靠性问题，而不是用"运维人员加班"。

这一篇主要聊聊 SLI/SLO 这两个核心概念。

OpenTelemetry 工程化：从 SDK 到 Collector 的全链路落地

Mon, 15 Aug 2022 16:00:00 +0800

2022 年初我们还在用 Jaeger SDK + Prometheus client + Loki SDK 三套独立可观测体系。每个语言栈要维护三套埋点，新人入职第一周基本都在学"哪段代码要插哪个探针"。那年 6 月我们启动 OpenTelemetry 迁移 —— 不是为了追新，而是因为"统一"已经压过"性能"和"习惯"。

OpenTelemetry（OTel）不是某个产品，而是一套 规范 + SDK + 协议 + 工具 的总和。它在 2021 年 2 月发布 Tracing 1.0 GA，2021 年 CNCF 进入 Incubating，已经成为云原生可观测的事实标准。本文从三大信号、SDK 设计、Collector 架构、采样策略四个维度，给出生产级落地的工程经验。

Prometheus 监控体系：从零搭建生产级

Sun, 08 Aug 2021 14:00:00 +0800

一套生产级 Prometheus 监控体系，绝不只是"跑起来一个 Prometheus 进程 + 配个 Grafana 面板"那么简单。从 2017 年 Prometheus 2.0 GA 至今，它的存储引擎、查询语言、生态工具链经历了数代演进。一个新项目如果按"开箱即用 demo"的认知去部署，三个月内几乎必然会在指标基数、告警风暴、长存储三件事上踩坑。

本文按"架构 → 数据采集 → 存储与查询 → 告警 → 高可用 → 落地清单"六个层次展开。

可观测性三大支柱：Metrics、Logs、Traces 的工程落地

Mon, 15 Mar 2021 10:00:00 +0800

2017 年 Pinterest 工程团队在 SREcon 上分享其监控平台 Bender 时展示过一组数字：单业务域的时序指标规模动辄上万，传统告警体系面对每天数百条告警已经疲于奔命，但工程师真正关心的"这个请求为什么慢"却往往无解。那个时刻暴露了一个被广泛忽视的事实——传统监控（Monitoring）解决的是"系统是否在运行"，而真正想回答"系统为什么这样运行"，需要的是可观测性（Observability）。

监控与可观测性不是同义词。监控是一组预定义的仪表盘和告警规则，依赖"已知未知"——你必须先想象故障形态。可观测性是一套能从系统外部行为反推内部状态的能力，依赖"未知未知"——即使面对从未发生过的故障，也能从足够丰富的遥测数据中推断根因。

context 与 goroutine 泄漏：取消信号如何穿过调用链

Tue, 20 Aug 2019 10:00:00 +0800

2018 年我们在线上遇到过一次奇怪的故障：服务平稳运行六小时后，HTTP 接口开始出现零星超时；八小时后超时雪崩，pprof 显示 goroutine 数从启动时的 80 涨到 47 万。内存没爆，CPU 没满，唯一异常是 goroutine 数量。重启后一切恢复，但同样的故事第二天又演了一遍。

最终定位是一个 HTTP handler 里启动了后台 goroutine，handler 提前超时返回后，这些 goroutine 没人通知它们退出，全部卡在 ch <- result 的发送上。每个超时请求泄漏一个 goroutine，撑爆了运行时调度。

goroutine 泄漏和内存泄漏不一样。它不会立刻爆掉，而是悄悄吃掉内存、句柄、连接，最终在高峰期把系统打穿。这篇文章想讲清楚：泄漏的常见形态、为什么 context 是它的标准解药、context 内部怎么把取消信号自上而下广播，以及怎么定位一个已经泄漏的现场。