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