我們對微服務的需求可以歸納為一個詞：速度。這種更快提供功能完善且可靠的軟件的需求，徹底改變了軟件開發模式。毫無疑問，這個改變對軟件管理，包括系統監控的方式，都產生了影響。在這篇文章里，我們將重點關注放在有效地監控產品環境中的微服務所需做出的主要改變。我們將為這一新的軟件架構擬定 5 條指導性原則來調整你的監控方法。
監控是微服務控制系統的關鍵部分，你的軟件越復雜，那么你就越難了解其性能及問題排障。鑒于軟件交付發生的巨大改變，監控系統同樣需要進行徹底的改造，以便在微服務環境下表現更好。下面我們將介紹監控微服務的 5 條原則，如下：
監控容器及其里面的東西。
在服務性能上做監控，而不是容器性能。
監控彈性和多地部署的服務。
監控 API。
將您的監控映射到您的組織結構。
利用這 5 條原則，你可以在向微服務前進的道路上，建立更有效的對微服務的監控。這些原則，可以讓你應對隨著微服務而來的技術變化和組織變化。
微服務監控的原則
1、監控容器及其里面的東西
容器因構建微服務而凸顯其重要性，容器的速度、可移植性和隔離特性讓開發者很容易就愛上了微服務模型。容器的好處已經寫的夠多了，毋庸贅述。
容器對于其外圍的系統來說就像是黑盒子。這對于開發來說大有裨益，從開發環境到生產環境，甚至從開發者的筆記本到云端，為它們帶來高度的可移植性。但是當運行起來后，監控和解決服務問題時，這個黑盒子讓常規的方法難以奏效了，我們會想：容器里到底在運行著什么?程序和代碼運行性能如何?它有什么重要的輸出指標嗎?從 DevOps 的視角，你需要對容器有更深的了解而不是僅僅知道有一些容器的存在。
非容器環境下衡量的典型做法，是讓一個代理程序運行在主機或者虛機上的用戶空間里，但這并不適用于容器。因為容器的優點是小，將各種進程分離開來，并盡可能的減少依賴關系。
而且，從規模上看，成千上萬的監測代理，對即使是一個中等大小的部署都是一個昂貴的資源浪費和管理的噩夢。對于容器有兩個潛在的解決方案：1)要求你的開發人員直接監控他們的代碼，或者2)利用一個通用的內核級的檢測方法來查看主機上的所有應用程序和容器活動。這里我們不會深入說明，但每一種方法都有其優點和缺點。
2、 利用業務流程系統提醒服務性能
理解容器容器中的運行數據并不容易，一個單一容器相比組成一個功能或服務的容器聚合，測量復雜度要低得多。
這特別適用于應用程序級別的信息，比如哪個請求擁有最短響應時間，或者哪些 URL 遇到最多的錯誤，但它同樣也適用于架構級別的監測，比如哪個服務的容器使用 CPU 資源超過了事先分配的資源數。
越來越多的軟件部署需要一個編排系統orchestration system，將應用程序的邏輯規劃轉化到物理的容器中。常見的編排系統包括 Kubernetes、Mesosphere DC/OS 和 Docker Swarm。團隊可以用一個編排系統來(1)定義微服務(2)理解部署的每個服務的當前狀態。你可以認為編排系統甚至比容器還重要。容器是短暫的，只有滿足你的服務需求才會存在。
DevOps 團隊應該將告警重點放到運行特征上，以盡可能貼近監控服務的體驗。如果應用受到了影響，這些告警是評估事態的第一道防線。但是獲得這些告警并不容易，除非你的監控系統是基于原生于容器的。
原生容器Container-native解決方案利用編排元數據orchestration metadata來動態聚合容器和應用程序數據，并按每個服務計算監控度量。根據您的編排工具，您可能想在不同層次進行深入檢測。比如，在 Kubernetes 里，你通常有 Namespace、ReplicaSet、Pod 和一些其他容器。聚合這些不同的層，對排除邏輯故障是很有必要的，與構成服務的容器的物理部署無關。
3、 監控彈性Elastic和多地部署Multi-Location的服務
彈性服務不是一個新概念，但是它在原生容器環境中的變化速度比在虛擬環境中快的多。迅速的變化會嚴重影響檢測系統的正常運行。
監測傳統的系統經常需要根據軟件部署，手動調整檢查指標。這種調整可以是具體的，如定義要捕獲的單個指標，或基于應用程序在一個特定的容器中的操作配置要收集的數據。在小規模上(比如幾十個容器)我們可以接受，但是再大規模就難以承受了。微服務的集中監控必須能夠自由的隨彈性服務而增長和縮減，無需人工干預。
比如，如果 DevOps 團隊必須手動定義容器包含哪個服務需要監控，他們毫無疑問會失手，因為 Kubernetes 或者 Mesos 每天都會定期創建新的容器。同樣，如果代碼發布并置于生產環境時要求運維團隊安裝一個定制的狀態端點custom stats endpoint，也給開發者從 Docker 倉庫獲取基礎鏡像帶來更多的挑戰。
在生產環境中，建立面向跨越多個數據中心或多個云的復雜部署的監控，比如，如果你的服務跨越私有數據中心和 AWS，那么亞馬遜的 AWS CloudWatch 就很難做到這一點。這就要求我們建立一個跨不同地域的監控系統，并可在動態的原生容器環境下運行。
4、 監控 API
在微服務環境中，API 接口是通用的。本質上，它們是將服務暴露給其它團隊的唯一組件。事實上，API 的響應和一致性可以看作是“內部 SLA”，即使還沒有定義一個正式的 SLA(服務等級協議)。
因此，API 接口的監控也是必要的。API 監控可以有不同的形式，但是很顯然它絕對不是簡單的二進制上下檢查。例如，了解像時間函數這樣的最常使用的端點endpoint是有價值的。這使得團隊可以看到服務使用的變化，無論是由于設計變更或用戶的改變。
你也可以記錄服務最緩慢的端點，這些可能揭示出重大的問題，或者至少指向需要在系統中做優化的區域。
最后，跟蹤系統服務響應的能力是另一個很重要的能力，它主要是開發者使用，也能幫助你了解整體用戶體驗，同時將信息基于底層和應用程序視角分成兩大部分。
5、 將您的監控映射到您的組織結構
這篇文章著重在微服務和監控上，像其他科技文章一樣，這是因為很多人都關注此層面。
對于那些熟悉康威定律Conway’s law的人來說，系統的設計是基于開發團隊的組織結構。創造更快，更敏捷的軟件的壓力推動了團隊去思考重新調整他們的開發組織和管理它的規則。
所以，如果他們想從這個新的軟件架構(微服務)上獲益，他們的團隊必須將微服務映射到團隊自身中。也就是說，他們需要更小的更松散耦合的團隊，可以選擇自己的方向只要能夠滿足整個需求即可。在每一個團隊中，對于開發語言的使用，bug 的提交甚至工作職責都會有更大的控制能力。
DevOps 團隊對此可以啟用一個監控平臺：讓每一個微服務團隊可以有自己的警報，度量指標，和控制面板，同時也要給出整體系統的視圖。
總結
讓微服務流行起來的是快捷。開發組織要想更快的為客戶提供更多的功能，然后微服務技術就來了，架構轉向微服務并且容器的流行讓快捷開發成為可能，所有相關的進程理所當然的搭上了這輛火車。
最后，基本的監控原則需要適應伴隨微服務而來的技術和結構。越早認識到這種轉變的開發團隊，能更早更容易的適應微服務這一新的架構。
京公網安備 11010502049343號