fbpx

雲架構實戰 - 設計雲端服務 Log 架構 (下)

接續前一篇文章「雲架構實戰 - 設計雲端服務 Log 架構 (上)」,繼續介紹 在 HTTP Saas 服務下的 Log 架構設計...服務高可用架構

凡走過必留下痕跡 - 透過 Request ID 追蹤 HTTP Request 生老病死

當我們在對 Issue 進行排除時,常常需要合併上述三種類型的 Log 進行判讀 (Event, Application, Request Log),然而在實做不同類型的 Log 記錄時,就需要有一個 ID 來幫助我們追蹤與歸納。以 Web Service 為例,我們通常在 HTTP Request 一進入系統時 (Load Balance),就會在 HTTP Header 配發一個 Request ID,這一個「Request ID」會更隨著系統進行傳遞,所有類型的 Log 都可以過濾記錄,也會透過 HTTP Response 回傳至 Client 端。可以讓 Server 與 Client 的 Log 串連顯示,實現「南北菜蟲一起串聯,就是這麼簡單!」,鎖定問題的時候就會很有效率,相當於有了生老病死的 Log Trace 機制。

有了這樣的設計,你會知道 Request 進來以後走到那一台機器?在那一個行程被執行?對資料進行了什麽操作?在哪裡發生錯誤?或者沒有錯誤回傳了什麽樣的狀態?

由於這些 Log 可能都是透過不同的系統來記錄,時間的同步也是很重要,如果您的服務是全球性質,使用 UTC 標準時間是一個好辦法。

Log 應該要有哪些通用欄位

在儲存大量 Log 以前,由於 Log 來自不同的系統,可以先想想 Log 會需要哪些通用的欄位,好讓未來在查詢的時候可以直接過濾,快速定位。

Timestamp

不論你的服務對象遍及全球,或者只在某一個時區,時間的同步是必要的。如果服務只是在單一時區,以「維運人員」的本地時區進行記錄既簡單又明瞭,畢竟實際調閱 Log 的人員才是重點,可以省下很多時區轉換與思考的腦細胞。如果你的服務與維運人橫跨不同的時區,那你就統一用 GTM+0 標準時間吧,總而言之統一即可。

Level

定義每一條 Log 的優先等級,方便在除錯的時候進行篩選,Level 的定義方法可以參考以下準則:

Debug:只要是幫助除錯的資訊都可以透過 Debug 模式輸出,在產品正式環境不進行記錄,只有在開發環境或者指定特別的模式來開啟,避免寫入太多無用的 Log 而影響了效能。一般的資料庫 Select Query 我都會寫進 Debug Log,遇到 Slow Request 的時候可以合併除錯。

Info:只要有檔案的寫入變更、資料庫的寫入變更、外部命令的呼叫、
第三方系統的呼叫 (API)、或者會改變 Server Status 的行為都會進行紀錄,在業務邏輯出現錯誤的時候這個 Info Level 可以幫上忙。另外,像是對資料庫會造成變更的 Query 也會進行記錄。

Warn:發生一些預期的錯誤,但不影響服務的運作,像是過大的檔案上傳,資訊安全警示,磁碟空間警示,Request 執行時間過長等等。一般這類的訊息可以一段時間(比如一週)後進行檢視,檢視對系統穩定性的影響,或者需要改善程式邏輯優畫流程。

Error:這一類的 Log 都是會影響系統正確執行的訊息,像是連線失敗、寫檔失敗等等。此外,只要程式發生 Exception 一定要記錄 Call Stack 相關資訊,這類嚴重的 Error Log 有時候還會整合 Slack/IM 直接發送到負責人手機。忽然大量的 Error 很有可能是系統崩潰的前兆,比如資料庫 Lock 造成緩慢或連線失敗,伴隨爆量的 Request 可能就會引發雪崩效應,導致整個系統崩潰。

Tag

對於不同的 Log 可以規劃設定不同的「標籤」,可以用來管理與監控。比如某一類標籤可能涉及系統緩慢,可以為此實做不同的警示機制。

Log 的儲存一般來說可以採用滾動的方式來管理,比如設定三個月滾動,並定時將過期的 Log 進行封存。千萬要考慮磁碟空間,避免在服務端讓 Log File 塞爆了系統磁碟。此外,在 Log 寫入的效率提昇,也有很多作法,以非同步的方式處理 Log 是最好的作法,為了降低 Log Server 的即時寫入覆載與提高 Log 吞吐,可以透過 Queue 的設計來實現,比入透過 Kafka 作為緩衝,讓大量產生的 Log 可以獲得妥善的處理。

通常已經具備一定規模的系統,就會需要獨立的 Log Server 來進行管理。Log Server 可以提供大量的 Log 儲存、檢索、監控、管理,可以省下不少除錯的時間,市面上也有很多現成的雲端服務或系統,比如 newrelic, splunk, elastic 等等。如果您對 ElasticSearch 實做 Log Server 有興趣可以參考「用 ElasticSearch + FluentD 打造 Log 神器與數據分析工具」這一篇文章。

有關 SaaS Log 架構設計就先介紹到這裡,下次見...