應用軟件架構經過單體架構、分佈式架構，面向服務架構、微服務架構發展，在雲計算、容器、網絡等技術的支撐下，更多企業的新一代應用都開始選擇使用微服務架構。同時，容器技術在LXC (Linux Container)、cgroups、namespaces 技術基礎上發展成型，是更輕量化的虛擬技術。隨着Kubernets的發展解決了大規模容器集羣的編排和管理問題，將被拆分解耦的業務系統再度統一管理起來讓服務可以自由融合、彼此協作爲業務的發展提供高效的基礎能力。
容器化微服務在具備面向業務功能、降低開發難度、增加容錯度、服務間松耦合、彈性擴展、提高生產效率等優勢同時，也面臨服務發現、限流、權限、版本管理等挑戰，服務監控也是其中挑戰之一。
01 容器化微服務面臨的監控運維挑戰
▌監控對象數量增大
傳統監控以單體應用爲粒度，結合計算、存儲、網絡等基礎設施監控進行運維保障。但在容器化微服務架構下，監控粒度細緻到容器POD或微服務API級別，使得監控對象的數量相比單體應用呈指數級增長。
▌監控路徑動態變化
基於微服務架構的應用動態性是監控面臨的一個重要挑戰。應用系統由很多個微服務組成，同時運行於容器環境中，服務通過相互調用、自身處理產生出複雜的行爲。微服務並不是靜態的，而是隨着業務需求不斷變化，改變調用關係，處理過程以及優化路徑。
▌信息維度多面
保障容器化微服務，首要基礎就要有能力全面“度量刻畫”微服務，這其中涉及到應用、系統、基礎設施等相關資源屬性和性能指標等，這是一張多維關聯的知識圖譜。以一個異常的服務訪問路徑爲例，涉及到的指標包括錯誤率，調用延時等。僅僅發現異常還不足以解決問題，因此會繼續產生一系列的疑問：
· 路徑上的異常服務有哪幾個？
· 服務運行在哪個節點上，哪個區域中？
· 訪問路徑在異常前有無變化？
· 服務歷史中的調用關係有哪些？
· 異常可能影響的範圍？
回答這些疑問，任何單一維度的排查都是管中窺豹。必須通過關聯服務、容器平臺、網絡流量、平臺事件等數據信息，構建多維度的知識圖譜，在解決問題的過程中方可成竹在胸。
▌傳統監控難以觸達
在雲環境中，由於虛擬化技術應用，傳統監控工具難以觸達池化後的各類資源，導致“黑盒”化嚴重。此外，傳統監控工具從數據開放性、架構擴展性、監控粒度上都難以滿足雲原生應用的需求。新興可觀測技術，旨在通過系統的外部監測數據（指標、日誌、追蹤等）實時分析系統的內部狀態（吞吐、錯誤、時延等），徹底解決雲內監控的“黑盒”問題。
02 監控與可觀測性
監
隨着業務系統不斷上雲，容器、微服務、持續發佈等雲原生技術被廣泛採用，從而爲IT系統的監控帶來了全新挑戰。爲保障雲原生應用的穩定性，可觀測技術被越來越多的企業所採用。針對於IT系統，尤其是面向雲原生應用，可觀測技術應包含如下需求：
▌零侵擾
傳統APM/NPM等工具，要麼需要應用程序中打樁插碼，要麼需要基礎設施中分光鏡像，均會對IT系統進行侵擾。可觀測技術使用外部數據做分析，因此採用零侵擾的方式獲取監控數據，無需打樁插碼、分光鏡像，而是通過開放系統架構直接獲取監控數據。零侵擾的另一方面是要求低功耗，不能因爲採集數據而影響應用或基礎設施性能，通常採集點功耗不能超過業務功耗的1%。
▌多維度
要保障雲原生應用穩定運行，可觀測技術必須包含多維度數據分析能力。具體來說，要將應用的API、容器、主機、網絡等監控數據進行全棧關聯分析。傳統的APM工具，可以定位代碼層問題，卻無法追蹤容器或主機網絡服務引起的故障。而傳統的NPM工具，又不能關聯應用的TraceID從而追蹤穿越NAT、LB等網元的流量。因此，多維度的全棧數據分析，是可觀測平臺的第二個需求。
▌實時性
雲原生應用的動態性要求可觀測平臺必須具備實時性。如果應用的升級/擴容在分鐘級完成，那麼監控系統就必須提供秒級的反饋能力。注意，這裏的反饋需要對海量指標/追蹤/日誌數據進行查找分析，因此對可觀測平臺的海量數據實時處理能力提出了極高要求。
在Google Cloud的定義中，“可觀測性是可幫助團隊有效調試其系統的工具或技術解決方案，並有能力探索未知或事先未定義的屬性和模式。”
可觀測性並不是通過簡單使用一個工具所能具備，是需要根據企業組織、業務應用、基礎設施以及已有的監控體系的需求現狀，明確階段目標，伴隨着業務發展逐步建立，是一個持續發展的過程。
雲杉網絡與客戶的共同實踐，基於雲原生應用發展的現狀，通過DeepFlow®與客戶的應用、網絡、基礎設施整合，綜合分析各類指標、日誌以及追蹤數據，形成一站式的容器化微服務可觀測性方案。
DeepFlow ®容器化微服務可觀測性方案
DeepFlow®提供適用於容器化微服務的可觀測性，解決雲原生應用診斷難的核心痛點。通過對全局微服務（UniversalServices）間的通信訪問、系統調用、平臺環境等數據進行深度分析，提供監控告警、故障定位及風險排查，保障業務在雲原生環境中的穩定、高效運行。
➤分鐘級定位問題邊界
基於容器化微服務的雲原生應用出現故障時，快速明確問題邊界是解決問題的第一步。基於知識圖譜、微服務調用鏈、全棧追蹤等功能組合，快速檢索到異常單元所關聯涉及到的其他維度信息和影響範圍；直觀展示系統、容器、虛擬主機全棧性能指標鎖定性能窪地等。
➤大幅提升排障效率
排障過程並不僅是找到故障根因並修復，而是從定位、根因、修復、驗證及預防一整套運維保障操作閉環。容器環境疊加微服務架構使得排障更加複雜，需要避免以單次異常故障爲視角，避免以單一數據爲依據判斷根因進行排障工作，需要有效地將應用、容器平臺、系統調用等運維數據進行關聯，且對比指標、跟蹤以及日誌特徵來提高根因的準確性；並通過歷史視圖、系統運行表現、修復驗證等指標來確認從而提升效率。
➤微服務可用性指標
應用微服務化後，衡量判斷衆多微服務的質量以及可用性是一個繁瑣的問題。涉及到不同開發團隊，設定具體指標，週期性的記錄和評估，發現性能窪地及熱點等等。這些工作都是要建立在數據積累的基礎之上，DeepFlow®平臺也是基於此來進行對微服務各維度的畫像評估。通過對應用中所涉及的幾十、上百個微服務運行的歷史指標數據進行量化分析，在一個運行週期中，能實時監控業務是否達到99.99%的可用性要求（Service Level Object），並分析出潛在影響可用性的各種原因。
▌DeepFlow®運行環境
在公有云環境中，例如由騰訊雲、阿里雲等的雲服務商提供的IaaS服務基礎上，可以直接選擇容器服務或者通過開源Kubernetes軟件搭建容器平臺，部署運行各類容器化微服務。DeepFlow ®通過零侵擾採集技術，獲取各類運維監控數據，如基礎設施資源配置、網絡流量、API調用等，並通過後臺實時數倉，對多維度數據進行實時分析處理，滿足不同場景下的微服務可觀測能力。
▌兼容現有監控工具
在監控體系發展以及客戶的實際使用中，存在各類監控工具，如資源監控ZABBIX、容器監控Prometheus、日誌監控ElasticSearch、應用追蹤Skywalking等等。DeepFlow®憑藉零侵擾、低消耗、高性能的流量採集技術，可以爲現有監控工具補充難以獲取的豐富指標數據，結合客戶已有的環境及工具平臺，達到監控數據關聯，運維流程聯動，滿足微服務保障的告警、定位、排障以及預測量化服務質量的要求。
以DeepFlow®做爲基礎數據平臺，結合Prometheus、ZABBIX、雲監控數據構成對應用、系統、雲基礎設施的指標數據基礎，通過開放數據對接告警平臺、認證平臺以及 Grafana等數據可視化平臺，向微服務開發部門、業務部門展現關鍵指標數據。通過TraceID、SpanID、URL、資源ID等關鍵值關聯追蹤數據，在應用出現異常或者調優過程中，以高效對接歷史指標趨勢劃定資源範圍，使特定應用請求過程與指標鑽取統計不再割裂。實現對雲上微服務的全方位可觀測能力。
總結
總結
雲杉網絡DeepFlow®容器化微服務可觀測性方案，面向公有云K8s、容器環境。利用eBPF等新技術的零侵入特性實現對網絡、系統、應用的全棧黃金指標的採集。對服務調用鏈以及Service mesh、iptables/ipvs、NAT的逐跳鏈路追蹤，對服務訪問的零採樣全留存，並結合雲資源知識圖譜和變更事件數據，搭建立體化的微服務可觀測平臺。
雲計算以及容器將是今後承載微服務業務應用的主要平臺，對於雲網絡以及雲原生應用保障，將面臨規模廣、彈性大、波動性強等諸多挑戰，雲杉網絡目標就是幫助客戶補齊雲網監控的拼圖，保障雲及微服務業務有序可控發展。
點擊閱讀原文，下載《DeepFlow容器化微服務可觀測性方案》文檔。
往期推薦
|
|||
|
|||
|
|||
|
備註“使用Zabbix年限+企業+姓名”
進入交流羣，4000+用戶已加入
一個人走得快，一羣人走得遠
本文分享自微信公衆號 - Zabbix開源社區（china_zabbix）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。