五原則之監控微服務

五原則之監控微服務
導讀我們對微服務的需求可以歸納為一個詞：速度。這種更快提供功能完善且可靠的軟體的需求，徹底改變了軟體開發模式。毫無疑問，這個改變對軟體管理，包括系統監控的方式，都產生了影響。在這篇文章裡，我們將重點關注放在有效地監控產品環境中的微服務所需做出的主要改變。我們將為這一新的軟體架構擬定 5 條指導性原則來調整你的監控方法。

監控是微服務控制系統的關鍵區段，你的軟體越複雜，那麼你就越難瞭解其效能及問題排障。鑒於軟體交付發生的巨大改變，監控系統同樣需要進行徹底的改造，以便在微服務環境下表現更好。下面我們將介紹監控微服務的 5 條原則，如下：

1. 監控容器及其裡面的東西。
2. 在服務效能上做監控，而不是容器效能。
3. 監控彈性和多地部署的服務。
4. 監控 API。
5. 將您的監控映射到您的組織圖。

利用這 5 條原則，你可以在向微服務前進的道路上，建立更有效對微服務的監控。這些原則，可以讓你應對隨著微服務而來的技術變化和組織變化。

微服務監控的原則監控容器及其裡面的東西

容器因構建微服務而凸顯其重要性，容器的速度、可移植性和隔離特性讓開發人員很容易就愛上了微服務模型。容器的好處已經寫的夠多了，毋庸贅述。

容器對於其外圍的系統來說就像是黑盒子。這對於開發來說大有裨益，從開發環境到生產環境，甚至從開發人員的筆記本到雲端，為它們帶來高度的可移植性。但是當運行起來後，監控和解決服務問題時，這個黑盒子讓常規的方法難以奏效了，我們會想：容器裡到底在運行著什嗎？程式和代碼運行效能如何？它有什麼重要的輸出指標嗎？從 DevOps 的視角，你需要對容器有更深的瞭解而不是僅僅知道有一些容器的存在。

非容器環境下衡量的典型做法，是讓一個代理程式運行在主機或者虛機上的使用者空間裡，但這並不適用於容器。因為容器的優點是小，將各種進程分離開來，並儘可能的減少依賴關係。

而且，從規模上看，成千上萬的監測代理，對即使是一個中等大小的部署都是一個昂貴的資源浪費和管理的噩夢。對於容器有兩個潛在的解決方案：1）要求你的開發人員直接監控他們的代碼，或者2）利用一個通用的核心級的檢測方法來查看主機上的所有應用程式和容器活動。這裡我們不會深入說明，但每一種方法都有其優點和缺點。

利用商務程序系統提醒服務效能

理解容器容器中的運行資料並不容易，一個單一容器相比組成一個功能或服務的容器彙總，測量複雜度要低得多。

這特別適用於應用程式層級的資訊，比如哪個請求擁有最短回應時間，或者哪些 URL 遇到最多的錯誤，但它同樣也適用於架構層級的監測，比如哪個服務的容器使用 CPU 資源超過了事先分配的資源數。

越來越多的軟體部署需要一個編排系統orchestration system，將應用程式的邏輯規劃轉化到物理的容器中。常見的編排系統包括 Kubernetes、Mesosphere DC/OS 和 Docker Swarm。團隊可以用一個編排系統來（1）定義微服務（2）理解部署的每個服務的目前狀態。你可以認為編排系統甚至比容器還重要。容器是短暫的，只有滿足你的服務需求才會存在。

DevOps 團隊應該將警示重點放到運行特徵上，以儘可能貼近監控服務的體驗。如果應用受到了影響，這些警示是評估事態的第一道防線。但是獲得這些警示並不容易，除非你的監控系統是基於原生於容器的。

原生容器Container-native解決方案利用編排中繼資料orchestration metadata來動態彙總容器和應用程式資料，並按每個服務計算監控度量。根據您的編排工具，您可能想在不同層次進行深入檢測。比如，在 Kubernetes 裡，你通常有 Namespace、ReplicaSet、Pod 和一些其他容器。彙總這些不同的層，對排除邏輯故障是很有必要的，與構成服務的容器的物理部署無關。

監控彈性的服務

彈性服務不是一個新概念，但是它在原生容器環境中的變化速度比在虛擬環境中快的多。迅速的變化會嚴重影響檢測系統的正常運行。

監測傳統的系統經常需要根據軟體部署，手動調整檢查指標。這種調整可以是具體的，如定義要捕獲的單個指標，或基於應用程式在一個特定的容器中的操作配置要收集的資料。在小規模上（比如幾十個容器）我們可以接受，但是再大規模就難以承受了。微服務的集中監控必須能夠自由的隨彈性服務而增長和縮減，無需人工幹預。

比如，如果 DevOps 團隊必須手動定義容器包含哪個服務需要監控，他們毫無疑問會失手，因為 Kubernetes 或者 Mesos 每天都會定期建立新的容器。同樣，如果代碼發布共置於生產環境時要求營運團隊安裝一個定製的狀態端點custom stats endpoint，也給開發人員從 Docker 倉庫擷取基礎鏡像帶來更多的挑戰。

在生產環境中，建立面向跨越多個資料中心或多個雲的複雜部署的監控，比如，如果你的服務跨越私人資料中心和 AWS，那麼亞馬遜的 AWS CloudWatch 就很難做到這一點。這就要求我們建立一個跨不同地區的監控系統，並可在動態原生容器環境下運行。

監控 API

在微服務環境中，API 介面是通用的。本質上，它們是將服務暴露給其它團隊的唯一組件。事實上，API 的響應和一致性可以看作是“內部 SLA”，即使還沒有定義一個正式的 SLA（服務等級協議）。

因此，API 介面的監控也是必要的。API 監控可以有不同的形式，但是很顯然它絕對不是簡單的二進位上下檢查。例如，瞭解像時間函數這樣的最常使用的端點endpoint是有價值的。這使得團隊可以看到服務使用的變化，無論是由於設計變更或使用者的改變。

你也可以記錄服務最緩慢的端點，這些可能揭示出重大的問題，或者至少指向需要在系統中做最佳化的地區。

最後，跟蹤系統服務響應的能力是另一個很重要的能力，它主要是開發人員使用，也能協助你瞭解整體使用者體驗，同時將資訊基於底層和應用程式視角分成兩大部分。

將您的監控映射到您的組織圖

這篇文章著重在微服務和監控上，像其他科技文章一樣，這是因為很多人都關注此層面。

對於那些熟悉康威定律Conway’s law的人來說，系統的設計是基於Team Dev的組織圖。創造更快，更敏捷的軟體的壓力推動了團隊去思考重新調整他們的開發組織和管理它的規則。

所以，如果他們想從這個新的軟體架構（微服務）上獲益，他們的團隊必須將微服務對應到團隊自身中。也就是說，他們需要更小的更鬆散耦合的團隊，可以選擇自己的方向只要能夠滿足整個需求即可。在每一個團隊中，對於開發語言的使用，bug 的提交甚至工作職責都會有更大的控制能力。

DevOps 團隊對此可以啟用一個監控平台：讓每一個微服務團隊可以有自己的警報，度量指標，和控制台，同時也要給出整體系統的視圖。

總結

讓微服務流行起來的是快捷。開發組織要想更快的為客戶提供更多的功能，然後微服務技術就來了，架構轉向微服務並且容器的流行讓快捷開發成為可能，所有相關的進程理所當然的搭上了這輛火車。

最後，基本的監控原則需要適應伴隨微服務而來的技術和結構。越早認識到這種轉變的Team Dev，能更早更容易的適應微服務這一新的架構。

原文來自：https://linux.cn/article-8034-1.html

本文地址：http://www.linuxprobe.com/5-principles-monitoring.html