DevOps監控微服務的五原則

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

監控是微服務控制系統的關鍵部分，你的軟件越複雜，那麼你就越難了解其性能及問題排障。鑑於軟件交付發生的巨大改變，監控系統一樣須要進行完全的改造，以便在微服務環境下表現更好。下面咱們將介紹監控微服務的 5 條原則，以下：

• 監控容器及其裏面的東西。
• 在服務性能上作監控，而不是容器性能。
• 監控彈性和多地部署的服務。
• 監控 API。
• 將您的監控映射到您的組織結構。

利用這 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 和一些其餘容器。聚合這些不一樣的層，對排除邏輯故障是頗有必要的，與構成服務的容器的物理部署無關。

三、 監控彈性Elastic和多地部署Multi-Location的服務

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

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

好比，若是 DevOps 團隊必須手動定義容器包含哪一個服務須要監控，他們毫無疑問會失手，由於 Kubernetes 或者 Mesos 天天都會按期建立新的容器。一樣，若是代碼發佈並置於生產環境時要求運維團隊安裝一個定製的狀態端點custom stats endpoint，也給開發者從 Docker 倉庫獲取基礎鏡像帶來更多的挑戰。

在生產環境中，創建面向跨越多個數據中心或多個雲的複雜部署的監控，好比，若是你的服務跨越私有數據中心和 AWS，那麼亞馬遜的 AWS CloudWatch 就很難作到這一點。這就要求咱們創建一個跨不一樣地域的監控系統，並可在動態的原生容器環境下運行。

四、 監控 API

在微服務環境中，API 接口是通用的。本質上，它們是將服務暴露給其它團隊的惟一組件。事實上，API 的響應和一致性能夠看做是「內部 SLA」，即便尚未定義一個正式的 SLA(服務等級協議)。

所以，API 接口的監控也是必要的。API 監控能夠有不一樣的形式，可是很顯然它絕對不是簡單的二進制上下檢查。例如，瞭解像時間函數這樣的最常使用的端點endpoint是有價值的。這使得團隊能夠看到服務使用的變化，不管是因爲設計變動或用戶的改變。

你也能夠記錄服務最緩慢的端點，這些可能揭示出重大的問題，或者至少指向須要在系統中作優化的區域。

最後，跟蹤系統服務響應的能力是另外一個很重要的能力，它主要是開發者使用，也能幫助你瞭解總體用戶體驗，同時將信息基於底層和應用程序視角分紅兩大部分。

五、 將您的監控映射到您的組織結構

這篇文章着重在微服務和監控上，像其餘科技文章同樣，這是由於不少人都關注此層面。

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

因此，若是他們想從這個新的軟件架構(微服務)上獲益，他們的團隊必須將微服務映射到團隊自身中。也就是說，他們須要更小的更鬆散耦合的團隊，能夠選擇本身的方向只要可以知足整個需求便可。在每個團隊中，對於開發語言的使用，bug 的提交甚至工做職責都會有更大的控制能力。

DevOps 團隊對此能夠啓用一個監控平臺：讓每個微服務團隊能夠有本身的警報，度量指標，和控制面板，同時也要給出總體系統的視圖。

總結

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

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

本文地址：http://www.linuxprobe.com/devops-five-rules.html