大厂的同事们，你们是怎么定位线上故障的？

splunk

就以我们公司这点微服务体量，闭着眼睛都能知道大概哪里的问题

监控+指标+数据+日志

楼上都是大佬,我们小小小公司项目发现问题,都靠客户...
客户不反馈=项目无 bug,反馈了不能复现出来,就不算问题.

我们小厂有时候要测试开发产品三方会诊才能确定这到底是 feature 还是 bug 😂

这种代码问题导致的单点故障基本上依靠基建都是非常好排查的。
稍微难一点的是上下游变更导致离变更节点非常远的地方异常，这种基本是排查时间点附近的变更并结合业务专家经验来看。
最难的是变更后很久才能发现的业务一致性问题，基本就靠人力慢慢推理了

小厂，先大致确定问题服务是哪组，开发查日志，问题严重需要联系运营找群里论坛里看有没有用户发复现操作，测试尝试复现。
拿到大致复现逻辑或者可能根本无法复现的，运维切备用线路，也可能问题太大先切，看运维和运营把控。
如果没有备用线路，看情况问运营争取关掉外网网关一段时间。至于该不该有备用是事后开会讨论的事。

如果日志查不出来就再拿其他工具分析旁路分析 tcpdump ，proc, gstack ，实在不行就找写这部分代码的开发一起调试吧，反正用户已经切备用线路了。

动态语言可以上一些 console ，或者一些内部接口实现一些简单的 runtime script ，例如动态读取一个脚本文件 or 语句执行
静态语言例如 c++就 ci 再 build 个 RelWithDebInfo ，该调试调试，该 dump 就 dump


当然上面说的运维+测试+看日志的+写这部分代码的人，可能都是你（ bushi

vim 20250430.log
/errorText (回车)

找吧就...

多说无益，先摇人。

虽然不是大厂,但也是我们公司内部开源出来的一种解决方案,实时的告警和全链路的追溯 https://github.com/GuangYiDing/exception-notify

太高级了，看不懂（

直接腾讯云低频 CLS 不香么

跟着赶脚走

就我自己用 frebase 么。。。

@0x49 反馈了不能复现， 就继续让客户反馈， 直到问题重现或者用户崩溃 😂

一般就看堆栈，异常类型，结合函数签名与功能，与最近相关改动，加上点日常经验，基本能解决 99%的问题

一般的问题就是群里监控告警，一般告警的时候会携带异常的采样，拿到 traceId 之类的去阿里云 SLS 查日志。
严重的问题就是 GOC 拉群摇人

先看大动脉有没有被裁

#24 @0x49 巧了我们也是，我们知道的 bug 不算 bug ，客户反馈的才是 bug

异常直接到群里自动分析堆栈并找到代码的提交人 at 对应的人处理并附带上全链路的日志