![1.png](https://ucc.alicdn.com/pic/developer-ecology/47befd36ec99435091c50f990837e0b8.png)

作者 | 騏羽  阿里巴巴技術專家

> **導讀**：本篇是“SpringCloud 應用在 Kubernetes 上的最佳實踐”系列文章的第六篇，主要介紹瞭如何保障生產環境服務穩定，做到隨時釋出，從而加快業務的迭代和上線速度。

相關文章推薦：

- [《SpringCloud 應用在 Kubernetes 上的最佳實踐 —— 開發篇》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247491668&idx=1&sn=c9839f78ff31d6f5da285a259d804f53&chksm=fae6eb9bcd91628d28b0db9b53a091132df7535d320aee9c85fea241dc4e964e746b83a69dc8&scene=21#wechat_redirect)

- [《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 部署篇(開發部署）》](https://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247492052&idx=1&sn=8ff93e6f7b398e6a509239910b61b975&scene=21#wechat_redirect)

- [《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 部署篇(工具部署)》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247492264&idx=1&sn=0bb4d0364b42af36886face9f3adec10&chksm=fae6e967cd916071e691a9296282755b771036a4a1182f51dadcbb3a3aebe76a6bdad298b69d&token=888059135&lang=zh_CN&scene=21#wechat_redirect)

- [《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出（可灰度）》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247492479&idx=1&sn=ac1463d4cd7b4323590766643d92dcb0&chksm=fae6e8b0cd9161a6d02057ca28971101aec9bc8ee823f0f4d12fc9b691bc8e122e542725f7ac&scene=21#wechat_redirect)

- [《SpringCloud 應用在 Kubernetes 上的最佳實踐 — 診斷（線上聯調）》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247492850&idx=1&sn=03793cf561ceca40d75b50c0c23c708e&chksm=fae6ef3dcd91662b7cd92d07beba3bab05c1ef641bce204b3f9dd80cad55ea7dd1ccee1c2109&scene=21#wechat_redirect)

# 前言

在應用釋出上線的時候我們最擔心的莫過於因為程式碼的 bug 引發業務的問題，雖然我們可以透過灰度的方式分批發布減小影響範圍，但是如果能夠在釋出的過程中從實時監控中快速的發現問題進行回滾，那麼就能縮短業務受影響的時間。因此我們可以看到**灰度、監控、回滾是整個釋出過程中不可或缺的三大利器**，有了這三大利器後，我們能夠做到隨時釋出，從而加快業務的迭代和上線速度。而監控作為基礎設施的一個重要環節，是保障生產環境服務穩定不可或缺的一部分，目前 EDAS 提供了非常豐富的監控能力，下面我們從不同的場景來詳細介紹一下這些監控能力。

# 體系化監控能力搭建

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

- 首先，如果故障產生時，最先感知到的其實是業務的受損，如交易量下跌、登陸的 UV 下跌等等；

- 而如果繼續往下鑽，如果業務叢集很大的時候，我們最先需要定位到某一個服務或者某一臺機器，這個過程如果沒有相應的工具相佐猶如大海撈針，所以一個分散式鏈路級別的應用監控會是建設 Spring Cloud 應用的很好的配搭；

- 等到我們找到了相應的服務要開始進行定位分析的時候，根據問題型別（是錯是慢？）接下來需要開始分析 JVM、記憶體、CPU 等維度的指標；
 
- 最後我們可能會發現這個問題是由於業務程式碼引起，也有可能由於基礎設施引起，而在 K8s 中，Prometheus 目前是屬於容器領域基礎監控最厲害的軍刀。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/ec205009bc954e1d9008d9a4285a53c7.png)

如上圖所示，目前 EDAS 結合阿里雲上的某些雲產品，完全能夠滿足日常的運維的需要並幫忙業務開發的同學快速的定位線上問題。

# EDAS 常規監控能力

## 1. 系統監控

應用例項的基礎監控資訊：

![3.png](https://ucc.alicdn.com/pic/developer-ecology/3802879edbae4384ae9070b0412b72cc.png)

上圖功能提供了以應用例項的維度來檢視每個例項的監控資訊，提供的 JVM / CPU / Load / 記憶體等的監控資訊也是我們經常需要關注的，當發現記憶體佔用高，並且有頻繁的 FullGCC 的情況時，我們可以透過建立記憶體快照進行分析來快速定位問題。SQL 分析的能力也能快速幫助我們定位到慢查詢用來排查問題。

## 2. 應用服務監控

應用服務介面監控資訊：

![4.png](https://ucc.alicdn.com/pic/developer-ecology/7f09e6e45d6549ee9611f5a2e57b4a96.png)

這裡提供了以介面維度的監控資訊，可以詳細的看到介面在最近一段時間的請求資訊，這裡重點介紹一下介面快照功能，透過介面快照我們可以看到該介面的請求耗時，以及請求的 TraceId，根據這個 TraceId 我們可以詳細的看到本次請求的呼叫鏈以及呼叫的方法棧。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/36e4b5a755b64a7baa82dc56938756d8.png)

![6.png](https://ucc.alicdn.com/pic/developer-ecology/c82a68d597ab4f6bb558f67f1579035a.png)

![7.png](https://ucc.alicdn.com/pic/developer-ecology/7b7d7ced4d904ae0ae5cafebf03d0521.png)

呼叫鏈路的追蹤在分散式系統下是一個必不可少的工具，尤其是在排查上下游依賴中究竟是哪個系統拖慢了整個請求非常有用，在呼叫的方法棧中可以直觀的追蹤到呼叫出錯的地方。

## 3. 應用業務監控

在 EDAS 中我們支援應用自定義業務監控，這需要我們開啟高階監控的能力。從業務的視角來衡量應用的效能和穩定性，可以透過自定義來採集業務資訊，來實時展現業務指標，幫助業務進一步完善監控資訊。詳細的監控配置可以參考 ARMS 業務監控。

## 4. Prometheus 監控

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

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

# EDAS 應用釋出場景中的監控

以阿里巴巴集團的經驗舉例子，超一半以上的大故障都是在釋出過程中產生，EDAS 針對釋出這一場景結合 Kubernetes 的能力做了結合，其中的精髓內容總結三個詞：先發、再看、再發。通俗的解釋就是可以利用 EDAS 中分批（灰度）釋出能力，同時在釋出檢視中，確保相關的指標回歸正常之後，再開始下一批發布了。

目前 EDAS 能夠提供在三個維度上的指標監控資料，用來判斷髮布是否正常，列舉如下：

## 1. 應用業務指標

目前 EDAS 以介面的維度提供了每個介面在釋出前後的總的請求數對比以及請求該比例的圖例，並且還能夠詳細的看到在釋出前後該介面的錯誤數、響應時間以及單機的請求數對比，如下圖所示：

![8.png](https://ucc.alicdn.com/pic/developer-ecology/72cb2a48ca064b4aa7b78aad7435d32c.png)

透過上圖，我們可以直觀的看到，當我們釋出後應用的介面請求是否正常，以此來判斷是否會對業務產生影響。

## 2. 應用異常

在釋出的過程中，我們也需要時刻的關注在釋出中是不是有新的異常產生，我們想要有地方能夠看到異常資訊，避免直接登入到機器上去看業務日誌，我們的釋出監控提供了日誌聚合分析的能力，可以在釋出的過程提供實時的異常日誌分析展示，如下圖所以：

![9.png](https://ucc.alicdn.com/pic/developer-ecology/f4dacc13cf314f48ab73cf826187085c.png)

## 3. 系統指標

在新的業務功能上線的時候，我們除了對業務本身的一些異常和指標進行關注外，還需要關注系統的指標，這關係到我們需要評估現有的機器是否能夠支撐我們的所有流量，是否需要進行水平擴容來更好的支援業務，我們的釋出監控系統同樣整合了系統的監控的能力，為我們的釋出過程來保駕護航，詳細的監控如下圖所示：

![10.png](https://ucc.alicdn.com/pic/developer-ecology/f646d749c004400bbc4c4b8b61d18e7a.png)

以上內容我們透過三個維度為大家展示了在整個釋出的過程中 EDAS 為我們提供的完備的監控能力，透過這個能力可以讓我們的每一次釋出都能做到不慌不忙，心中有數，每一次釋出都能平滑讓業務進行升級。同時我們也提供了檢視釋出報告的功能，將釋出監控資訊形成了一份清晰的視覺化分析報告供分享他人。

# 後續及結語

本章我們介紹了 EDAS 中提供的監控能力以及如何對 EDAS Kubernetes 叢集上的 Spring Cloud 應用在釋出的過程中如何看監控發現異常資訊，但是如果出現異常了該怎麼辦呢？接下來的文章我們將繼續介紹，當出現問題後我們如何對已經發布的應用進行快速的回滾。

## 課程推薦

去年，CNCF 與 阿里雲聯合釋出了《雲原生技術公開課》已經成為了 Kubernetes 開發者的一門“必修課”。今天，阿里雲再次集結多位具有豐富雲原生實踐經驗的技術專家，正式推出《雲原生技術實踐公開課》。課程內容由淺入深，專注講解“ 落地實踐”。還為學習者打造了真實、可操作的實驗場景，方便驗證學習成果，也為之後的實踐應用打下堅實基礎。

點選連結即可免費觀看：[https://developer.aliyun.com/learning/roadmap/cloudnative2020](https://developer.aliyun.com/learning/roadmap/cloudnative2020)

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/aXdbBJlUAQp6YPvZU3isSQ)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

SpringCloud 應用在 Kubernetes 上的最佳實踐 — 線上釋出（可監控）

相關文章