作者 | 夏莞 阿里巴巴函式計算團隊
本文整理自《serverless 技術公開課》
可觀測性是什麼呢？維基百科中這樣說：可觀測性是通過外部表現判斷系統內部狀態的衡量方式。
在應用開發中，可觀測性幫助我們判斷系統內部的健康狀況。在系統出現問題時，幫助我們定位問題、排查問題、分析問題；在系統平穩執行時，幫助我們評估風險，**可能出現的問題。評估風險類似於天氣預報，**到明天下雨，那出門就要帶傘。在函式計算的應用開發中，如果觀察到函式的併發度持續公升高，很可能是業務推廣團隊的努力工作導致業務規模迅速擴張，為了避免達到併發度限制觸發流控，開發者就需要提前提公升併發度。
可觀測性包括三個方面：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 中，可以登入日誌服務控制台檢視日誌。
同時，函式計算控制台也整合了日誌服務，可以在函式計算控制台上檢視日誌。函式計算控制台有兩種查詢方式：
2. 指標
檢視指標的方式：
3. 鏈路追蹤
（請求在各個鏈路的延時瀑布圖）
鏈路追蹤是分布式系統排查問題的重要一環，鏈路追蹤可以分析分布式系統中請求在各個鏈路的時延。有以下幾種情況：
函式計算提供了很多可觀測性相關的功能，那究竟怎樣定位問題呢？以幾個場景為例。
場景一：新版本發布後，函式錯誤率公升高
首先發布版本後要觀察函式各項指標，一旦錯誤率公升高要立即回滾避免故障，檢視函式日誌定位錯誤原因，修復問題再次上線。
場景二：函式效能差，總是執行時間很長，甚至超時
開啟 tracing 功能，在函式內部可能耗時的地方進行埋點，檢視請求的瀑布圖，定位執行時間長的原因，修復問題。
場景三：業務量迅速擴張，併發度即將到達併發度限制
通過 metrics 檢視當前併發度，觀察到併發度持續上公升時，及時聯絡函式計算開發同學，提公升併發度。
Obsuite 混合雲可觀測性中臺
什麼是obsuite？obsuite是一整套支援混合雲場景的可觀測性解決方案，可同時支援物理機場景和雲原生場景，利用指標和日誌兩種分析手段，覆蓋資源 應用 業務多層次監控和分析，內建強大的資料採集傳輸儲存引擎 指標計算告警引擎 資料查詢分析引擎，線上問題及時感知，業務資料深刻洞見，為業務穩定性建設和...
捕獲和增強原生系統的可觀測性來發現錯誤
在對 tidb 進行 chaos 實踐的時候，我一直在思考如何更好的發現 tidb 整個系統的故障。最開始，我們參考的就是chaos engineering裡面的方式，觀察系統的穩定狀態，注入乙個錯誤，然後看 metrics 上面有啥異常，這樣等實際環境 現類似的 metrics，我們就知道發現了什...
構建可觀測的分布式系統
如今的系統正在變得越來越複雜 微服務在網路上是分布式存在的，並且能夠動態擴充套件，這樣會導致各種形式的故障，出現故障的方式是我們無法預料的。如果盲目相信我們能夠構建完美的系統將會形成錯誤的安全感，所以我們需要預先為此做好充分地準備。在可觀測方面進行投資能夠讓我們掌握系統的執行狀況，這些事情是我們以前...