有些 bug 找不到原因怎么办

[751327]

做业务系统的，经常有 bug，要是能复现的话，99.9%都能定位到原因；经常有些偶发的问题，涉及到的链路特别长（ a 服务 -> b 服务 -> ...K 服务），很难确定具体是哪个部分有问题，关键也不熟悉各个服务的代码，查问题只能通过 kibana 上面的日志寻找线索，你们是怎么处理这类问题呢？

[9yu]

问熟悉服务的人啊，自己解决不了的问题就不要自己解决。

[kop1989]

只能各个业务单独输出日志，记录输入和输出。这样下次再出现就能判断出问题在哪。
偶发说明不是计算问题，所以优先排查涉及逻辑的模块，比如异步、队列、事务等。

[Leigg]

当前服务在返回错误时一定要打日志

[751327]

@Leigg 关键是没有报错的那种，有报错就好解决了

[zarte]

有预生产环境么？

[gggyyybbb]

pinpoint 了解一下

[freakxx]

你先把握住大概流程，比如你说的 a --> b --> c --> d

你先缩小出现问题的地方。
比如直接去掉你熟悉的 a 和 d （按你描述，你一般在上游或者下游），你那么就只需要排查 b 和 c 。

然后你就看 c 入口的日志，没反应的话， 再看 b 入口和模块日志。


=================
至于偶发的问题，这个我觉得是挺悖论的。。。
你在这个发生的地方，拿着它去上游回溯或者看下参数到这里是怎么转变，还是可以排查

[751327]

@gggyyybbb 我研究研究

[751327]

@zarte 很多环境，灰度 -> 预发 -> 线上

[751327]

@freakxx 业务系统一大问题就是调用链特别长，太多地方需要打日志了

[751327]

@freakxx 不是每个模块都有这么多的日志

[751327]

@gggyyybbb 请教下，这个东西生产环境用的多吗，性能怎么样

[freakxx]

@751327 #11

我思路在于，
我没想过能直接定位到问题在哪，
思维也类似二分法来处理

日志也不需要详尽，你只需要有入口和出口就可以，
你配个 nginx 也有个基本日志，你就看有没进去和出来，

排到具体模块打 log，直接 print 都可以，再来排查看具体在哪里有问题。

[751327]

@freakxx 目前就是这样查问题的，有些请求会找运维拿 nginx 日志，不过也谢谢你

[gggyyybbb]

@751327 一般服务调用链长的就可以用类似的接口监控工具了，pinpoint 只是其中一种，底层是探针的形式，对整体系统消耗性能很低。类似的还有 skywalking，zipkin 等，你可以比较权衡下