如何分析Serverless 中函數計算的可觀測性

這期內容當中小編將會給大家帶來有關 如何分析Serverless 中函數計算的可觀測性，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

下面主要分為三個部分：概述中介紹可觀測性的基本概念，主要包括 Logging、Metrics、Tracing 三個方面；然后詳細介紹函數計算上的 Logging、Metrics、Tracing；最后以幾個常見場景為例，介紹在函數計算中如何快速定位問題并解決問題。

概述

可觀測性是什么呢？維基百科中這樣說：可觀測性是通過外部表現判斷系統內部狀態的衡量方式。

在應用開發中，可觀測性幫助我們判斷系統內部的健康狀況。在系統出現問題時，幫助我們定位問題、排查問題、分析問題；在系統平穩運行時，幫助我們評估風險，預測可能出現的問題。評估風險類似于天氣預報，預測到明天下雨，那出門就要帶傘。在函數計算的應用開發中，如果觀察到函數的并發度持續升高，很可能是業務推廣團隊的努力工作導致業務規模迅速擴張，為了避免達到并發度限制觸發流控，開發者就需要提前提升并發度。

可觀測性包括三個方面：Logging、Metrics、Tracing

• Logging 是日志，日志記錄了函數運行中的關鍵信息，這些信息是離散且具體的，結合錯誤日志與函數代碼可以迅速定位問題。

• Metrics 是指標，是聚合的數據，通常以圖表的形式展現。圖表中的 tps、錯誤率等核心指標，可以反映函數的運行情況與健康狀況。

• Tracing 是鏈路追蹤，是請求級別的追蹤，在分布式系統中可以看到請求在各個模塊的延時、分析性能瓶頸。

函數計算中的 Logging/Metrics/Tracing

1. 日志

在函數計算中如何查看函數日志呢？在傳統服務器開發方式中，可以將日志記錄到磁盤中的某個文件中，再通過日志收集工具收集文件的內容；而在函數計算中，開發者不需要維護服務器了，那如何收集代碼里打印的日志呢？

1）配置日志

函數計算與日志服務無縫集成，可以將函數日志記錄到開發者提供的日志倉庫（Logstore）中。日志是服務配置中的一項，為服務配置 LogProject 和 Logstore，同一服務下所有函數通過 stdout 打印的日志，都會收集到對應的 Logstore 中。

2）記錄日志

那日志怎么打呢？在代碼中直接通過 console.log/print 打印的日志可以收集到嗎？答案是可以的。各個開發語言提供的打印日志的庫都將日志打印到 stdout，比如 node.js 的 console.log()、python 的 print()、golang 的 fmt.Println() 等。函數計算收集所有打印到 stdout 的日志并將其上傳到 Logstore 中。

函數計算的調用是請求維度的，每次調用對應一個請求，也就對應一個 requestID。當請求量很大時，會有海量日志，如何區分哪些日志屬于哪個請求呢？這就需要把 requestID 一起記錄到日志中。函數計算提供內置的日志語句，打印的每條日志前都會帶上請求 ID，方便日志的篩選。

3）查看日志

當函數日志被收集到日志服務的 Logstore 中，可以登錄日志服務控制臺查看日志。

同時，函數計算控制臺也集成了日志服務，可以在函數計算控制臺上查看日志。函數計算控制臺有兩種查詢方式：

• 簡單查詢：簡單查詢中列出每個 requestID 對應的日志，可以通過 requestID 對日志進行篩選；

• 高級查詢：高級查詢嵌入了日志服務，可以通過 SQL 語句進行查詢。

2. 指標

查看指標的方式：

• 函數詳情查看監控指標：FC 提供豐富的系統指標，這些指標可以不用任何配置，就可以在函數計算控制臺查看。

• 配置日志大盤：日志大盤不僅可以看到函數計算提供的監控指標，而且可以與開發者日志關聯，生成自定義的監控指標。

3. 鏈路追蹤

（請求在各個鏈路的延時瀑布圖）

鏈路追蹤是分布式系統排查問題的重要一環，鏈路追蹤可以分析分布式系統中請求在各個鏈路的時延。有以下幾種情況：

• 函數計算作為整個鏈路中的一環，可以看到請求在函數計算上的時延，時延包括系統啟動的時間和請求真正的執行時間，幫助用戶分析性能瓶頸。

• 函數計算中調用 FC SDK，可以默認看到 SDK API 的調用時延。

• 開發者在函數代碼中訪問數據庫等產品，可以手動在函數中埋點分析這段時延。

問題排查

函數計算提供了很多可觀測性相關的功能，那究竟怎樣定位問題呢？以幾個場景為例。

場景一：新版本發布后，函數錯誤率升高

首先發布版本后要觀察函數各項指標，一旦錯誤率升高要立即回滾避免故障，查看函數日志定位錯誤原因，修復問題再次上線。

場景二：函數性能差，總是執行時間很長，甚至超時

開啟 tracing 功能，在函數內部可能耗時的地方進行埋點，查看請求的瀑布圖，定位執行時間長的原因，修復問題。

場景三：業務量迅速擴張，并發度即將到達并發度限制

通過 metrics 查看當前并發度，觀察到并發度持續上升時，及時聯系函數計算開發同學，提升并發度。

上述就是小編為大家分享的 如何分析Serverless 中函數計算的可觀測性了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。