秘籍公開！如何監控無伺服器應用程式？

在60年代初，約瑟夫·卡爾·羅伯內特·利克利德（Joseph Carl Robnett Licklider）提出了透過Arpanet（網際網路的前身）隨時隨地連線人和資料的想法。然後在90年代的舊時代，由於電信公司的廣泛使用，網路和虛擬化開始普及。當公司可以透過共享資源削減成本時，這是革命性的。

從裸機到雲的過渡和演進對於小型和大型企業組織都是令人興奮的。在新千年的頂峰時期，亞馬遜，谷歌，微軟，IBM等供應商開始引入其託管雲服務。IT經理開始考慮他們可以從本地遷移到雲的速度有多快，甚至沒有質疑雲是否應該向他們遷移。

雲端計算帶來了從基礎架構和軟體到功能即服務的一切現象。分別發生了IaaS，PaaS，SaaS，然後是CaaS，FaaS等，使使用者可以管理更少的操作，並更加專注於他們的業務邏輯。雪球滾滾而來，並在2010年十年間成為對Containers的大肆宣傳，然後引領了無伺服器計算的道路。

瞭解更多開源資訊和乾貨內容歡迎關注微信公眾號“開源村OSV”

無伺服器時代

Serverless可以讓您快速開發微服務，移動應用程式和API，同時具有成本效益且無需考慮伺服器。這種新的雲端計算執行模型將利與弊的便利性提升到了一個新的水平。雲應用程式的最大問題（例如可伸縮性和成本劣勢）已變成許多情況下無伺服器方法的優勢。簡化的後端任務提高了許多開發人員的工作效率。但是，當然存在挑戰，例如資源和執行限制，監視和除錯以及安全性和隱私性。

無伺服器是高度分散式的，並且與非同步事件一起使用，這使得它們很難透過預設提供的一堆日誌進行跟蹤。雲供應商的環境通常不是開源的。因此，在大多數情況下，對無狀態功能的效能分析可能會很複雜。可觀察性是至關重要的，因為如果您不關注無伺服器應用程式，它們可能會失敗並導致諸如不可用或高昂成本之類的若干問題。傳統的APM增加了呼叫的開銷，並且無法在無狀態環境中執行。

下面，我們將使用一個無伺服器應用程式的真實示例，並展示如何透過使用分散式跟蹤來提高其可見性。

什麼是Thundra？

Thundra最初是Opsgenie（一家提醒功能和通話管理解決方案商）內部的一個內部專案，旨在使工程團隊能夠最佳化資源並解決問題，同時遷移到AWS中的無伺服器。然後在2018年，Thundra從Opsgenie分離出來，後者被Atlassian收購。Thundra應用程式可觀察性和安全性平臺為無伺服器中心，容器和虛擬機器工作負載提供了端到端可見性，異常檢測，除錯，故障排除，警報和自動操作。Thundra可以以精確定位問題的方式共同提供應用程式管理，安全性和合規性。

Thundra有助於提高效能，最佳化成本並將MTTR降低多達80％。客戶可以在幾分鐘內瞭解應用程式的行為並進行故障排除。Thundra的安全護欄和合規性有助於透過白名單/黑名單策略防止安全漏洞並自動檢測異常，因此發現瓶頸和檢測開發和生產中的問題的速度提高了90％！Thundra還使客戶能夠線上和離線逐行除錯以無伺服器為中心的應用程式。

Thundra幫助軟體團隊解決非同步，分散式無伺服器環境中的複雜問題。憑藉靈活的查詢和警報功能，以及彙總指標，日誌和跟蹤的豐富視覺化，軟體團隊可以快速響應事件並解決其無伺服器和容器化環境中的效能問題。所有這些操作都透過簡單的設定即可完成，並且沒有額外的開銷。Thundra使其使用者能夠在AWS中除錯，監視，排除故障並保護其無伺服器和容器化環境，並透過包裝AWS Lambda函式來生成程式碼或來自Amazon Cloudwatch服務的連結來檢測程式碼，然後收集資料。Thundra還幫助開發人員在產品開發階段進行本地除錯，並在生產階段進行實時監控。

對於那些擔心開銷（這意味著增加AWS Lambda函式的執行時間）的人，Thundra提供了另一種稱為“非同步監視”的整合方法。Thundra透過CloudWatch釋出監視資料，這被AWS視為最佳實踐，如其“ 使用AWS Lambda的無伺服器架構 ”白皮書中所述。透過使用非同步監視，客戶無需擔心由於Thundra而導致的功能故障，因為Thundra的Lambda會獨立傳送資料執行。使用非同步監視的最重要優點是將日誌寫入Cloudwatch僅會給Lambda增加可忽略的開銷。

一則例項

讓我們用一個真實的例子來演示Thundra的好處。我們將使用部落格應用程式來演示Thundra如何透過分散式跟蹤來提高客戶的無伺服器應用程式的可見性。該應用程式具有兩種不同的角色：部落格作者和編輯者。使用部落格應用程式，部落格作者可以提交其草稿，獲得反饋以及編輯/刪除其部落格文章。該應用程式還允許編輯者檢視草稿，提交反饋並在準備就緒時釋出部落格。

部落格應用程式設計為無伺服器正規化，並分解為許多小的Lambda函式，它們的責任很小，特權最少。當第一個請求進入系統時，非同步呼叫鏈從Lambda函式之間流動的事件開始。這稱為“業務流”，它表示有意義的呼叫鏈，這些呼叫可以為軟體使用者實現真正的工作。例如，當作者提交部落格帖子時，便開始了使該部落格帖子準備好進行審閱的業務流程。

讓我們仔細看看下圖。

可以在上面的螢幕快照中看到業務流程，該螢幕快照來自Thundra控制檯，並且是自動繪製的。

讓我們一一介紹這些操作：部落格應用程式應立即顯示一條訊息，說明該帖子已儲存，並將由編輯者進行稽核。新的部落格帖子被提取到SQS佇列中。Lambda接管了SQS的作用，並向SNS釋出訊息以通知編輯。相同的Lambda會儲存部落格文章，以便編輯可以使用它進行審查。從DynamoDB記錄中，另一個Lambda被觸發，並將內容寫入具有必要索引的Elasticsearch表中，以便可以在數百萬部落格帖子中進行搜尋。

從開發人員的角度來看所有這些問題時，很難在本地複製生產中發生的問題以瞭解“後臺”應用程式的行為。所有這些問題都可以用一個短語來概括：瞭解應用程式行為和維持應用程式健康。我們相信瞭解應用程式執行狀況的三大支柱：可觀察性，除錯/測試和安全性/合規性。

微服務的可觀察性

我們進入了自動觀測的新時代。當企業遷移到以無伺服器為中心的工作負載時，基於事件的體系結構被用來應對複雜的業務邏輯和非同步程式設計模型。

Thundra定義了可觀察性的三個支柱：指標、痕跡、日誌。

開發人員可以減少跨多種工具的上下文切換。開發人員可以使用真正的端到端管理平臺來跨無伺服器架構的分散式應用程式，而不必使用多種工具來應用Observability Engineering的特性。預設情況下，Thundra包括17個指標（某些特定於執行時的規範，例如Java或Go），可以提供以下內容：呼叫計數、呼叫持續時間、記憶體使用、CPU百分比、磁碟IO位元組、處理記憶體使用情況、執行緒數、GC計數。

透過與Open Tracing相容，Thundra提供了完整的跟蹤功能，包括本地和分散式跟蹤，您可以在其中檢查Lambda與其他資源的互動。

在同一個儀表板中，開發人員可以快速進入日誌，輕鬆進行呼叫和跟蹤連線。

藉助從不同角度（例如持續時間，錯誤，成本，資源消耗）進行檢視的能力，Thundra幫助使用者查明AWS Lambda函式和其他資源中錯誤的根本原因。錯誤，冷啟動和超時因此可以大大減少。Thundra使您能夠了解無狀態環境中錯誤背後的問題，並毫不費力地跟蹤第三方API和資源的執行狀況。

無伺服器應用程式的實時除錯

由於開發人員無法訪問基礎架構，因此他們現在除錯無伺服器應用程式所需的唯一資源就是呼叫後列印的日誌。但是，編寫新的日誌行，部署功能並再次檢查日誌需要花費大量時間。分步除錯，設定斷點和檢查變數可以提高開發人員效率。在某種程度上，AWS Toolkit和SAM使您可以輕鬆地在本地環境上執行逐步除錯。但是，由於許可權，觸發器和VPC配置的原因，很難在本地重新建立相同的AWS環境。有時，在不進行實時除錯的情況下對問題進行故障排除可能既複雜又耗時。但是，能夠在IDE上傳統除錯的舒適度下使用逐步除錯實時功能，是完成該任務的便捷方法。

為了提供與開發人員在AWS環境中的Lambdas本地環境相同的除錯體驗，Thundra釋出了其Online Debugger。該工具使開發人員能夠在其本機環境中除錯Lambda函式並使用其IDE，從而使他們能夠執行傳統的除錯任務，例如設定斷點以及檢視和更改變數。客戶只需更改一些配置即可完成此操作，而無需修改其程式碼。線上偵錯程式還支援Java，Nodejs和Python執行時。為了使除錯更加容易，Thundra釋出了Nodejs，Python的VSCode外掛和Java的Intellij外掛。對於其他環境，它釋出了Python客戶端。

執行後除錯

應用程式團隊需要一種不同的監視方法來跟蹤功能之間傳遞的所有非同步訊息，因為老式的指標和日誌監視對這種分散式系統沒有幫助。開發人員需要更多按時間順序排列的高基數資料，以顯示非同步體系結構的行為。分散式跟蹤得以解救，解決了理解現代應用程式行為和維護應用程式健康的痛苦點。

分散式跟蹤在大多數情況下時間可能會很短，因為所有業務邏輯仍然在函式內部而不是在函式之間發生。當大型Lambda函式出現任何問題時，開發人員將只留下日誌；在這種情況下，應在應用程式中仔細放置一種結構化的日誌記錄機制，以有效地使用日誌。但是，這需要大量的手動工作，並且仍然會汙染程式碼。在這種註定的情況下，開發人員很樂意使用類似IDE的經驗來除錯這些應用程式。這樣，開發人員可以遍歷業務邏輯以檢視執行程式碼後是否發生了意外情況。為了滿足此需求，Thundra的離線除錯功能使開發人員可以在完成執行後除錯無伺服器功能。

安全護欄

安全是一個至關重要的主題，即使在無伺服器等託管環境中也應謹慎處理。無伺服器計算自其誕生以來就已經發展起來，它使每個組織都可以快速行動，而無需考慮幕後情況。這導致了適合無伺服器生態系統的新服務爆炸。與非無伺服器環境相比，無伺服器環境的脆弱性較小。但是，這並不意味著不會發生安全漏洞。在大多數情況下，保護無伺服器應用程式就是確保您緊密關閉了潛在的安全漏洞，例如區分敏感資料和非敏感資料。與無伺服器相關技術的許多安全漏洞來自錯誤配置，該錯誤配置公開暴露了非公共資訊。

在構建無伺服器應用程式時，要克服的一個共同問題是限制在AWS Lambda函式內部進行的內部API呼叫。從外部，您可以使用AWS IAM許可權來限制這些許可權，但這隻會對AWS資源訪問產生影響。

如果您想阻止所有API URL（安全團隊批准的URL除外）該怎麼辦？這將需要在AWS Lambda之上使用一些額外的工具來檢查在AWS Lambda函式中正在發出哪些請求，然後根據您定義的內容採取措施。

在上圖中，我們可以看到我們對AWS Lambda函式具有一些現有的AWS IAM許可權。我們還可以看到，我們新增了一個列入黑名單的資源，該資源將阻止對SQS的所有讀取請求。

如您所見，我們有兩個選擇：一是提醒並通知我，二是阻止並通知我。

如果選擇“警報”，則AWS Lambda執行將繼續執行；否則，將繼續執行。但是，正如名稱和描述所暗示的那樣，將向您的團隊傳送一條訊息，讓他們知道發生了什麼。

另一個“阻止”選項會停止操作。這意味著您的AWS Lambda執行將停止。如果您在需要高階別安全性的高度關鍵的應用程式上工作，並且整個公司和開發團隊都採用了嚴格的安全策略，那麼此選項可能是值得的。

結論

在受益於最新雲技術的同時構建微服務的複雜性通常被證明是開發人員的負擔。工程團隊和DevOps團隊在開發或生產階段都可能面臨可觀察性的挑戰，這可能會對成本和效率產生不利影響。Thundra的無伺服器可觀察性平臺用於測試，除錯，監視，故障排除和保護無伺服器應用程式，可提供彙總指標，日誌和跟蹤的豐富視覺化。我們很高興將Thundra可以減輕工具負擔的工具。