SpringCloud 應用在 Kubernetes 上的最佳實踐 -- 線上發佈

前言

在應用發佈上線的時候咱們最擔憂的莫過於由於代碼的bug引起業務的問題,雖然咱們能夠經過灰度的方式分批發布減少影響範圍,可是若是可以在發佈的過程當中從實時監控中快速的發現問題進行回滾,那麼就能縮短業務受影響的時間。所以咱們能夠看到灰度、監控、回滾是整個發佈過程當中不可或缺的三大利器,有了這三大利器後,咱們可以作到隨時發佈,從而加快業務的迭代和上線速度。而監控做爲基礎設施的一個重要環節,是保障生產環境服務穩定不可或缺的一部分,目前EDAS提供了很是豐富的監控能力,下面咱們從不一樣的場景來詳細介紹一下這些監控能力。html

體系化監控能力搭建

監控體系,最怕的就是有覆蓋不到的地方,一個覆蓋全面的監控應該是從基礎設施到上層應用均有對應的手段去覆蓋:運維

  • 首先,若是故障產生時,最早感知到的實際上是業務的受損,如交易量下跌、登錄的 UV 下跌等等。
  • 而若是繼續往下鑽,若是業務集羣很大的時候,咱們最早須要定位到某一個服務或者某一臺機器,這個過程若是沒有相應的工具相佐猶如大海撈針,因此一個分佈式鏈路級別的應用監控會是建設 Spring Cloud 應用的很好的配搭。
  • 等到咱們找到了相應的服務要開始進行定位分析的時候,根據問題類型(是錯是慢?)接下來須要開始分析 JVM、內存、CPU 等維度的指標。
  • 最後咱們可能會發現這個問題是因爲業務代碼引發,也有可能因爲基礎設施引發,而在 K8S 中,Prometheus 目前是屬於容器領域基礎監控最厲害的軍刀。

1.png

如上圖所示,目前 EDAS 結合阿里雲上的某些雲產品,徹底可以知足平常的運維的須要並幫忙業務開發的同窗快速的定位線上問題。分佈式

EDAS常規監控能力

系統監控

應用實例的基礎監控信息:工具

上圖功能提供了以應用實例的維度來查看每一個實例的監控信息,提供的JVM/CPU/Load/內存等的監控信息也是咱們常常須要關注的,當發現內存佔用高,而且有頻繁的FullGCC的狀況時,咱們能夠經過建立內存快照進行分析來快速定位問題。SQL分析的能力也能快速幫助咱們定位到慢查詢用來排查問題。性能

應用服務監控

應用服務接口監控信息:阿里雲

2.png

這裏提供了以接口維度的監控信息,能夠詳細的看到接口在最近一段時間的請求信息,這裏重點介紹一下接口快照功能,經過接口快照咱們能夠看到該接口的請求耗時,以及請求的TraceId,根據這個TraceId咱們能夠詳細的看到本次請求的調用鏈以及調用的方法棧。spa

3.png
這裏提供了以接口維度的監控信息,能夠詳細的看到接口在最近一段時間的請求信息,這裏重點介紹一下接口快照功能,經過接口快照咱們能夠看到該接口的請求耗時,以及請求的TraceId,根據這個TraceId咱們能夠詳細的看到本次請求的調用鏈以及調用的方法棧。
4.png日誌

5.png

調用鏈路的追蹤在分佈式系統下是一個必不可少的工具,尤爲是在排查上下游依賴中到底是哪一個系統拖慢了整個請求很是有用,在調用的方法棧中能夠直觀的追蹤到調用出錯的地方。cdn

應用業務監控

在EDAS中咱們支持應用自定義業務監控,這須要咱們開啓高級監控的能力。從業務的視角來衡量應用的性能和穩定性,能夠經過自定義來採集業務信息,來實時展示業務指標,幫助業務進一步完善監控信息。詳細的監控配置能夠參考ARMS業務監控htm

Prometheus監控

監控產品的歷史由來已久,可是隨着雲原生技術的持續火熱,Prometheus 做爲新生代的開源監控系統,慢慢成爲了雲原生體系的事實標準。而在EDAS中的高級監控產品ARMS已經全面對接開源Prometheus生態,支持類型豐富的組件監控,提供多種開箱即用的預置監控大盤,且提供全面託管的Prometheus服務,更多的詳細內容能夠參考ARMS Prometheus

經過以上這些監控能力,能夠大大縮短線上問題從發現到定位再到解決的時間,提升開發和運維人員排查和解決問題的效率。

EDAS應用發佈場景中的監控

以阿里巴巴集團的經驗舉例子,超一半以上的大故障都是在發佈過程當中產生,EDAS 針對發佈這一場景結合 Kubernetes 的能力作告終合,其中的精髓內容總結三個詞:先發再看再發。通俗的解釋就是能夠利用 EDAS 中分批(灰度)發佈能力,同時在發佈視圖中,確保相關的指標迴歸正常以後,再開始下一批發布了。

目前EDAS可以提供在三個維度上的指標監控數據,用來判斷髮布是否正常,列舉以下:

應用業務指標

目前EDAS以接口的維度提供了每一個接口在發佈先後的總的請求數對比以及請求該比例的圖例,而且還可以詳細的看到在發佈先後該接口的錯誤數、響應時間以及單機的請求數對比,以下圖所示:

6.png

經過上圖,咱們能夠直觀的看到,當咱們發佈後應用的接口請求是否正常,以此來判斷是否會對業務產生影響。

應用異常

在發佈的過程當中,咱們也須要時刻的關注在發佈中是否是有新的異常產生,咱們想要有地方可以看到異常信息,避免直接登陸到機器上去看業務日誌,咱們的發佈監控提供了日誌聚合分析的能力,能夠在發佈的過程提供實時的異常日誌分析展現,以下圖因此:

7.png

系統指標

在新的業務功能上線的時候,咱們除了對業務自己的一些異常和指標進行關注外,還須要關注系統的指標,這關係到咱們須要評估現有的機器是否可以支撐咱們的全部流量,是否須要進行水平擴容來更好的支持業務,咱們的發佈監控系統一樣集成了系統的監控的能力,爲咱們的發佈過程來保駕護航,詳細的監控以下圖所示:

8.png

以上內容咱們經過三個維度爲你們展現了在整個發佈的過程當中EDAS爲咱們提供的完備的監控能力,經過這個能力可讓咱們的每一次發佈都能作到鎮定自若,心中有數,每一次發佈都能平滑讓業務進行升級。同時咱們也提供了查看發佈報告的功能,將發佈監控信息造成了一份清晰的可視化分析報告供分享他人。

後續及結語

本章咱們介紹了EDAS中提供的監控能力以及如何對EDAS Kubernetes集羣上的Spring Cloud應用在發佈的過程當中如何看監控發現異常信息,可是若是出現異常了該怎麼辦呢?接下來的文章咱們將繼續介紹,當出現問題後咱們如何對已經發布的應用進行快速的回滾。

本文爲阿里雲原創內容,未經容許不得轉載。

相關文章
相關標籤/搜索