[[344764]]

【51CTO.com快譯】眾所周知，無(wú)服務(wù)器(Serverless)應(yīng)用的優(yōu)勢(shì)在于它能夠擁有多個(gè)在邏輯上彼此分布的功能與服務(wù)。不過(guò)，隨著這些功能和服務(wù)的增長(zhǎng)，以及各種代理和包裝器(wrapper)的添加，此類(lèi)應(yīng)用會(huì)變得越來(lái)越復(fù)雜，而且維護(hù)的成本也會(huì)越來(lái)越高。因此，我們需要對(duì)無(wú)服務(wù)器應(yīng)用采取恰當(dāng)?shù)谋O(jiān)控，以便開(kāi)發(fā)人員能夠深入地了解每次執(zhí)行和事件的具體細(xì)節(jié)，更容易地發(fā)現(xiàn)錯(cuò)誤，并可以準(zhǔn)確地衡量每次調(diào)用所消耗的資源。此外，良好的無(wú)服務(wù)器監(jiān)控工具也有益于優(yōu)化應(yīng)用程序的開(kāi)發(fā)成本和運(yùn)行性能。

什么是AWS Lambda?

在此，我們以AWS的日志記錄和監(jiān)控工具為參照，首先來(lái)看看一套良好的日志監(jiān)控系統(tǒng)所應(yīng)該具備的要素：

• 數(shù)據(jù)信息越詳細(xì)越好
• 數(shù)據(jù)的采集越頻繁越好
• 日志收集不應(yīng)影響應(yīng)用程序的性能

無(wú)服務(wù)器架構(gòu)是面向服務(wù)架構(gòu)(SOA)原理的擴(kuò)展，其中服務(wù)(或稱(chēng)功能)采用消息(或稱(chēng)事件)進(jìn)行通信。如果使用得當(dāng)，那么無(wú)服務(wù)器架構(gòu)不但可以降低代碼復(fù)雜性，而且能夠簡(jiǎn)化對(duì)于應(yīng)用程序的管理。下面讓我們來(lái)了解一下有關(guān)AWS Lambda的概念及其用途。

作為一項(xiàng)服務(wù)，AWS Lambda可以將您的代碼運(yùn)行在某個(gè)已經(jīng)預(yù)先分配好CPU、磁盤(pán)和內(nèi)存的容器中。所有這些，連同您的代碼、及其關(guān)聯(lián)的配置被稱(chēng)為L(zhǎng)ambda功能函數(shù)(function)。這些功能在運(yùn)行時(shí)能夠響應(yīng)各種外部事件或觸發(fā)器。由于它是“無(wú)狀態(tài)(stateless)”的，因此Lambda功能與底層架構(gòu)解耦，開(kāi)發(fā)人員只需專(zhuān)注其代碼，而由Lambda來(lái)負(fù)責(zé)無(wú)服務(wù)器應(yīng)用的核心部分。

功能即服務(wù)(Function-as-a-Service，F(xiàn)aaS - https://dashbird.io/blog/what-is-faas-function-as-a-service/)從開(kāi)發(fā)人員的角度，解決了過(guò)往架構(gòu)模型需要處置的許多問(wèn)題，即：無(wú)需考慮服務(wù)器的管理性、可擴(kuò)展性和可用性，即可具有代碼的運(yùn)行能力。如果您想了解更多有關(guān)無(wú)法服務(wù)器化的整個(gè)詳細(xì)知識(shí)，請(qǐng)參考無(wú)服務(wù)器知識(shí)庫(kù)。

需要監(jiān)控什么?

監(jiān)控，就是通過(guò)外部工具和手段，讓由系統(tǒng)產(chǎn)生的、可觀測(cè)的數(shù)據(jù)可視化。在大多數(shù)情況下，監(jiān)控所面臨的挑戰(zhàn)主要是：目標(biāo)單元多、生命周期短、以及由配置代理所直接導(dǎo)致的延遲。因此，在具體實(shí)現(xiàn)中，我們既可以對(duì)無(wú)服務(wù)器應(yīng)用采取有針對(duì)性的特定監(jiān)控方式，也可以使用通用的監(jiān)控辦法，具體則取決于您的實(shí)際需求和所使用的平臺(tái)。

不過(guò)，無(wú)論采取哪種方式，我們都需要及時(shí)獲悉無(wú)服務(wù)器應(yīng)用的各項(xiàng)性能開(kāi)銷(xiāo)，其中包括：延遲、冷啟動(dòng)、調(diào)用錯(cuò)誤、以及費(fèi)用與使用量等方面。下面我們將逐一進(jìn)行討論。

延遲

在面對(duì)大型數(shù)據(jù)集時(shí)，有的延遲很容易根據(jù)較長(zhǎng)的用戶(hù)請(qǐng)求響應(yīng)時(shí)間而被發(fā)現(xiàn)，而某些延遲則可能隱藏在那些平均執(zhí)行速度之下，很難被直接檢測(cè)到。因此，監(jiān)控延遲的一種較好的方法是：構(gòu)造一個(gè)包含了所有關(guān)鍵任務(wù)功能的自定義儀表板，一旦檢測(cè)到某個(gè)功能的用時(shí)比預(yù)期更長(zhǎng)，則需要深入查看其詳細(xì)的數(shù)據(jù)指標(biāo)。

作為開(kāi)發(fā)人員，我們所面對(duì)的應(yīng)用SLA需求往往是：讓99%的請(qǐng)求都能夠在1秒鐘或更短的時(shí)間內(nèi)完成。因此，儀表板還需要通過(guò)測(cè)量和統(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ì)于那些初次訪問(wèn)應(yīng)用的用戶(hù)來(lái)說(shuō)，很可能會(huì)感受到幾百毫秒、甚至是幾秒鐘的延遲時(shí)間。在初始等待時(shí)間過(guò)后，該功能函數(shù)會(huì)在一段時(shí)間內(nèi)保持“活躍(warm)”的狀態(tài)。此間，新的調(diào)用既不會(huì)遭遇延遲，最終用戶(hù)的響應(yīng)也會(huì)比較快。不過(guò)，在應(yīng)對(duì)同一時(shí)刻的大量流量并發(fā)時(shí)，AWS會(huì)通過(guò)擴(kuò)展更多的容器，來(lái)處理所有新的請(qǐng)求。而這將導(dǎo)致完全不同的冷啟動(dòng)序列。此外，如果功能函數(shù)需要依賴(lài)于彈性網(wǎng)絡(luò)接口(Elastic Network Interfaces，ENI-- https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html)與其他服務(wù)進(jìn)行通信，那么延遲還會(huì)增加。

可見(jiàn)，在大多數(shù)情況下，我們需要避免出現(xiàn)冷啟動(dòng)現(xiàn)象。不過(guò)，云服務(wù)平臺(tái)通常不會(huì)直接提供針對(duì)應(yīng)用程序棧的冷啟動(dòng)檢測(cè)和監(jiān)控。我們需要借用Dashbird(https://dashbird.io/features/)之類(lèi)的監(jiān)控服務(wù)，來(lái)發(fā)現(xiàn)目標(biāo)架構(gòu)中值得改進(jìn)的地方。如果您想了解更多有關(guān)如何解決冷啟動(dòng)問(wèn)題的介紹，請(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)被拒絕了。而且，此類(lèi)調(diào)用錯(cuò)誤會(huì)讓Lambda返回400或500系列的HTTP狀態(tài)代碼。具體請(qǐng)參見(jiàn)常見(jiàn)錯(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ì)通過(guò)API連接到其他SaaS工具上，如果其中的某個(gè)連接或節(jié)點(diǎn)出現(xiàn)了問(wèn)題，則會(huì)影響到正常的業(yè)務(wù)邏輯。我們可以通過(guò)由Dashbird提供的嚴(yán)重錯(cuò)誤儀表板，來(lái)快速了解應(yīng)用程序在第一次和最后一次發(fā)生特定瓶頸、或錯(cuò)誤的根本原因和具體時(shí)間。

費(fèi)用與使用量

無(wú)論是Lambda，還是AWS S3存儲(chǔ)桶、VPC、DynamoDB等資源，其費(fèi)用都是與使用量成正比的。而我們?cè)谑褂梅植际皆品?wù)時(shí)，很難有效且及時(shí)地跟蹤資源在使用過(guò)程中所產(chǎn)生的花銷(xiāo)。因此，在具體實(shí)現(xiàn)中，我們往往需要采取以帳戶(hù)級(jí)別監(jiān)控為主，功能級(jí)別監(jiān)控為輔的方法。例如，我們可以使用Dashbird應(yīng)用來(lái)統(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ú)服務(wù)器監(jiān)控的最佳實(shí)踐，請(qǐng)參考--https://sls.dashbird.io/en/serverless-best-practices。

監(jiān)控工具--AWS CloudWatch

作為L(zhǎng)ambda的內(nèi)置工具，AWS CloudWatch會(huì)根據(jù)功能、版本和容器類(lèi)型，來(lái)組織日志，并在日志中包含運(yùn)行時(shí)、容器錯(cuò)誤、以及時(shí)間戳。當(dāng)然，Lambda也會(huì)為每次調(diào)用添加各種元數(shù)據(jù)。通過(guò)收集和跟蹤各類(lèi)指標(biāo)，CloudWatch日志可以提供有關(guān)資源使用情況、應(yīng)用程序的性能、以及運(yùn)營(yíng)狀況的等基礎(chǔ)架構(gòu)范圍內(nèi)的視圖。

同時(shí)，我們可以使用其自帶的AWS Cloudwatch Alarm，來(lái)設(shè)置各種指標(biāo)警報(bào)和復(fù)合警報(bào)。據(jù)此，您可以獲悉目標(biāo)應(yīng)用正在使用的CPU和內(nèi)容的情況。而且，您還可以通過(guò)預(yù)定義事件來(lái)設(shè)置門(mén)限值，一旦達(dá)到或接近該值，就會(huì)觸發(fā)通知。因此，我建議您在構(gòu)建第一個(gè)FaaS應(yīng)用程序時(shí)，就將CloudWatch作為監(jiān)控和跟蹤的起點(diǎn)，而當(dāng)用戶(hù)和請(qǐng)求數(shù)大到一定數(shù)量級(jí)時(shí)，再引入更加全面的工具。

問(wèn)題管理與團(tuán)隊(duì)合作

任何云端應(yīng)用程序，即使是最簡(jiǎn)單的，也會(huì)頻繁地產(chǎn)生一定數(shù)量的事件與問(wèn)題，尤其是那些正在不斷開(kāi)發(fā)與迭代的應(yīng)用。因此，為了能讓開(kāi)發(fā)團(tuán)隊(duì)有效地獲悉和解決問(wèn)題，監(jiān)控平臺(tái)需要以用戶(hù)友好的方式，可視化和控制各種未解決、已解決、暫時(shí)可以被忽略的問(wèn)題。通過(guò)設(shè)置和提供清晰的工作流程，團(tuán)隊(duì)將能夠更流暢地溝通，并提出切實(shí)可行的解決方案。

質(zhì)量跟蹤

在監(jiān)控過(guò)程中，快速可視化某個(gè)事件在過(guò)去所發(fā)生過(guò)的狀況是非常重要的。它不但能夠幫助我們就某種情況開(kāi)展進(jìn)一步的調(diào)查，還可以協(xié)助我們發(fā)現(xiàn)針對(duì)某個(gè)錯(cuò)誤的修復(fù)方法。通過(guò)此類(lèi)回溯性的質(zhì)量跟蹤，我們可以避免在初始開(kāi)發(fā)和錯(cuò)誤糾正的過(guò)程中犯同樣的錯(cuò)誤，同時(shí)也能通過(guò)創(chuàng)建持續(xù)的自動(dòng)化學(xué)習(xí)和評(píng)估方法，來(lái)提高應(yīng)用的質(zhì)量與性能。

事件驅(qū)動(dòng)的調(diào)試

開(kāi)發(fā)人員雖然是監(jiān)控程序的創(chuàng)建者，但是他們并沒(méi)有責(zé)任在生產(chǎn)環(huán)境中持續(xù)監(jiān)控自己的應(yīng)用日志。那么面對(duì)大量的應(yīng)用日志，監(jiān)控系統(tǒng)就需要能夠在不錯(cuò)過(guò)關(guān)鍵內(nèi)容的前提下，提供自動(dòng)化的警報(bào)服務(wù)。也就是說(shuō)，我們需要通過(guò)自定義警報(bào)功能，來(lái)成功實(shí)現(xiàn)監(jiān)控和錯(cuò)誤調(diào)試。

在實(shí)際應(yīng)用中，警報(bào)機(jī)制不僅需要能夠檢測(cè)出應(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)參見(jiàn)-- https://dashbird.io/features/automated-alerting/。此外，對(duì)于系統(tǒng)中的容錯(cuò)組件，開(kāi)發(fā)人員則可以禁用單個(gè)問(wèn)題警報(bào)，只設(shè)置匯總之后的指標(biāo)。據(jù)此，他們不但可以得到真正所需的信息，還能夠?qū)⒆⒁饬Ψ旁趹?yīng)用調(diào)優(yōu)上。

小結(jié)

如今，大多數(shù)開(kāi)發(fā)團(tuán)隊(duì)也在使用Slack之類(lèi)即時(shí)消息服務(wù)，以更快捷、更輕松、更方便的方式，專(zhuān)注于無(wú)服務(wù)器應(yīng)用的開(kāi)發(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】