同一个问题跑五次，得到三种不同的结果 九月初用户反馈我们的运维 Agent 有时会给出错误的重启建议——明明是磁盘满了，它建议重启服务。我们拿到 session ID 去复现，同一个问题、同一份上下文，跑了五次： 次数 结论 步数 耗时 token 1 磁盘满，建议清理日志（正确） 4 18s 21
LLM 进了核心链路，黑盒就太危险 工单助手上线后，运营反馈"有时候答非所问"。但 LLM 调用对我们来说是个黑盒：不知道每次花了多少 token、耗时多少、模型返回了啥。更糟的是出了错没法归因。我参照传统可观测性，给 LLM 调用也接上了 Trace、Token 统计和效果评估三件套，才算把这层黑
三套系统各看各的 故障复盘最头疼的是：告警在 Prometheus 里，调用链在 SkyWalking，日志在 ELK，三套 ID 对不上，定位一个问题要在三个系统间反复横跳。有次一个下单超时，我在 SkyWalking 看到 span 慢，却没法直接拿到那次请求的日志，只能靠时间戳去 ELK 捞，
背景：一次排查花了三个小时 六月一次线上下单失败，从接到告警到定位根因花了三个小时。不是问题复杂，是信息散——日志在 ELK、指标在 Prometheus、链路在 SkyWalking，三套系统各看各的，人肉拼不出完整画面。那周我推动了可观测性体系重构，把三大支柱真正串起来。 三大支柱：日志、指标、
排查一次下单失败，登了 7 台机器 4 月初有用户反馈下单失败，报错是"系统繁忙"。这个接口要经过 7 个服务：网关 → 订单 → 库存 → 价格 → 风控 → 优惠券 → 支付。 我们的排查方式是：先猜可能是哪个服务，登录它的机器 grep 日志，找不到就换下一个。那天从晚上八点查到十点半，最后在
