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