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