對于微服務架構監控應該遵守的原則
隨著軟件交付方式的變革，微服務架構的興起使得軟件開發變得更加快速和靈活。在這種情況下，監控系統成為了微服務控制系統的核心組成部分。隨著軟件的復雜性不斷增加，了解系統的性能狀況和及時排除問題變得更加困難。因此，監控系統也需要與時俱進，進行全面的改造，以更好地適應微服務環境的需求，并能夠更好地發揮作用。
新興的微服務架構對軟件開發帶來了速度和靈活性的提升，從而改變了傳統的軟件開發模式。其中，速度是微服務的核心需求之一。為了更好地滿足這一需求，監控系統也需要隨之進行調整和改進。
監控在微服務體系結構中變得尤為關鍵，因為隨著軟件復雜性的增加，我們需要更好地了解系統的性能和及時發現問題。下面是我們制定的五個指導性原則，以幫助我們整監控方法：
- 監控容器及其內部：微服務通常在容器中運行，因此監控容器本身以及容器內的各種組件和資源是至關重要的。
- 關注服務性能而不是容器性能：在微服務架構中，重點應該放在監控服務的性能和健康狀態上，而不是單純地監控容器的資源使用情況。
- 監控彈性和多地部署的服務：微服務架構的一個優勢是其彈性和多地部署的能力，因此監控系統需要能夠有效地跟蹤和管理這些特性。
- 監控 API：微服務通常以 API 的形式提供服務，因此監控這些 API 的性能和可用性對于確保整個系統的穩定運行至關重要。
- 將監控映射到組織結構：根據我們的組織結構和團隊的職責，設計監控系統的結構，確保監控數據能夠直觀地反映出整個組織的運行狀態。
通過遵循這五個原則，可以建立起更加有效和全面的微服務監控系統，從而更好地應對微服務架構所帶來的技術和組織上的挑戰。
下面我們細說這五個原則
監控容器及其內部
隨著微服務架構的流行，容器技術已成為構建微服務的重要組成部分。容器具有速度、可移植性和隔離性等優勢，使得開發人員更容易接受微服務模型。容器的好處已經被廣泛討論，不再贅述。
然而，對于外部系統來說，容器就像一個黑盒子一樣。這對于開發人員來說是非常方便的，因為容器可以輕松地在不同的環境中部署。但是一旦容器開始運行，當需要監控和解決服務問題時，這個黑盒子就會成為挑戰，因為常規的監控方法往往無法生效。我們需要深入了解容器內部運行的情況：究竟運行了哪些程序和代碼？它們的性能如何？是否有重要的輸出指標？從DevOps的角度來看，我們需要更深入地了解容器，而不僅僅是知道它們的存在。
在非容器環境下，常見的監控方法是在主機或虛擬機的用戶空間內運行一個代理程序。然而，這種方法并不適用于容器環境。容器的優點之一是輕量級，它們將各種進程隔離開來，并盡可能地減少依賴關系。
此外，大規模使用成千上萬個監控代理對于即使是中等規模的部署來說都是一種昂貴的資源浪費和管理上的挑戰。對于容器環境，有兩種潛在的解決方案：
- 要求開發人員直接監控他們的代碼：讓開發人員負責監控其代碼的性能和運行狀況。這種方法可以讓開發人員更深入地了解其代碼的運行情況，但可能會增加他們的工作負擔，并且對于整個系統的全面監控可能不夠全面。
- 利用內核級的檢測方法：使用一種通用的內核級監控方法來查看主機上的所有應用程序和容器活動。這種方法可以減少代理的數量，并提供更全面的監控覆蓋范圍，但可能會影響主機的性能，并且可能無法提供與每個容器相關的詳細信息。
每種方法都有其優點和缺點，選擇最適合環境的方法取決于我們的具體需求和限制。
利用業務流程系統提醒服務性能
在容器環境中理解運行數據并不容易，相比于單個容器，聚合多個容器組成的功能或服務的復雜度要低得多。
這種方法特別適用于應用程序級別的信息，比如哪個請求具有最短的響應時間，或者哪些 URL 遇到了最多的錯誤。同樣，它也適用于架構級別的監控，比如哪個服務的容器使用了超出事先分配的 CPU 資源。
越來越多的軟件部署需要使用編排系統來將應用程序的邏輯規劃轉化為物理容器的部署。常見的編排系統包括 Kubernetes、Mesosphere DC/OS 和 Docker Swarm。團隊可以利用編排系統來定義微服務，并理解每個服務當前狀態。可以說編排系統甚至比容器本身還要重要，因為容器是臨時的，只有在滿足服務需求時才會存在。
DevOps 團隊應該將告警重點放在服務運行特征上，以盡可能貼近監控服務的實際體驗。如果應用受到影響，這些告警是評估事態的第一道防線。但是獲得這些告警并不容易，除非監控系統是基于容器本身的。
容器本身的監控解決方案利用編排元數據來動態聚合容器和應用程序數據，并按每個服務計算監控度量。根據使用的編排工具，可能希望在不同的層次進行深入監測。例如，在 Kubernetes 中，通常會有 Namespace、ReplicaSet、Pod 和其他一些容器。聚合這些不同的層次對于排除邏輯故障是非常必要的，與構成服務的容器的物理部署無關。
監控彈性Elastic和多地部署Multi-Location的服務
彈性服務并不是一個新概念，但在原生容器環境中的變化速度比在虛擬環境中要快得多。這種快速變化會嚴重影響監測系統的正常運行。
傳統系統的監測通常需要根據軟件部署進行手動調整。這種調整可能是具體的，例如定義要捕獲的單個指標，或者基于應用程序在特定容器中的操作來配置要收集的數據。在小規模環境下（例如幾十個容器），我們可能可以接受這種手動調整，但在大規模環境下就難以承受了。微服務的集中監控必須能夠自動地隨著彈性服務的增長和縮減而調整，無需人工干預。
舉例來說，如果 DevOps 團隊必須手動定義哪些服務需要監控，那么他們很可能會失手，因為像 Kubernetes 或 Mesos 這樣的平臺每天都會定期創建新的容器。同樣，如果在將代碼部署到生產環境時需要運維團隊安裝一個定制的狀態端點，這也會給開發人員從 Docker 倉庫獲取基礎鏡像帶來更多的挑戰。
在生產環境中，建立面向跨越多個數據中心或多個云的復雜部署的監控是一項挑戰。例如，如果服務跨越私有數據中心和 AWS，那么亞馬遜的 AWS CloudWatch 就很難實現這一點。因此，我們需要建立一個能夠跨不同地域的監控系統，并能夠在動態的原生容器環境下運行。
監控 API
在微服務環境中，API 接口是通用的，并且本質上是將服務暴露給其他團隊的唯一組件。事實上，API 的響應和一致性可以看作是“內部 SLA”，即使還沒有定義一個正式的 SLA（服務等級協議）。
因此，API 接口的監控也是必不可少的。API 監控可以采用不同的形式，但很顯然，它絕對不是簡單的二進制上下檢查。例如，了解像時間函數這樣的最常使用的端點是很有價值的。這使得團隊可以看到服務使用的變化，無論是由于設計更改還是用戶的變化。
還可以記錄服務最慢的端點，這些可能會揭示出重大的問題，或者至少指向需要在系統中進行優化的區域。
最后，跟蹤系統服務響應的能力是另一個非常重要的能力，它主要是供開發者使用的，但也有助于你了解整體用戶體驗。同時，將信息基于底層和應用程序視角分成兩大部分也是很有幫助的。
將監控映射到組織結構
對于熟悉康威定律的人來說，系統的設計是基于開發團隊的組織結構。創造更快、更敏捷的軟件推動了團隊重新思考他們的開發組織和管理規則。因此，如果他們想要從這種新的軟件架構（微服務）中獲益，他們的團隊必須將微服務映射到團隊自身的結構中。換句話說，他們需要更小、更松散耦合的團隊，這些團隊可以自主選擇自己的方向，只要能夠滿足整體需求即可。在每個團隊中，他們對于開發語言的使用、bug 提交甚至工作職責都會擁有更大的控制能力。
