在本文中，我們演示瞭如何使用Sentry.io更好地監視無服務器應用程序中的錯誤並節省調試時間。
微服務為我們作為開發人員提供了難以置信的自由度。我們可以選擇我們的語言，並決定在何時何地部署我們的服務。但是，微服務面臨的最大挑戰之一就是弄清楚問題出在哪裡。藉助微服務，我們可以構建大型的分佈式應用程序，但這也意味著找出問題所在具有挑戰性。使用AWS Lambda等平臺時，更難跟蹤錯誤。
作為優秀的開發人員，我們編寫了單元測試和集成測試，並確保這些測試全部通過。我們與質量保證團隊一起編寫了複雜的測試方案，以確保我們的代碼按照我們的預期方式運行。但是，我們永遠無法預測的一件事就是最終用戶將如何使用該軟件。總有一些我們認為不會發生的新問題。這就是為什麼諸如Sentry.io之類的應用程序監視工具很有用的原因。這些事件可以是錯誤，但也可以是其他類型的事件。
隨著應用程序的增長和變得越來越複雜，找出問題出處的時間也隨之增加。當您將應用重新構建為事件驅動並利用無服務器計算時，這種複雜性將進一步增加。ACME Fitness Shop是ACME Fitness Shop的應用程序之一，可用來展示團隊合作的事物。ACME Fitness Shop由六個微服務組成，它們全部運行在各自的容器中並使用各自的數據存儲。
在過去的幾個月中，CloudJourney.io團隊開發了ACME Fitness Shop 的無服務器版本。當前，無服務器版本具有24個可一起使用的Lambda函數。跟蹤他們的所作所為以及事情在哪裡崩潰是很難的。現在有八個不同的Lambda函數，而不是隻有一個容器來處理所有“購物車”。
上圖中的Lambda函數與第一張圖片中基於容器的對應函數相同。實際上，您可以將基於容器的服務與無服務器服務交換，而永遠不會真正知道它們之間的區別。
儘管我們可以讓不同的團隊從事同一組功能的不同部分，但在故障排除和發現錯誤方面確實增加了一些複雜性。尤其是在無服務器的情況下，您無法打開終端會話和“ _ssh到容器_”。
儀表錯誤處理
我們選擇用於該項目錯誤監視的工具是Sentry.io。要連接到Sentry，唯一需要的值是客戶端密鑰，Sentry稱為DSN。為了確保該價值的安全性並嚴格遵循最佳實踐，您可以將其存儲在AWS Systems Manager參數存儲（SSM）中，並在使用CloudFormation（或SAM）部署應用程序時使用它。
SSM使您可以為參數創建層次結構組。使用該分層功能，我們/Sentry/Dsn在SSM中調用了該參數。在CloudFormation模板中，您可以使用參數，例如：
捕捉事件
大多數無服務器平臺會在功能完成後立即關閉所有網絡連接，並且不會等待確認。為確保Sentry接收到所有事件，您可以配置同步HTTP傳輸。連同一些其他設置，與Sentry的連接配置為：
Sentry提供了許多有用的事件，您可以發送這些事件來幫助您瞭解應用程序中發生的事情：
- Breadcrumbs：在錯誤或消息之前發生的一系列事件。
- 異常：發生了一個錯誤。
- 消息：一條日誌消息，其中包含有關事件或錯誤的其他信息。
在付款服務中，將驗證信用卡數據以確保它是有效的信用卡。當訂單沒有有效的信用卡時，其餘流程也將停止，因此這是您要捕獲的錯誤。
您會在單元測試和集成測試中發現此錯誤，但是由於它會嚴重影響您的用戶體驗，因此您可能還希望在生產過程中對其進行跟蹤。
相反也可能。如果您想捕獲應用程序的成功調用，也可以這樣做。在這種情況下，我想說的是，成功驗證信用卡後調用成功，並且消息已成功發送到需要發送的位置（在這種情況下為SQS隊列）。使用單個語句，您可以將事件發送到Sentry，以捕獲Lambda函數的成功。
跟蹤數據
在這兩種情況下，跟蹤其他數據都很重要。這些額外的數據可能意味著花費兩分鐘查看一項服務或花費一整天找出受影響的服務之間的區別。麵包屑在這裡起著至關重要的作用。在這種情況下，金額，訂單號和生成的交易ID很有用。
如果運輸服務中存在錯誤，此數據也非常有用。例如，當應該將訂單發送到運輸服務但又未被Lambda函數提取時，您可以輕鬆地找到問題所在。通過麵包屑添加此數據，例如：
到目前為止，我們已經研究了ACME Fitness Shop的無服務器組件。如前所述，也有容器版本，您可以混合和匹配零件。在這裡，跟蹤和知道錯誤發生的位置至關重要。
您不僅需要查看一個地方的日誌，還需要查看無服務器日誌和Kubernetes日誌。在基於Python的購物車服務中，我們也添加了Redis集成。只需添加一行和一個import語句，即可確保所有執行的Redis命令也能顯示出來。
不用花時間弄清楚問題出在哪裡以及如何將某些數據轉換為Redis命令，您可以直接讀取發生的事情。
隨著您的應用程序從開發，測試到生產的轉移，環境標記將幫助您跟蹤在哪種環境中發生的情況。與生產環境相比，測試環境中發生的問題不那麼緊迫。
我們設置的標籤之一稱為“ release”，即git commit的SHA。基於此，我們可以跟蹤在任何給定時間在任何環境中運行的確切提交，並查看已捕獲的事件。
這些標籤與特定範圍相關聯時，甚至可以使您將消息關聯在一起。這使您能夠查看發生錯誤時系統中所有發生的事情。可以在Sentry docs中找到一些示例，包括從應用程序前面的Nginx負載平衡器進行跟蹤。
結尾
ACME Fitness Shop的容器和Kubernetes清單位於GitHub上，ACME Serverless Fitness Shop的代碼也位於GitHub上。因此，如果您想嘗試一下，看看Sentry.io是否也為您的用例增加了價值，則可以使用我們已經構建的代碼和應用程序來做到這一點。同時，讓我們知道您的想法，並在Twitter上向Bill，Leon或團隊發送註釋。
閱讀更多 一名小白人員 的文章
