云應(yīng)用容器的向左監(jiān)控方法

作者：科技狠活與軟件技術(shù) 2023-08-30 16:12:03

云計算 在彈性容器化環(huán)境中，擁有低效代碼是非常昂貴的。通過向左監(jiān)控方法和可觀測性解決方案，可以幫助解決這個問題。

在彈性容器化環(huán)境中，擁有低效代碼是非常昂貴的。通過向左監(jiān)控方法和可觀測性解決方案，可以幫助解決這個問題。

向左移動（Shift-left）是一種軟件開發(fā)和運(yùn)維的方法，強(qiáng)調(diào)在軟件開發(fā)生命周期的早期進(jìn)行測試、監(jiān)控和自動化。向左移動的目標(biāo)是在問題出現(xiàn)之前及時發(fā)現(xiàn)并迅速解決，以防止問題的發(fā)生。

當(dāng)您早期識別到可擴(kuò)展性問題或錯誤時，解決起來更快、更具成本效益。將低效代碼轉(zhuǎn)移到云容器中可能非常昂貴，因為它可能會激活自動擴(kuò)展功能，增加您的月度費(fèi)用。此外，在您能夠識別、隔離和修復(fù)問題之前，您將處于緊急狀態(tài)。

問題陳述

我想給您演示一個案例，我們成功地避免了一個潛在的應(yīng)用程序問題，在生產(chǎn)環(huán)境中可能會造成重大影響。

2022年我們的Kubernetes報告提供了關(guān)于團(tuán)隊如何利用Kubernetes、AI中的K8s、集群可觀測性方面的見解等內(nèi)容。

我正在審查最近應(yīng)用程序更改后的UAT基礎(chǔ)架構(gòu)的性能報告。這是一個使用MariaDB作為后端、運(yùn)行在Apache反向代理和AWS應(yīng)用負(fù)載均衡器后面的Spring Boot微服務(wù)。新功能成功集成，并且通過了所有UAT測試用例。然而，我注意到MariaDB性能儀表板中的性能圖表與部署前的模式有所偏離。

以下是事件的時間軸。

8月6日14:13，應(yīng)用程序使用包含嵌入式Tomcat的新Spring Boot jar文件重新啟動。

14:52，MariaDB的查詢處理速率從每秒0.1增加到88次查詢/秒，然后增加到301次查詢/秒。

此外，系統(tǒng)CPU利用率從1%提高到6%。

最后，JVM在G1 Young Generation Garbage Collection上花費(fèi)的時間從0%增加到0.1%，并保持在這個水平。

該應(yīng)用程序在UAT階段異常地發(fā)出300次查詢/秒，遠(yuǎn)遠(yuǎn)超出了其設(shè)計要求。新功能導(dǎo)致數(shù)據(jù)庫連接增加，因此查詢量顯著增加。然而，監(jiān)控儀表板顯示，在部署新版本之前，問題措施是正常的。

解決方案

這是一個使用JPA查詢MariaDB的Spring Boot應(yīng)用程序。該應(yīng)用程序的設(shè)計是在兩個容器上運(yùn)行以實(shí)現(xiàn)最小負(fù)載，但可以擴(kuò)展到十個容器。

如果一個單獨(dú)的容器可以生成每秒300次查詢，那么如果所有十個容器都運(yùn)行，它可以處理每秒3000次查詢嗎？數(shù)據(jù)庫能否擁有足夠的連接來滿足應(yīng)用程序其他部分的需求？

我們別無選擇，只能返回開發(fā)人員的工作臺，檢查Git中的更改。

新的更改將從一個表中獲取少量記錄并進(jìn)行處理。這是我們在服務(wù)類中觀察到的代碼。

List findAll = this.xRepository.findAll();

不，使用Spring的CrudRepository的findAll()方法而沒有分頁是低效的。分頁有助于減少從數(shù)據(jù)庫檢索數(shù)據(jù)所需的時間，通過限制獲取的數(shù)據(jù)量。這是我們主要的關(guān)系型數(shù)據(jù)庫（RDBMS）教育所教導(dǎo)我們的。此外，分頁有助于保持內(nèi)存使用低，以防止應(yīng)用程序由于數(shù)據(jù)過載而崩潰，并減少Java虛擬機(jī)的垃圾回收工作量，正如前面問題陳述中提到的。

這個測試是在一個容器中使用2000條記錄進(jìn)行的。如果這段代碼被部署到生產(chǎn)環(huán)境中，其中每個容器有約20萬條記錄，那么可能會給團(tuán)隊帶來很大的壓力和憂慮。

應(yīng)用程序在將方法添加WHERE子句后重新構(gòu)建。

List findAll =
this.xRepository.findAllByY(Y);

恢復(fù)了正常運(yùn)行。每秒查詢數(shù)從300降至30，垃圾收集的工作量恢復(fù)到原始水平。此外，系統(tǒng)的CPU使用率降低。

學(xué)習(xí)和總結(jié)

任何從事站點(diǎn)可靠性工程（SRE）工作的人都會理解這個發(fā)現(xiàn)的重要性。我們能夠在不提高嚴(yán)重性1級別的情況下采取行動。如果這個有缺陷的軟件包部署到生產(chǎn)環(huán)境中，可能會觸發(fā)客戶的自動擴(kuò)展閾值，即使沒有額外的用戶負(fù)載，也會啟動新的容器。

這個故事有三個主要的要點(diǎn)。

首先，最好從一開始就啟用一個可觀測性解決方案，因為它可以提供事件的歷史記錄，用于識別潛在問題。如果沒有這個歷史記錄，我可能不會認(rèn)真對待0.1%的垃圾回收百分比和6%的CPU消耗，代碼可能會發(fā)布到生產(chǎn)環(huán)境中，造成災(zāi)難性的后果。擴(kuò)大監(jiān)控解決方案的范圍到UAT服務(wù)器有助于團(tuán)隊在問題發(fā)生前識別潛在根本原因并防止問題發(fā)生。

其次，在測試過程中應(yīng)存在與性能相關(guān)的測試用例，并由具有可觀測性經(jīng)驗的人員進(jìn)行審查。這將確保對代碼的功能和性能進(jìn)行測試。

第三，云原生的性能跟蹤技術(shù)對于接收有關(guān)高利用率、可用性等方面的警報非常有用。為了實(shí)現(xiàn)可觀測性，您可能需要準(zhǔn)備合適的工具和專業(yè)知識。祝編碼愉快！

新聞標(biāo)題：云應(yīng)用容器的向左監(jiān)控方法
當(dāng)前鏈接：http://m.5511xx.com/article/djhdjdj.html