事後報告：Bad Gateway

摘要#

在 2024 年 1 月 11 日，Logto 服務經歷了服務中斷，出現許多 502 Bad Gateway 錯誤。

• 開始時間： 大約在 2024 年 1 月 11 日 15:28 UTC
• 解決時間： 大約在 2024 年 1 月 12 日 00:49 UTC
• 持續時間： 大約 9 小時
• 受影響的服務： Logto 驗證服務，Logto 雲端服務
• 影響程度： 嚴重
• 根本原因： logto.app 域名到期，續期未能完成。

時間線#

• 2024 年 1 月 11 日 15:28 UTC 使用者報告在訪問 Logto 驗證服務時遇到 502 Bad Gateway 錯誤。
• 2024 年 1 月 11 日 15:42 UTC 更多使用者報告相同問題。
• 2024 年 1 月 11 日 15:50 UTC 我們的團隊成員開始調查問題，並致電其他團隊成員。由於對部分成員已經是深夜，普通電話未能強烈地喚醒他們。
• 2024 年 1 月 12 日 23:54 UTC 我們發現雲端服務正在向驗證服務發送請求，但由於出現 ERR_TLS_CERT_ALTNAME_INVALID 錯誤，請求失敗。
• 2024 年 1 月 12 日 00:36 UTC 我們清除了 DNS 緩存，希望有幫助，但沒有。
• 2024 年 1 月 12 日 00:38 UTC 我們重新簽發了 TLS 證書，希望有幫助，但仍無效。
• 2024 年 1 月 12 日 00:45 UTC 我們注意到 logto.app 域名可能已經到期。檢查域名註冊商後發現未成功續期，域名已過期。
• 2024 年 1 月 12 日 00:49 UTC 域名續期完成。服務逐漸恢復正常。

事件分析#

發生了什麼？#

我們的域名通常通過域名註冊商自動續期。然而，此次續期過程因潛在的配置錯誤而失敗。因此，logto.app 域名過期，DNS 記錄被更新指向註冊商的停車頁面。

目前，驗證服務仍在運行，但大多數請求無法到達。惟一例外的是綁定到 auth.logto.io 域名的 Logto 管理租戶，不受過期影響。

除了驗證服務，我們還有一個協調 Logto 租戶和提供 Logto 雲端控制台（前端應用程式）的雲端服務。

當使用者操作雲端控制台時，應用程式不直接調用驗證服務，而是調用雲端服務進行所有管理操作。

為了對應 Logto 管理 API，我們設計了一個 "管理 API 代理" 端點來轉發請求到驗證服務。整個流程如下：

由於 *.logto.app 域名存在證書不匹配問題，雲端服務（Node.js）拒絕請求並拋出錯誤。

通常情況下，請求錯誤會被捕獲以防止整個服務崩潰。然而，由於錯誤是從代理模塊傳遞出來的，現有的錯誤處理邏輯未能捕獲，導致服務崩潰。

儘管每個 Logto 服務至少有三個副本，所有副本因雲端控制台的幾乎每個請求都會發生錯誤而輕易崩潰。自動恢復機制需要一些時間來生效，導致服務在一段時間內無法使用。

這就是為什麼使用者看到 502 Bad Gateway 錯誤的原因（所有副本崩潰）。一旦雲端服務恢復，上新的及重試的雲端控制台請求進來，崩潰循環繼續。

當雲端服務中斷時，它也影響驗證服務的某些端點，主要是 /api/.well-known/sign-in-exp。這個端點用於獲取包含連接器信息的登錄體驗配置，需要從雲端服務獲取。

解決方案#

• 手動續期域名。

經驗教訓#

• 始終設置域名到期監控或長時間購買。
• 注意時區差異可能導致事件響應延遲。
• 確保監控涵蓋所有域名。
• 在與可拋出模塊交互時需謹慎，確保能捕獲並妥善處理錯誤。

糾正和預防措施#

• ✅ 添加每月域名到期的監控，無論是否啟用自動續期。
• ✅ 添加對 logto.app 的監控。
• ✅ 更新雲端服務的錯誤處理邏輯，妥善捕獲和處理代理錯誤。
• ✅ 實施更強的警報機制，以在有全時區覆蓋的 SRE 團隊出現之前喚醒團隊面對事故。