<a></a>
定義：消息軌迹指的是一條消息從生産方發出到消費方消費處理，整個過程中的各個相關節點的時間地點等資料彙聚而成的完整鍊路資訊。
基本思路：從mq系統中，一條消息的完整鍊路包含生産方，服務方，消費方三個角色，每個角色處理消息的過程中都會在軌迹鍊路中增加相關的資訊，将這些資訊彙聚即可擷取任意消息目前的狀态，進而為生産環境中的問題排查提供強有力的資訊支援。
消息軌迹的資料包含：
發送方資訊：
發送方用戶端資訊
發送時間
發送成功與否
發送耗時
…
服務方資訊：
消息存儲位置
消息存儲時間
消息本身的屬性
接收方資訊：
接收方用戶端資訊
投遞資訊（第幾次投遞，投遞時間）
消費成功與否
消費耗時
消息軌迹功能一般在生産環境的消息收發不符合預期時排查問題使用。通過消息的一些屬性（messageid，messagekey，topic）搜尋相關的消息軌迹，找到關心的消息的實際收發狀态，幫助診斷問題。
消息軌迹的使用方場景：
消息軌迹的使用對于業務方不會增加額外的接入成本，僅僅需要確定用戶端sdk版本支援該特性。正常收發消息後以消息的相關屬性在mq控制台上查詢即可。
登入mq控制台，點選消息軌迹功能（現處于公測階段），點選右上角建立查詢按鈕。
消息軌迹查詢功能支援三種查詢方式，請按照對應方式輸入查詢條件，建立查詢。
根據messageid查詢：需要輸入消息的唯一messageid，topic名稱以及消息的大緻發送時間。
根據messagekey查詢：需要輸入消息的messagekey和topic以及大緻發送時間，适用于沒有記錄messageid，但記錄了messagekey的場景。
根據topic查詢：僅僅輸入topic和時間段，批量查詢，适用于沒有上述messageid和messagekey，而且消息量比較小的場景。
注意：
查詢時，盡可能設定最為精确的時間區間，以便縮小查詢範圍，提高速度。
根據msgid查詢屬于精确查詢，速度快，精确比對，推薦使用者使用。
根據msgkey查詢屬于模糊查詢，僅适用于業務方沒有記錄messageid但是設定了messagekey，同時messagekey具有區分度的情況，messagekey查詢最多查詢1000條軌迹。
根據topic分段查詢屬于範圍查詢，不推薦使用，因為時間範圍内消息很多，不具備區分度。
建立查詢後，會生成一個查詢任務，mq背景會異步執行，并将任務狀态回報到管理頁面，查詢結束時，任務狀态顯示查詢完成，否則顯示查詢中。
根據任務的狀态可以選擇檢視軌迹，或者删除查詢任務。
點選檢視軌迹按鈕，檢視軌迹，如果發現沒有結果，請參考彈窗連結，排查原因。
如果查詢到軌迹資訊，可以看到軌迹的簡要資訊，主要是消息本身的屬性以及接收狀态的統計，如下圖所示：
點選檢視軌迹按鈕即可檢視完整的鍊路圖，如圖所示：
消息鍊路圖包含4個部分：
生産者資訊
topic資訊
消費者資訊
詳情資訊
各個字段區域均可以通過滑鼠懸停的方式擷取詳細資訊。對于msgkey和topic查詢方式，如果比對到多條軌迹，可以進行上下翻頁，檢視比對軌迹資料。
消息軌迹查詢頁面中涉及到的名詞概念清單如下。
相關概念
含義
發送成功
消息發送成功
發送失敗
消息發送失敗
消息定時中
該消息是定時或者延時消息，且尚未到達投遞時間
事務未送出
該消息是事務消息，且尚未送出狀态
事務復原
該消息是事務消息，并且已經復原
全部成功
該消息所有投遞都已成功消費
部分成功
該消息投遞中存在消費失敗并重試成功的情況
尚未消費
該消息尚未投遞給任何消費方
記錄消息從發送端發送時的用戶端時間戳
記錄發送端調用send方法發送消息的毫秒耗時
region
記錄消息存儲的region資訊，或者消費方機器所在的region資訊
記錄消息推送到用戶端之後執行consumemessage方法的耗時
投遞時間
記錄用戶端執行consumemessage方法開始消費消息時的時間戳
本部分文檔介紹消息軌迹的一些使用案例，推薦使用者參考以下的場景，利用消息軌迹來排查mq問題。
業務方如果根據業務日志裡的資訊判斷某條消息一直沒有沒有收到，此時可以使用消息軌迹工具來确認該情況。
step1：收集懷疑的消息的資訊，messageid,messagekey，topic以及大概的發送時間範圍。
step2：進入mq控制台，根據已有的資訊建立查詢任務，查詢相關的消息的軌迹。
step3：檢視結果。并分析判斷原因，如果軌迹顯示尚未消費，則可以去訂閱管理頁面查詢，确認是否有堆積導緻消息尚未消費。
step4：如果發現已經消費，請根據消費端的資訊，找到對應的用戶端機器和時間，登入檢視相關日志。