调用链跟踪系统的首秀—查找打印配置未正确加载的bug

背景

问题

连续两天都有商家反馈无法打印，远程查看后都发现打印配置加载的有问题，以前设置好的打印机都没显示出来——显示的是 store 级别的打印配置（打印配置从store细化到entity_store后，如果请求没有entity_store_id，会去查找store级别的打印配置）。

思路

调用链跟踪系统，记录了每次api请求的url、params、返回数据、时间戳、ua、x-forwarded-for、埋点标记 等有用信息，足够我们用来回溯当时的程序运行路径，展示当时程序的部分状态。

操作

  1. 首先从庞大的日志里筛选出需要的所有调用链；
    1.1 根据商家反馈，早上从未成功打印过，我们先确定了一个较小的时间范围：从商家第一次登陆，到打印配置获取完成；
    1.2 我们先在记录里找商家store_id第一次出现的位置，再根据这条记录的ua找到了商家ip，根据此ip筛选出第一批数据，也找到了大概的时间范围；
    1.3 把所有记录复制出来，分组排序（按TraceId分组，组内按RpcId排序，组间按每组内第一条记录的At排序），方便分析；
    1.4 根据TraceId和RpcId补足中间缺失的记录（RpcId是有序的，中间缺失可以看出来）
    1.5 最终筛选出来106条记录，时间跨度约5秒，其中seller端的cash/get/lists接口产生了11个Api调用，相关记录就占了46条）；
  2. 找到“获取打印配置”这个接口的请求参数和返回值，发现接口传参不正确，获取到的数据也不正确；
  3. 结合记录和代码，推测程序运行路径，找出问题的原因。

效果

最后找出来一个bug：

check接口和返回值：


PS: 接口没返回entity_store_id，后面却使用了entity_store_id去获取打印配置。

结语

  1. 最终张跃还在js端找出一个bug：打印配置的获取 写在了 setCookie方法 前面，导致获取配置的时候没有取到ntity_store_id(所以也没传)。
  2. 打印配置的获取有三个地方：打印js加载后自动获取、doLogin时获取、checkLogin时获取，所以出bug后也只有部分商户无法打印。
  3. 调用链跟踪记录查阅起来还不是很方便，主要问题有：
    3.1 商家没有固定的身份标识，在记录里难以找出所有的商家相关记录；
    3.2 日志记录无序，还需要自己排一遍序；
    3.3 如果能像数据库一样select筛选数据更好；
  4. 针对上面的问题，分别有一些解决方法：
    4.1 在客户端里获取商家电脑的硬件信息，作为商家的身份标识；
    4.2 日志记录排好序再写到log里，可以保证组内绝对有序，组间相对有序；
    4.3 找一些开源工具。。

发表评论