【51CTO.com快譯】眾所周知，無服務器(Serverless)應用的優勢在于它能夠擁有多個在邏輯上彼此分布的功能與服務。不過，隨著這些功能和服務的增長，以及各種代理和包裝器(wrapper)的添加，此類應用會變得越來越復雜，而且維護的成本也會越來越高。因此，我們需要對無服務器應用采取恰當的監控，以便開發人員能夠深入地了解每次執行和事件的具體細節，更容易地發現錯誤，并可以準確地衡量每次調用所消耗的資源。此外，良好的無服務器監控工具也有益于優化應用程序的開發成本和運行性能。
什么是AWS Lambda?
在此，我們以AWS的日志記錄和監控工具為參照，首先來看看一套良好的日志監控系統所應該具備的要素：
- 數據信息越詳細越好
- 數據的采集越頻繁越好
- 日志收集不應影響應用程序的性能
無服務器架構是面向服務架構(SOA)原理的擴展，其中服務(或稱功能)采用消息(或稱事件)進行通信。如果使用得當，那么無服務器架構不但可以降低代碼復雜性，而且能夠簡化對于應用程序的管理。下面讓我們來了解一下有關AWS Lambda的概念及其用途。
作為一項服務，AWS Lambda可以將您的代碼運行在某個已經預先分配好CPU、磁盤和內存的容器中。所有這些，連同您的代碼、及其關聯的配置被稱為Lambda功能函數(function)。這些功能在運行時能夠響應各種外部事件或觸發器。由于它是“無狀態(stateless)”的，因此Lambda功能與底層架構解耦，開發人員只需專注其代碼，而由Lambda來負責無服務器應用的核心部分。
功能即服務(Function-as-a-Service，FaaS - https://dashbird.io/blog/what-is-faas-function-as-a-service/)從開發人員的角度，解決了過往架構模型需要處置的許多問題，即：無需考慮服務器的管理性、可擴展性和可用性，即可具有代碼的運行能力。如果您想了解更多有關無法服務器化的整個詳細知識，請參考無服務器知識庫。
需要監控什么?
監控，就是通過外部工具和手段，讓由系統產生的、可觀測的數據可視化。在大多數情況下，監控所面臨的挑戰主要是：目標單元多、生命周期短、以及由配置代理所直接導致的延遲。因此，在具體實現中，我們既可以對無服務器應用采取有針對性的特定監控方式，也可以使用通用的監控辦法，具體則取決于您的實際需求和所使用的平臺。
不過，無論采取哪種方式，我們都需要及時獲悉無服務器應用的各項性能開銷，其中包括：延遲、冷啟動、調用錯誤、以及費用與使用量等方面。下面我們將逐一進行討論。
延遲
在面對大型數據集時，有的延遲很容易根據較長的用戶請求響應時間而被發現，而某些延遲則可能隱藏在那些平均執行速度之下，很難被直接檢測到。因此，監控延遲的一種較好的方法是：構造一個包含了所有關鍵任務功能的自定義儀表板，一旦檢測到某個功能的用時比預期更長，則需要深入查看其詳細的數據指標。
作為開發人員，我們所面對的應用SLA需求往往是：讓99%的請求都能夠在1秒鐘或更短的時間內完成。因此，儀表板還需要通過測量和統計，以百分比的形式反映某些指標。
冷啟動
Lambda功能函數往往會運行在Docker容器之中。在首次調用時，AWS會首先“冷啟動”一個新的容器，然后在其中執行某項功能。這對于那些初次訪問應用的用戶來說，很可能會感受到幾百毫秒、甚至是幾秒鐘的延遲時間。在初始等待時間過后，該功能函數會在一段時間內保持“活躍(warm)”的狀態。此間，新的調用既不會遭遇延遲，最終用戶的響應也會比較快。不過，在應對同一時刻的大量流量并發時，AWS會通過擴展更多的容器，來處理所有新的請求。而這將導致完全不同的冷啟動序列。此外，如果功能函數需要依賴于彈性網絡接口(Elastic Network Interfaces，ENI-- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)與其他服務進行通信，那么延遲還會增加。
可見，在大多數情況下，我們需要避免出現冷啟動現象。不過，云服務平臺通常不會直接提供針對應用程序棧的冷啟動檢測和監控。我們需要借用Dashbird(https://dashbird.io/features/)之類的監控服務，來發現目標架構中值得改進的地方。如果您想了解更多有關如何解決冷啟動問題的介紹，請參考--https://dashbird.io/blog/can-we-solve-serverless-cold-starts/。
調用錯誤
有時候，在功能函數接收到調用請求之前，該請求就已經被拒絕了。而且，此類調用錯誤會讓Lambda返回400或500系列的HTTP狀態代碼。具體請參見常見錯誤的列表--https://dashbird.io/knowledge-base/logging/lambda-invocation-function-and-runtime-errors/，或完整的調用錯誤列表--https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html#API_Invoke_Errors。
通常，典型的企業應用會通過API連接到其他SaaS工具上，如果其中的某個連接或節點出現了問題，則會影響到正常的業務邏輯。我們可以通過由Dashbird提供的嚴重錯誤儀表板，來快速了解應用程序在第一次和最后一次發生特定瓶頸、或錯誤的根本原因和具體時間。
費用與使用量
無論是Lambda，還是AWS S3存儲桶、VPC、DynamoDB等資源，其費用都是與使用量成正比的。而我們在使用分布式云服務時，很難有效且及時地跟蹤資源在使用過程中所產生的花銷。因此，在具體實現中，我們往往需要采取以帳戶級別監控為主，功能級別監控為輔的方法。例如，我們可以使用Dashbird應用來統計從12小時到1個月的時間跨度，按照每隔5分鐘抽樣一次的詳細信息視圖，進而發現目標應用中的使用趨勢和費用異常。如果您想了解更多有關無服務器監控的最佳實踐，請參考--https://sls.dashbird.io/en/serverless-best-practices。
監控工具--AWS CloudWatch
作為Lambda的內置工具，AWS CloudWatch會根據功能、版本和容器類型，來組織日志，并在日志中包含運行時、容器錯誤、以及時間戳。當然，Lambda也會為每次調用添加各種元數據。通過收集和跟蹤各類指標，CloudWatch日志可以提供有關資源使用情況、應用程序的性能、以及運營狀況的等基礎架構范圍內的視圖。
同時，我們可以使用其自帶的AWS Cloudwatch Alarm，來設置各種指標警報和復合警報。據此，您可以獲悉目標應用正在使用的CPU和內容的情況。而且，您還可以通過預定義事件來設置門限值，一旦達到或接近該值，就會觸發通知。因此，我建議您在構建第一個FaaS應用程序時，就將CloudWatch作為監控和跟蹤的起點，而當用戶和請求數大到一定數量級時，再引入更加全面的工具。
問題管理與團隊合作
任何云端應用程序，即使是最簡單的，也會頻繁地產生一定數量的事件與問題，尤其是那些正在不斷開發與迭代的應用。因此，為了能讓開發團隊有效地獲悉和解決問題，監控平臺需要以用戶友好的方式，可視化和控制各種未解決、已解決、暫時可以被忽略的問題。通過設置和提供清晰的工作流程，團隊將能夠更流暢地溝通，并提出切實可行的解決方案。
質量跟蹤
在監控過程中，快速可視化某個事件在過去所發生過的狀況是非常重要的。它不但能夠幫助我們就某種情況開展進一步的調查，還可以協助我們發現針對某個錯誤的修復方法。通過此類回溯性的質量跟蹤，我們可以避免在初始開發和錯誤糾正的過程中犯同樣的錯誤，同時也能通過創建持續的自動化學習和評估方法，來提高應用的質量與性能。
事件驅動的調試
開發人員雖然是監控程序的創建者，但是他們并沒有責任在生產環境中持續監控自己的應用日志。那么面對大量的應用日志，監控系統就需要能夠在不錯過關鍵內容的前提下，提供自動化的警報服務。也就是說，我們需要通過自定義警報功能，來成功實現監控和錯誤調試。
在實際應用中，警報機制不僅需要能夠檢測出應用程序的錯誤，還要能夠發現可能間接影響應用的架構自身缺陷。例如在AWS Lambda中，可能會出現包括超時、容器崩潰、內存耗盡等方面的事件，那么我們就可以采用Dashbird的自動化警報服務，具體請參見-- https://dashbird.io/features/automated-alerting/。此外，對于系統中的容錯組件，開發人員則可以禁用單個問題警報，只設置匯總之后的指標。據此，他們不但可以得到真正所需的信息，還能夠將注意力放在應用調優上。
小結
如今，大多數開發團隊也在使用Slack之類即時消息服務，以更快捷、更輕松、更方便的方式，專注于無服務器應用的開發與調試，實現即時的警報和更快的響應修復。這也正是我們監控無服務器應用的意義所在。
原標題：The Ultimate Guide to Monitoring Serverless Applications，作者: Taavi Rehemägi
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
