這期內(nèi)容當中小編將會給大家?guī)碛嘘P(guān) 如何分析Serverless 中函數(shù)計算的可觀測性，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

皮山網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),皮山網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為皮山1000多家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)營銷網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的皮山做網(wǎng)站的公司定做！

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

概述

可觀測性是什么呢？維基百科中這樣說：可觀測性是通過外部表現(xiàn)判斷系統(tǒng)內(nèi)部狀態(tài)的衡量方式。

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

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

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

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

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

函數(shù)計算中的 Logging/Metrics/Tracing

1. 日志

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

1）配置日志

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

2）記錄日志

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

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

3）查看日志

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

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

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

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

2. 指標

查看指標的方式：

• 函數(shù)詳情查看監(jiān)控指標：FC 提供豐富的系統(tǒng)指標，這些指標可以不用任何配置，就可以在函數(shù)計算控制臺查看。

• 配置日志大盤：日志大盤不僅可以看到函數(shù)計算提供的監(jiān)控指標，而且可以與開發(fā)者日志關(guān)聯(lián)，生成自定義的監(jiān)控指標。

3. 鏈路追蹤

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

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

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

• 函數(shù)計算中調(diào)用 FC SDK，可以默認看到 SDK API 的調(diào)用時延。

• 開發(fā)者在函數(shù)代碼中訪問數(shù)據(jù)庫等產(chǎn)品，可以手動在函數(shù)中埋點分析這段時延。

問題排查

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

場景一：新版本發(fā)布后，函數(shù)錯誤率升高

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

場景二：函數(shù)性能差，總是執(zhí)行時間很長，甚至超時

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

場景三：業(yè)務(wù)量迅速擴張，并發(fā)度即將到達并發(fā)度限制

通過 metrics 查看當前并發(fā)度，觀察到并發(fā)度持續(xù)上升時，及時聯(lián)系函數(shù)計算開發(fā)同學，提升并發(fā)度。

上述就是小編為大家分享的 如何分析Serverless 中函數(shù)計算的可觀測性了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。