杭州都市網

應用軟件架構經過單體架構、分布式架構,面向服務架構、微服務架構發展,在云計算、容器、網絡等技術的支撐下,更多企業的新一代應用都開始選擇使用微服務架構。

容器技術在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,并分析出潛在影響可用性的各種原因。

運行環境

在公有云環境中,例如由騰訊云、阿里云等的云服務商提供的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的逐跳鏈路追蹤,對服務訪問的零采樣全留存,并結合云資源知識圖譜和變更事件數據,搭建立體化的微服務可觀測平臺。

云計算以及容器將是今后承載微服務業務應用的主要平臺,對于云網絡以及云原生應用保障,將面臨規模廣、彈性大、波動性強等諸多挑戰,云杉網絡目標就是幫助客戶補齊云網監控的拼圖,保障云及微服務業務有序可控發展。