微服務架構下日誌採集運維管理分析

簡介：阿里雲日誌服務(SLS)結合Kubernetes日誌特色以及應用場景，提供全方位的容器微服務應用環境下的日誌採集、處理以及分析的實踐。

直達最佳實踐：【微服務架構日誌採集運維管理最佳實踐】
最佳實踐頻道：【最佳實踐頻道】
這裏有豐富的企業上雲最佳實踐，從典型場景入門，提供一系列項目實踐方案，下降企業上雲門檻的同時知足您的需求！

Kubernetes日誌系統的重要性

雲原生對於微服務可觀測性的一項重要標準就是日誌記錄（logging)。日誌的採集、存儲和分析時構建現代系統平臺的關鍵支柱之一，能夠幫助團隊進行問題的診斷、質量的回溯、系統運營效率監控等。在當今容器/Kubernetes技術大火的環境下，日誌系統對於Kubernetes也起着很是關鍵的做用，對於Devops、運營、安全等方面都離不開完整多樣有效的日誌採集、存儲管理和分析，從下圖可見。

微服務架構下日誌採集運維管理面臨的挑戰

衆所周知，隨着容器/Kubernetes技術在微服務落地過程當中相對物理機、VM在應用部署、應用交付等環節給用戶提供了更加簡單輕量、高性價比等優點，並且用戶在應用容器/Kubernetes技術作微服務改造過程當中，也同時存在容器化應用/非容器化應用混合部署的形態。對於基於VM或者物理機部署的應用，日誌採集相關技術都比較完善，有比較健全的Logstash、Fluentd、FileBeats等，可是在應用容器化特別是基於Kubenetes集羣作微服務應用部署時，日誌採集運維給用戶帶來了不小的挑戰，主要的緣由有：

• 日誌採集目標多，須要採集宿主機日誌、容器內日誌、容器stdout,存在多種應用數據及多種日誌格式，缺少統一的一站式日誌採集解決方案；
• 集羣彈性伸縮、環境動態性強、服務動態遷移等都給日誌採集帶來了很大的困難，日誌採集的動態性以及數據完整性都是很是大的挑戰；
• 運維成本很是大，已有的一些方案只能使用多種軟件組合採集，各個軟件組裝起來的系統穩定性難以保障，且缺少中心化的管理、配置、監控手段，運維負擔大；
• 日誌採集Agent侵入性高，Docker Driver擴展須要修改底層引擎，一個Container對應採集一個日誌採集Agent又會產生資源競爭和浪費
• 日誌採集性能低，正常狀況下一個Docker Engine會運行數十個甚至數百個Container，此時開源日誌採集Agent採集性能及資源消耗十分不理想；
• 日誌分析效率和手段缺少，開源的日誌分析展示工具對於日誌的實時分析、智能分析等缺少簡單有效的可視化手段。

阿里雲Kubernetes日誌採集方案

基於以上分析，阿里雲日誌服務產品針對用戶在基於Kubernetes作應用微服務改造落地過程當中日誌採集運維管理的需求和痛點，結合阿里雲組合雲產品的優點，提出了一站式的日誌採集運維管理分析的解決方案，提供了強大的日誌處理分析能力，如PB級日誌實時查詢、日誌聚類分析、Ingress日誌分析報表、日誌分析函數、上下游生態對接等能力，提供用戶在 容器/Kubernetes技術落地應用微服務改造過程當中的日誌採集運維管理一站式能力。

• Ingress日誌解決方案
  Kubernetes中Ingress是一種API資源的聲明，具體的實現須要由Ingress Controller來接管Ingress定義，目前比較流行的Ingress Controller實現有Nginx、Traefik、listio、Kong等，在國內接受度最高的是Nginx Ingress Controller。
  日誌和監控是全部Ingress Controller都會提供的基礎功能，日誌通常包括訪問日誌(Access Log)、控制日誌(Controller Log)和錯誤日誌(Error Log)，監控主要從日誌以及Controller中提取Metrics信息。這心數據中訪問日誌的量級最大、信息最多、價值也最高，通常七層的訪問日誌包括：URL、源IP、UserAgent、狀態碼、入流量、出流量、響應時間等，對於Ingress Controller這種轉發型的日誌，還包括轉發的Service名、Service響應時間等額外信息。從這些信息中，咱們可以分析出很是多的有用信息，例如：網站訪問的PV、UV；訪問的地域分佈、設備端分佈；網站訪問的錯誤比例；後端服務的響應延遲；不一樣URL訪問分佈等。可是手動搭建並運維一整套的Ingress日誌分析與監控系統很是複雜，系統須要很是多的模塊，例如部署日誌採集Angent並配置採集和解析規則，部署實時數據分析引擎例如Elastic Search、Clickhouse等，部署可視化組件並搭建報表例如Grafana、Kibana等，部署告警模塊等配置告警規則例如ElastAlert等，並且因爲Kubernetes集羣的訪問量相對較大，所以還須要搭建一個緩衝隊列例如Redis、Kafka等。
  爲了簡化用戶對於Ingress日誌分析與監控的門檻，阿里雲容器服務和日誌服務將Ingress打通，只須要應用一個yaml資源便可完成日誌採集、分析、可視化等一整套Ingress日誌方案的部署。
  

• Kubernetes 容器日誌採集分析與監控
  日誌做爲任一系統不可或缺的部分，Kubernetes的官方文檔也介紹了多種日誌採集形式，總結起來主要有下述三種：原生方式、DaemonSet方式和SideCar方式。

  • 原生方式：使用kubectl logs直接查看本地保留的日誌，或者經過docker engine的logging driver將日誌重定向到文件、syslog、fluentd等系統中。
  • DaemonSet方式：在Kubernetes集羣的每一個節點上部署日誌agent，由agent採集全部容器的日誌到服務端。
  • SideCar方式：一個容器組(Pod)中運行一個SideCar的日誌agent容器，用於採集該容器組(Pod)主容器產生的日誌。SideCar模式的日誌採集依賴Logtail和業務容器共享日誌目錄，業務容器將日誌寫入到共享目錄中，Logtail經過監控共享目錄中日誌文件變化並採集日誌。

  採集方式對比見下表。
  從上述表格能夠看出，原生方式相對功能太弱，通常不建議在生產系統中使用；DameonSet方式相對資源佔用要小不少，但擴展性、租戶隔離性受限，比較適用於功能單一或者業務不是不少的集羣；SideCar方式相對資源佔用較多，但靈活性以及多租戶隔離性較強，建議大型的Kubernetes集羣或做爲PAAS平臺爲多個業務方服務的集羣使用該方式。一般咱們能夠這樣進行採集部署建議：

  • 核心應用：使用SideCar方式採集。
  • 普通應用/系統日誌：使用DaemonSet方式採集。
  • 標準輸出: 使用DaemonSet方式採集。

總結

本文介紹了基於Kubernetes進行應用微服務改造過程當中的日誌採集與運維管理方案，限於篇幅，本文沒法對具體實施建議以及更多特點功能進行一一介紹，請你們詳細閱讀阿里雲官網最佳實踐頻道的微服務架構日誌採集運維管理最佳實踐

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。