我先分享下我们小厂是怎么玩的
所有服务节点都接了 pinponit ，然后结合 kibana 收集的线上日志+traceid
分享几张今天新鲜出炉的 bug 图

今天发现根据这个 pp 的日志就很快定位到有查全表的场！

小厂未必用得上你的这么高级的工具。分析办法全靠经历事故来积累经验

日志收集 + 监控，剩下的全靠个人经验了

printf

大佬啊

小公司 tail -f xxx.log 啊

sentry

后端就是靠 TraceId 看链路+日志上报
web 就是看 JS 堆栈+日志上报来分析

23333 ，在全球五百强。 我们现在都没用上你这一套东西。

推荐之前看到的一篇文章 线上故障应急处理：4 年多 on call 经验总结，虽然不是什么具体的工具，但感觉思路还是可以的。

好

好，晚点我也去看下

我去，怎么多了个空格，线上故障应急处理：4 年多 on call 经验总结

skywalking

var_dump();die; phper 就是任性

tail -f xxxx | xargs grep xxx

以前写 ruby ，都是直接生产 rails console 执行代码调试🤣主打一个胆大心细

kibana + trace_id 搜就行了，没空搞这些花里胡哨的，开发自己用的工具不算 KPI ，能用就行，懒得搞

我们都是 tail -f 大法

大盘监控 + 链路追踪 + 查日志。

tail -f, grep 😂

哦不对，我们不是大厂

splunk

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

监控+指标+数据+日志

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

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

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

小厂，先大致确定问题服务是哪组，开发查日志，问题严重需要联系运营找群里论坛里看有没有用户发复现操作，测试尝试复现。
拿到大致复现逻辑或者可能根本无法复现的，运维切备用线路，也可能问题太大先切，看运维和运营把控。
如果没有备用线路，看情况问运营争取关掉外网网关一段时间。至于该不该有备用是事后开会讨论的事。
如果日志查不出来就再拿其他工具分析旁路分析 tcpdump ，proc, gstack ，实在不行就找写这部分代码的开发一起调试吧，反正用户已经切备用线路了。
动态语言可以上一些 console ，或者一些内部接口实现一些简单的 runtime script ，例如动态读取一个脚本文件 or 语句执行
静态语言例如 c++就 ci 再 build 个 RelWithDebInfo ，该调试调试，该 dump 就 dump

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

vim 20250430.log
/errorText (回车)

找吧就...

多说无益，先摇人。

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

太高级了，看不懂（

直接腾讯云低频 CLS 不香么

跟着赶脚走

就我自己用 frebase 么。。。

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