Memorystore for Redis 提供即時伺服器端指標,可監控總處理量、CPU 使用率和記憶體用量,但光是這些資料可能無法解釋,為何用戶端應用程式在複雜的分散式系統中會發生高延遲問題。
用戶端指標可提供完整要求-回應週期的透明度,解決這個問題。這類指標會測量從應用程式啟動指令到處理回應的時間。擷取這些資料點後,您就能準確判斷延遲時間是源自應用程式邏輯、網路路徑還是 Redis 伺服器。
事前準備
請確認用戶端應用程式使用服務帳戶,並為該帳戶指派下列 Identity and Access Management (IAM) 角色:
roles/cloudtrace.agent(Cloud Trace 代理程式)roles/monitoring.metricWriter(Monitoring 指標寫入者)
如要進一步瞭解如何授予角色,請參閱「使用 Google Cloud 控制台授予 IAM 角色」快速入門指南。
啟用 Cloud Monitoring API
如要將用戶端指標匯出至 Monitoring,應用程式必須啟用 Monitoring API。在 Monitoring 中匯出及以圖表呈現這些指標,有助於找出瓶頸的根本原因,判斷延遲的來源。
如要啟用 Monitoring API,請按照下列步驟操作:
在 Google Cloud 控制台中,前往「APIs & Services」(API 與服務) 頁面。
選取您建立 Memorystore for Redis 執行個體的專案。
按一下「啟用 API 和服務」。
搜尋
monitoring。在搜尋結果中,點選「Cloud Monitoring API」。
如果畫面顯示「API 已啟用」,代表 API 已啟用。否則請按一下「啟用」。
啟用 Cloud Trace API
如要在「追蹤記錄」中查看分散式追蹤記錄,請啟用 Trace API。接著,您可以使用「Trace 探索工具」查看這些追蹤記錄、診斷瓶頸,並找出應用程式中的延遲來源。
如要啟用 Trace API,請按照下列步驟操作:
在 Google Cloud 控制台中,前往「APIs & Services」(API 與服務) 頁面。
選取您建立 Memorystore for Redis 執行個體的專案。
按一下「啟用 API 和服務」。
搜尋
trace。在搜尋結果中,按一下「Cloud Trace API」。
如果畫面顯示「API 已啟用」,代表 API 已啟用。否則請按一下「啟用」。
啟用用戶端指標
如要啟用用戶端指標,請將 OpenTelemetry SDK、Cloud Monitoring 匯出工具和 Cloud Trace 匯出工具新增至應用程式的程式碼。OpenTelemetry 檢測會直接在應用程式的 Redis 用戶端程式庫中執行,並擷取指標。應用程式可藉此記錄延遲時間資料點,並匯出至 Monitoring 和 Trace 以供視覺化。
如要啟用用戶端指標,可以使用 Go、Java、Node.js 或 Python。如要瞭解如何為各語言啟用指標,請參閱下方的分頁標籤。
Go
如要安裝必要的 OpenTelemetry 和 Google Cloud exporter 依附元件,請在終端機中執行下列指令:
go get github.com/gomodule/redigo/redis@latest go get go.opentelemetry.io/otel go get go.opentelemetry.io/otel/sdk/trace go get go.opentelemetry.io/otel/sdk/metric go get github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/trace go get github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/metric
如要啟用用戶端指標,請建立
main.go檔案,並在其中加入下列程式碼:執行應用程式至少一分鐘,讓匯出工具有足夠的時間批次處理並將發布的指標傳送至 Monitoring。
Java
如要安裝必要的 OpenTelemetry 和 Google Cloud exporter 依附元件,請在應用程式的
pom.xml檔案中新增下列程式碼:如要啟用用戶端指標,請建立
RedisTelemetryApp.java檔案,並在其中加入下列程式碼:執行應用程式至少一分鐘,讓匯出工具有足夠的時間批次處理並將發布的指標傳送至 Monitoring。
Node.js
如要安裝必要的 OpenTelemetry 和 Google Cloud exporter 依附元件,請在終端機中執行下列指令:
npm install redis@^4.6.0 @opentelemetry/api@^1.9.0 @opentelemetry/sdk-trace-node@^2.1.0 @opentelemetry/sdk-trace-base@^2.1.0 @opentelemetry/sdk-metrics@^2.1.0 @opentelemetry/instrumentation@^0.205.0 @opentelemetry/instrumentation-redis@^0.67.0 @google-cloud/opentelemetry-cloud-trace-exporter@^3.0.0 @google-cloud/opentelemetry-cloud-monitoring-exporter@^0.21.0 @opentelemetry/resources@^2.1.0
如要啟用用戶端指標,請建立
server.js檔案,並在其中加入下列程式碼:執行應用程式至少一分鐘,讓匯出工具有足夠的時間批次處理並將發布的指標傳送至 Monitoring。
Python
如要安裝必要的 OpenTelemetry 和 Google Cloud exporter 依附元件,請在終端機中執行下列指令:
pip install redis==7.0.1 opentelemetry-api==1.39.1 opentelemetry-sdk==1.39.1 opentelemetry-instrumentation-redis==0.60b1 opentelemetry-exporter-gcp-trace==1.11.0 opentelemetry-exporter-gcp-monitoring==1.11.0a0
如要啟用用戶端指標,請建立
main.py檔案,並在應用程式中加入下列程式碼:執行應用程式至少一分鐘,讓匯出工具有足夠的時間批次處理並將發布的指標傳送至 Monitoring。
在 Monitoring 中查看指標
啟用用戶端指標並執行應用程式至少一分鐘,讓匯出工具有足夠時間批次處理指標並傳送至 Monitoring 後,即可使用 Monitoring 視覺化呈現指標、依作業或執行個體分組,以及套用匯總工具來監控應用程式的效能。
如要在 Monitoring 中查看指標,請按照下列步驟操作:
前往 Google Cloud 控制台的「Metrics Explorer」頁面。
選取 Google Cloud 專案。
按一下「Select a metric」(選取指標)。
搜尋
workload.googleapis.com/redis。選取用戶端指標。視需要依
operation和instance將資料分組,然後選擇匯總器。如要瞭解更多選項,請參閱「在使用 Metrics Explorer 時選取指標」。
在 Trace 中查看分散式追蹤記錄
應用程式開始匯出資料後,您可以使用 Trace 視覺化呈現 Redis 指令的完整要求-回應週期。在 Trace 中查看分散式追蹤記錄,有助於診斷瓶頸,以便快速找出應用程式中延遲的確切來源。
如要在 Trace 中查看分散式追蹤記錄,請按照下列步驟操作:
前往 Google Cloud 控制台的「Trace Explorer」頁面。
在散布圖上選取以圓點表示的近期追蹤記錄。
檢查瀑布圖,找出下列瓶頸,以找出延遲來源:
要求總時間長度:頂層 (父項) 長條會顯示作業完成前必須等待的總時間。
網路和伺服器延遲 (RTT):子長條 (例如標示為
GET或SET的長條) 會顯示指令在網路中傳輸,以及在 Memorystore for Redis 伺服器上執行的時間。用戶端連線遭到封鎖:如果 Redis 子時距開始之前出現大片的空白水平間隙,表示應用程式執行緒卡住,正在等待連線集區中的可用 TCP 連線。
應用程式剖析作業遭到封鎖:如果 Redis 子時距結束後出現大範圍的空白水平間隙,表示應用程式難以剖析或處理傳回的酬載。這種情況通常發生在數百萬位元組的 JSON 字串。
重試:如果同一個指令有多個短暫的子項範圍,且這些範圍在同一個父項追蹤記錄中依序發生,則用戶端可能發生網路封包遺失的情況,因此必須觸發指數輪詢重試迴圈。
疑難排解
本節列出可使用用戶端指標識別的常見效能問題,說明問題的根本原因,並提供疑難排解指引。
| 問題 | 原因 | 疑難排解 |
|---|---|---|
應用程式的延遲時間突然大幅增加,但 Memorystore for Redis 似乎完全正常。
|
瓶頸嚴格來說是在應用程式內部。您的執行緒嘗試執行 Redis 指令,但連線集區已完全耗盡。高 redis_client_blocking_latency 代表程式碼等待可用 TCP 通訊端的時間,之後指令才會傳送至網路。 |
如要處理更高的並行流量,請在 Redis 用戶端設定中增加連線集區大小限制 (例如 Go 的 MaxActive、Java 的 MaxTotal,或 Node.js 和 Python 的 max_connections)。 |
要求完成,但端點所需時間遠超出預期。網路或伺服器健康狀態沒有問題。
|
Memorystore for Redis 會執行指令,網路也會快速傳輸酬載 (RTT 較低)。不過,傳回的酬載很大 (例如 15 MB 的 JSON 字串)。應用程式發生高redis_application_blocking_latency,是因為應用程式在分配記憶體並將該大型字串還原序列化為物件時,耗用過多資源。 |
最佳化資料模型。請勿在單一金鑰中儲存大量 JSON Blob。
使用 Redis 雜湊 (HSET) 細分資料,並使用 HGET 或 HMGET 僅擷取所需的特定欄位。 |
面對使用者的應用程式延遲時間突然增加,但 Redis 指標顯示伺服器延遲時間較短,且連線集區簽出作業正常。
|
由於 redis_client_rtt 只會擷取成功要求的回合時間,因此不會反映封包失敗的逾時時間長度。如果應用程式發生暫時性封包遺失或 TCP 重設,經過檢測的用戶端重試邏輯會遞增 redis_retry_count,並觸發指數輪詢迴圈。這會在嘗試之間導入休眠時間 (例如 100ms、200ms 或 400ms)。使用者會感受到總延遲時間較長,但根本原因在於網路封包遺失,這會觸發用戶端休眠延遲。 |
檢查虛擬私有雲流量記錄檔,確認是否有封包遭捨棄、頻寬受到節流,或跨區域路由異常。如果發生逾時問題,請確保用戶端連線逾時 (socket_timeout 或 connect_timeout) 大於預期的 RTT,以因應暫時的網路抖動。 |
所有項目都會停止,且遙測管道的所有層級都會回報高延遲。
|
Redis 是單一執行緒,當您對大型集合執行 O(N) 時間複雜度指令 (例如 KEYS *、SMEMBERS 或對含有數百萬個欄位的雜湊執行 HGETALL) 時,Redis 引擎會暫停以滿足該要求。執行該指令時,所有其他應用程式要求都會排隊,導致系統延遲時間大幅增加。由於自訂 redis_client_rtt 與伺服器的延遲時間 (commands/usec_per_call) 相符,因此執行指令的伺服器是瓶頸。 |
開啟 Trace,查看緩慢跨度中的 Redis 指令,找出造成封鎖的查詢。在程式碼中,將封鎖指令換成非封鎖指令。 如要遞增地疊代大型資料集,且不鎖定伺服器執行緒,請使用 |
即使流量不高,應用程式仍會針對所有 Redis 指令回報一致的偏高基準延遲。
|
Redis 伺服器會立即執行指令,但您的應用程式和執行個體部署在不同區域 (例如 us-central1 和 us-east1)。每個網路封包都必須在這些地理位置資料中心之間,透過實體 Google 雲端基礎架構傳輸。因此,每次來回都會產生強制性的光速跨區域延遲懲罰。 |
如要縮短延遲時間,請將應用程式部署至與執行個體相同的區域和可用區。如要查看應用程式和執行個體的區域,請使用 Google Cloud 控制台。 |
後續步驟
- 進一步瞭解用戶端指標。
- 瞭解 Memorystore for Redis 適用的用戶端指標。