我們對微服務的需求可以歸納為乙個詞：速度。這種更快提供功能完善且可靠的軟體的需求，徹底改變了軟體開發模式。毫無疑問，這個改變對軟體管理，包括系統監控的方式，都產生了影響。在這篇文章裡，我們將重點關注放在有效地監控產品環境中的微服務所需做出的主要改變。我們將為這一新的軟體架構擬定 5 條指導性原則來調整你的監控方法。
監控是微服務控制系統的關鍵部分，你的軟體越複雜，那麼你就越難了解其效能及問題排障。鑑於軟體交付發生的巨大改變，監控系統同樣需要進行徹底的改造，以便在微服務環境下表現更好。下面我們將介紹監控微服務的 5 條原則，如下：
1. 監控容器及其裡面的東西。
2. 在服務效能上做監控，而不是容器效能。
3. 監控彈性和多地部署的服務。
4. 監控 api。
5. 將您的監控對映到您的組織結構。
利用這 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 團隊對此可以啟用乙個監控平台：讓每乙個微服務團隊可以有自己的警報，度量指標，和控制面板，同時也要給出整體系統的檢視。
總結 讓微服務流行起來的是快捷。開發組織要想更快的為客戶提供更多的功能，然後微服務技術就來了，架構轉向微服務並且容器的流行讓快捷開發成為可能，所有相關的程序理所當然的搭上了這輛火車。
最後，基本的監控原則需要適應伴隨微服務而來的技術和結構。越早認識到這種轉變的開發團隊，能更早更容易的適應微服務這一新的架構。
DevOps監控微服務的五原則
我們對微服務的需求可以歸納為乙個詞 速度。這種更快提供功能完善且可靠的軟體的需求，徹底改變了軟體開發模式。毫無疑問，這個改變對軟體管理，包括系統監控的方式，都產生了影響。在這篇文章裡，我們將重點關注放在有效地監控產品環境中的微服務所需做出的主要改變。我們將為這一新的軟體架構擬定 5 條指導性原則來調...
微服務devops 用於微服務的安全DevOps
微服務devops 容器和微服務徹底改變了應用程式開發和基礎架構管理。他們還提出了新的安全挑戰，而沒有解決舊的挑戰。有哪些新的安全挑戰，您可以如何應對？微服務正在改變一切。不變的基礎架構，無共享架構和容器化應用程式 微服務 是當今大多數企業路線圖的重點。微服務提供了一種以小型，自治且可自我維持的能力...
微服務架構下的監控問題
用一句話概括就是服務特別多，服務間的呼叫也變得非常複雜 我們其實是微服務的受害者，其實業內很多人做的架構只是服務化，並不夠 微 而我們做的比較徹底，我們線上很多服務都只有乙個 api，但這樣造成線上指標非常多，告警也非常多，讀和寫的壓力都非常大。第二個是智慧型化的監控和告警，運用合適的演算法並加上機...