開源點評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，超過這個閥值的話，會出現将消息日志丢棄的情況。這裡可以根據實際情況進行評估。

1. 檢視本地消息檔案是否被清理掉了,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保持一緻;

1. 這個也可能和第二點有關，當用戶端本地隊列積攢一定資料的時候，消費比較慢，剛好跨小時了，這個時候服務端會有個邏輯就是非目前小時，上個小時的資料會丢掉；這個可以從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，而是本地新生成一個消息編号；這樣的話從上遊找不到下遊，但是從下遊可以找到上遊；

各自抉擇吧…

有問題留言交流…