RocketMQ 消息軌跡主要包含兩篇文章：設計篇與源碼分析篇，本節將詳細介紹RocketMQ消息軌跡-設計相關。
RocketMQ消息軌跡，主要跟蹤消息發送、消息消費的軌跡，即詳細記錄消息各個處理環節的日誌，從設計上至少需要解決如下三個核心問題：
消費軌跡數據格式記錄消息軌跡(消息日誌)消息軌跡數據存儲在哪？1、消息軌跡數據格式
RocketMQ4.5版本消息軌跡主要記錄如下信息：
traceType跟蹤類型，可選值：Pub(消息發送)、SubBefore(消息拉取到客戶端，執行業務定義的消費邏輯之前)、SubAfter(消費後)。timeStamp當前時間戳。regionIdbroker所在的區域ID，取自BrokerConfig#regionId。groupName組名稱，traceType為Pub時為生產者組的名稱；如果traceType為subBefore或subAfter時為消費組名稱。requestIdtraceType為subBefore、subAfter時使用，消費端的請求Id。topic消息主題。msgId消息唯一ID。tags消息tag。keys消息索引key，根據該key可快速檢索消息。storeHost跟蹤類型為PUB時為存儲該消息的Broker伺服器IP；跟蹤類型為subBefore、subAfter時為消費者IP。bodyLength消息體的長度。costTime耗時。msgType消息的類型，可選值：Normal_Msg(普通消息),Trans_Msg_Half(預提交消息),Trans_msg_Commit(提交消息),Delay_Msg(延遲消息)。offsetMsgId消息偏移量ID,該ID中包含了broker的ip以及偏移量。success是發送成功。contextCode消費狀態碼，可選值：SUCCESS,TIME_OUT,EXCEPTION,RETURNNULL,FAILED。2、記錄消息軌跡
消息中間件的兩大核心主題：消息發送、消息消費，其核心載體就是消息，消息軌跡（消息的流轉）主要是記錄消息是何時發送到哪臺Broker，發送耗時多少時間，在什麼是被哪個消費者消費。記錄消息的軌跡主要是集中在消息發送前後、消息消費前後，可以通過RokcetMQ的Hook機制。通過如下兩個接口來定義鉤子函數。
通過實行上述兩個接口，可以實現在消息發送、消息消費前後記錄消息軌跡，為了不明顯增加消息發送與消息消費的時延，記錄消息軌跡最好使用異步發送模式。
3、如何存儲消息軌跡數據
消息軌跡需要存儲什麼消息以及在什麼時候記錄消息軌跡的問題都以及解決，那接下來就得思考將消息軌跡存儲在哪裡？存儲在資料庫中或其他媒介中，都會加重消息中間件，使其依賴外部組件，最佳的選擇還是存儲在Broker伺服器中，將消息軌跡數據也當成一條消息存儲到Broker伺服器。
既然把消息軌跡當成消息存儲在Broker伺服器，那存儲消息軌跡的Topic如何確定呢？RocketMQ提供了兩種方法來定義消息軌跡的Topic。
系統默認Topic如果Broker的traceTopicEnable配置設置為true，表示在該Broker上創建topic名為：RMQ_SYS_TRACE_TOPIC，隊列個數為1，默認該值為false，表示該Broker不承載系統自定義用於存儲消息軌跡的topic。自定義Topic在創建消息生產者或消息消費者時，可以通過參數自定義用於記錄消息軌跡的Topic名稱，不過要注意的是，rokcetmq控制臺(rocketmq-console)中只支持配置一個消息軌跡Topic，故自定義Topic，在目前這個階段或許還不是一個最佳實踐，建議使用系統默認的Topic即可。通常為了避免消息軌跡的數據與正常的業務數據混合在一起，官方建議，在Broker集群中，新增加一臺機器，只在這臺機器上開啟消息軌跡跟蹤，這樣該集群內的消息軌跡數據只會發送到這一臺Broker伺服器上，並不會增加集群內原先業務Broker的負載壓力。