开源点评CAT使用问题经验分享

目前公司应用美团CAT的时候遇到的一些问题总结并且分享一下，有的是配置问题，有的是使用问题，给大家列出来给遇到问题的小伙伴一些排查的思路.

问题列表：

1. Sorry, the message is not there. It could be missing or archived.

1. 之前写的排查文章，不过版本升级已经修复了。
2. 可能和客户端的本地队列满了有关系，这里可以从CAT的心跳[hearbeat]报表里面去查看，主要指标名称是: client-send-queue Info

这里需要注意的是CAT默认的本地客户端队列是5000，超过这个阀值的话，会出现将消息日志丢弃的情况。这里可以根据实际情况进行评估。

3. 查看本地消息文件是否被清理掉了,CAT服务端默认是15天，在配置[config]模块，【全局系统配置】-【服务端配置】-

• [local-logivew-storage-time] 本地Log日志存储天数
• [local-report-storage-time] : 本地报表日志存储天数
• [max-hdfs-storage-time] : hdfs存储log日志的天数

这里要注意的是，即便你是用的本地存储LogView，也请配置好max-hdfs-storage-time ，因为这个参数在查询LogView会使用到，请和local-logivew-storage-time保持一致;

4. 这个也可能和第二点有关，当客户端本地队列积攒一定数据的时候，消费比较慢，刚好跨小时了，这个时候服务端会有个逻辑就是非当前小时，上个小时的数据会丢掉；这个可以从state报表的网络传输或者客户端延迟发送导致消息丢失看到，当然报表中也涵盖了一些其他的；
   • 两台机器时钟不准导致消息存储丢失
   • 丢失消息总量

当然这些指标有一定参考因素，但是如果客户端队列已经出现网络传输慢或者消息堆积开始丢弃消息了，可能心跳数据都发送不过来就丢弃了；

2. 消息内容和实际内容不一致

比如你这个消息编号的内容是A接口的，但是根据消息编号去LogView查看时发现是另一个B接口的，不相关的串联；

我们这边排查的可能发现消息编号是: default-ac13bda0-450615-21
default代表不确定的应用名称,内部封装调用的是
com.dianping.cat.Cat#logRemoteCallClient(com.dianping.cat.Cat.Context)
方法；

可能产生的场景就是: A 和 B (远程调用OR其他)都是用了default作为应用前缀，又是在同一台机器上面同一个小时，从消息id设计的前3段来讲已经是重复的了，最后一段根据消息递增必然会发生冲撞；导致消息内容被覆盖；

解决的方案也很简单，换另一个API
com.dianping.cat.Cat#logRemoteCallClient(com.dianping.cat.Cat.Context, java.lang.String)

// 是用类似的方式在本地生成消息编号带到下游去进行串联;
Cat.logRemoteCallClient(context,Cat.getManager().getDomain());

另外还有一种情况就是发送消息队列的时候:
当我们发送一个远程消息的时候，CAT的逻辑是本地生成好3个消息：

1. ROOT LOG ID
2. PARENT LOG ID
3. LOG ID

这个都是客户端先生成好，然后再带到下游去的服务去串联这些消息。
但是消息队列的场景并不好做;

• 因为它不确定下游是谁，
• 也不确定下游是多少个；

就导致A发送一条消息，即便消息中涵盖了三个消息编号，但是下游后 消费的消费者会覆盖上一个消费者的情况；

这种方式的话不是很好解决，我们这边的解决方式是：

1. 构建一套搜索系统，负责根据参数内容搜索；
2. 基于消息发送的下游不应用上游的LOG ID，而是本地新生成一个消息编号；这样的话从上游找不到下游，但是从下游可以找到上游；

各自抉择吧…

有问题留言交流…