使用慢日誌排查逾時問題 -

慢請求引起的連線逾時等問題是影響Redis服務品質的常見問題，KVStore for Redis的慢日誌系統能夠協助您快速找到慢請求問題發生的位置，定位發出請求的用戶端IP，為徹底解決逾時問題提供可靠的依據。

功能簡介

Tair的慢日誌會記錄執行時間超過指定閾值的請求，慢日誌分為資料節點慢日誌和代理慢日誌。

代理慢日誌中統計的命令執行時間從代理向資料節點發出請求開始，到代理從資料節點收到相應的回複為止，包含了命令在資料節點中的執行時間、資料在網路中的傳輸時間以及命令的排隊延遲等。
代理慢日誌的保留時間為72小時，無數量限制。
由於代理慢日誌反映的延遲與您在應用端感受到的延遲更相近，在排查Tair服務逾時問題時，建議多關注此類日誌。

說明

標準架構的Tair執行個體不提供代理慢日誌。

慢日誌類型	查看方式
資料節點慢日誌	通過用戶端串連Tair執行個體，然後使用SLOWLOG GET命令查看，詳情請參見Redis Commands。通過Tair控制台或調用OpenAPI查看：查詢慢日誌（控制台） DescribeSlowLogRecords
代理慢日誌	通過Tair管理主控台或調用OpenAPI查看：查詢慢日誌（控制台） DescribeSlowLogRecords

Tair服務逾時的原因通常比較複雜，很多情況下與慢請求相關。您可以按照下述步驟來排查逾時問題。

當Tair服務出現逾時問題，首先查看代理慢日誌，詳情請參見查詢慢日誌。
說明
- 如果執行個體為標準架構，請跳轉至步驟3分析資料節點慢日誌。
- 如果代理慢日誌內容為空白，您可以排查用戶端與Redis執行個體間的網路狀況。
定位最早的代理慢日誌由哪條命令引發。
說明代理慢日誌通常是因為資料節點中出現慢請求，引起命令堆積而導致的。
本案例中，最早出現的慢日誌是由一條KEYS命令產生的。右側的IP地址即為使用這些命令的用戶端IP地址。
查看資料節點慢日誌以確認代理慢日誌中的哪些日誌引起了逾時問題。
說明通常情況下，在代理慢日誌中最先產生慢日誌的命令，也會在資料節點產生慢日誌。資料節點的慢日誌一般比代理節點慢日誌少，這與二者對執行時間的定義以及慢日誌閾值不同有關。
本案例中，查看代理慢日誌後，再對比資料節點慢日誌，發現也存在KEYS命令產生的慢日誌，且沒有出現代理慢日誌中的其它慢日誌，說明真正引起逾時即為KEYS命令產生的慢日誌。
在代理慢日誌中，根據上一步驟定位到的命令精確搜尋，可找到使用這些命令的用戶端IP，隨後進行最佳化。

參數名	說明
slowlog-log-slower-than	設定資料節點慢日誌閾值，預設為20000微秒（即20毫秒）。說明通常情況下您感知到的延遲實際會高於本參數設定的值，因為感知時間中包含了資料在用戶端、代理、資料節點之間傳輸和處理所消耗的時間。
slowlog-max-len	設定最大慢日誌條目數，預設為1024。

參數名	說明
rt_threshold_ms	設定代理慢日誌的閾值，預設為500毫秒。建議將該閾值配置為與用戶端逾時時間近似的值，推薦為200毫秒到500毫秒。