作者 | 劉龍飛

前言

Serverless架構在今天已經不再是新鮮的事物。該架構具有多個特點：較低的運營和開發成本、能快速上線、自動擴展、安全性高和適合微服務等。各大云服務商也提供了各自的Severless解決方案。然而，盡管Serverless架構在某些方面表現出色，但在當前轟轟烈烈的“微服務”進程中，它仍然不是一種主要的選擇。

除了由于本身特性導致的使用場景受限外，我想乏善可陳的關于Serverless最佳實踐的總結也是一個重要的因素。我有幸參與了一項基于AWS搭建的Serverless (FaaS) 系統的開發工作，該系統提供了一組核心服務。

通過幾次系統故障調研和性能優化的實際體驗，我發現系統監控在Serverless架構中至關重要。所以本文將從Serverless系統監控的角度來展開一些討論。

哪些指標需要被監控？

先分享一個真實發生的故事：

我們在對上文提到的FaaS 系統做一次部署時，由于API測試不通過導致流水線構建失敗。調查發現是因為測試運行時間過久導致請求使用的令牌過期。這一發現直接指向了系統的性能問題。我們回溯大量流水線構建記錄后發現，API測試所耗時長在近一個月以來逐日遞增。

在調查了CloudWatch中各項觀測指標后發現：從一個月前開始，Lambda的調用次數始終保持在最大并發量，并且Lambda一直處于高執行時延狀態。最終找到根因在于一個會觸發Lambda執行的消息事件由于某個bug被大量復制，并且該事件在被Lambda處理后原樣發回SQS，導致發生死循環。 

盡管這個問題發生在非生產環境，但帶來的影響依然是非常大的：首先，測試環境性能明顯降低。另一方面，AWS是按使用收費。該問題導致一個月以來，Lambda，SQS，RDS，DynamoDB和CloudWatch等AWS服務被持續不斷地使用，因而產生了高額的賬單。

上述故事中反映出來的問題可能有很多方面，但缺乏監控與告警無疑是導致該問題持續近一個月而沒有被發現和解決的罪魁禍首。那么，在Severless系統中，一般有哪些需要監控的指標呢？其實AWS 的CloudWatch已經給出了部分答案。不同于需要監控CPU/內存使用率等指標的長生命周期服務，Severless服務的一大特點就是不需要開發和運維人員過多關注底層資源的分配和管理。那么與之相對應地，針對Severless (FaaS) 而言，有以下一些值得關注的指標需要監控并配置告警。

1. 執行時延 (Duration)

一般Severless系統的函數都有最大執行時間的限制。而且從系統的設計原則上講，一次函數調用也不應執行過長的時間。當監控到較多的長時延函數調用時，表明系統出現了異常情況，且極有可能導致性能問題。同時，長時延也意味著成本的增加。函數執行時延的異常增高通常有如下原因：

• 如果該函數依賴于第三方服務或同一云平臺的其他服務，則有可能是網絡通信，數據庫訪問等I/O操作延遲增大；
• 若該函數會批處理事件，則有可能是事件的生產者出現了異常，導致函數每次調用都需要處理大量任務。

所以函數執行時延的異常增高，通常就是系統某一部分出現問題的信號。

2. 調用次數 (Invocations)

調用次數表示某一時間范圍內函數的調用次數，它能夠反映當前函數的活躍程度以及整體上的執行情況。調用次數的突然變化也會反映系統中的異常情況。另外，監控各個函數的調用情況也有助于我們合理配置該函數的最大并發量。

Severless系統的自動擴容就依賴于函數的調用情況。當多個請求進入系統，而當前函數實例正在處理請求，系統會自動創建新的實例來處理其他請求。這個過程會一直持續到有足夠的函數實例來處理所有請求，除非達到最大并發量。一旦達到最大并發量后仍有待處理請求，則認為發生了瓶頸（Throttles）。出現瓶頸則是一個非常明顯的需要告警的情況，因此為瓶頸這一指標配置告警通常是非常有效的做法。

3. 錯誤率 (Error rate)

無論是函數調用錯誤或者是函數執行異常都說明系統出現了非預期的行為，都需要盡快處理使系統恢復正常。但需要說明的是，如果系統出現的是性能問題，則不一定會導致錯誤率提高。所以不能僅依靠這單一指標來衡量系統的健康狀態。

以上是我認為的針對FaaS系統最基本的和最重要的三個指標。合理配置這幾個指標的監控與告警，可以提前發現大多數非業務問題的系統異常，進而及時調查和解決問題避免更大的損失。

當然，除了函數，Severless系統還會依賴于大量云平臺提供的其他服務。以AWS為例，一個典型的Severless架構通常會使用到API Gateway， SQS， SNS， DynamoDB和RDS等服務。而每個服務都有對應的需要關心并監控的指標，從學習了解的角度，有個技巧是直接去看CloudWatch提供了哪些已經被自動監控的指標，進而深入了解每個指標所代表的含義和所反映的深層次問題。了解得越清楚，在配置監控和告警時會更得心應手，收到告警后也有助于快速定位問題。

除了針對各個基礎服務的各類指標進行監控外，監控云平臺各個賬號的賬單也是避免損失的一大法寶。Severless系統中很多問題都會導致賬單的異常增加，而通常我們的精力都會放在系統問題的調查和修復上，后知后覺地才發現這一實打實的經濟損失。大多云平臺都提供了成本管理功能。如AWS可以監控賬單信息，并配置通知告警。甚至還可以配置預算操作，當賬單達到某些條件時自動執行一些預先定義好的行為，以達到止損的目的。

最后需要強調的是，除了監控各項服務的基礎指標外，監控業務指標以及由業務指標導向的技術指標也是監控中非常重要的一環，畢竟任何軟件系統提供具體業務都是第一位的。在這一方面，Severless架構和其他類型架構沒有太多本質上的差別，所以不在此過多討論，但這也是設計系統監控架構時必不可少的。

分布式監控

盡管云服務商已經提供了很多基礎指標的監控，但由于函數的事件驅動以及短生命周期特性，使我們很難從這些基礎指標中讀到一個完整的“故事”。若是我們想基于這些基礎監控去分析系統性能瓶頸，或者嘗試調研特定業務問題，則會面臨重重困難。當然，很容易想到的方式是分析日志來進行分析和調研，但以我們實際經驗來看，嘗試從大量日志中發現性能瓶頸絕不是一個簡單的事情。

我們曾對上述FaaS系統嘗試進行整體性能調優，以及針對特定業務場景的性能優化。需要做的事情大致分為以下步驟：識別性能瓶頸，對發現的瓶頸排列優先級，依次嘗試優化，本地驗證局部優化效果，測試環境驗證特定業務場景下的優化效果，生產環境驗證整體性能提升和特定業務場景優化效果。在整個調查、修復和驗證過程中，遇到了很多痛點，其中最為明顯的就是尋找瓶頸和驗證優化后效果兩個方面：

問題1：找到性能瓶頸

由于每個請求都會有若干個函數依次進行處理，其中整個過程還會包括消息隊列中事件的寫入和讀出，數據庫的連接和數據讀寫，第三方服務的訪問等過程。而我們所能采用的手段只能是首先分析日志進行初步定位，然后再本地調試進行更為精確地定位。因為現有日志缺少一些必要信息，所以需要增加日志。但這樣做，一方面帶來了額外的工作量，另一方面也會帶來大量的“噪音”，增加了分析日志的復雜程度。更重要的是，記錄大量日志有可能影響函數本身執行的性能，也會增加監控系統的成本。另外，本地調試也不是一件容易的事情。由于函數依賴于很多第三方服務或者云平臺其他服務，本地需要隔離掉或提供虛擬的依賴。即使使用單元測試來觀察特定事件處理過程的執行性能，因為要關注特定業務場景，也需要花費大量時間準備測試數據。

問題2：驗證優化后效果

由于依賴過多，每次修復后都需要部署到個人測試環境中，而部署過程會花費較多的時間。另外，想要端到端地去驗證整體和局部性能的提升效果，也只能通過寫復雜的查詢命令來從日志中進行統計。在部署到生產環境后，想要統計特定業務場景下的性能提升也是很大的一個挑戰。由于日志主要關注局部過程，很難通過日志提取出特定業務場景并得到統計意義上的結果，所以遲遲無法衡量優化后的真實效果。

雖然以上問題最終都通過各種手段得到了一定程度上的解決，但過程顯然不是輕松愉快的。以上問題的癥結在于單單依靠日志無法完整地貫通端到端過程，各處日志信息格式不統一，不能方便地聚合各個服務中的監控信息。

分布式監控系統就是可以有效解決這一類問題的技術手段。它通過采用統一數據模型和API，從各個系統子服務/函數中收集數據，統一聚合和分析處理，以良好的可視化方式進行結果的呈現。構建良好的分布式監控系統可以從端到端的視角提供請求跟蹤，過程分析，甚至實時調試等功能。所以在業務場景較為復雜的情況下，為Serverless系統應用分布式監控工具應該成為一種必然的選擇。

以AWS為例，它提供了原生的監控工具X-Ray。X-Ray具備端到端跟蹤功能，可以監控到Lambda，RDS，DynamoDB，SQS和SNS等服務中的元數據，并提供應用程序的端到端和跨服務視圖。Service map 則提供了應用程序中的服務間匯總數據的連接視圖，其中包括平均延遲和故障率等。其他如延遲檢測，數據注釋和篩選等也是非常實用的功能。當然，還有很多其他類似的工具也能達到相同的目的，我們在使用中根據具體需求進行選擇就好。

寫在最后

本文只是拋磚引玉，沒有過于深入的討論，目的是想總結與記錄在Serverless系統中試水的所見與所得。或許我們遇到的很多問題，有可能是因為Severless架構目前并不適用于我們所面臨的復雜業務。但我想說，實踐是最好的老師，體驗和經歷這些痛點才會讓人更有動力去思考和解決這些問題。監控系統單拎出來也是一個龐大的話題，希望能通過本文讓我們更多地回過頭去思考監控的目的，總結那些切實幫助和啟發到了我們的實踐。