一文詳解|雲原生下的指標與日誌採集

語言: CN / TW / HK

導讀:眾所周知,對於一個雲原生 PaaS 平臺而言,在頁面上檢視日誌與指標是最為基礎的功能。無論是日誌、指標還是鏈路追蹤,基本都分為採集、儲存和展示 3 個模組。這裡筆者將介紹雲原生下的常見的指標 & 日誌的採集方案,以及 Erda 作為一個雲原生 PaaS 平臺是如何實將其現的。


指標採集方案介紹


  常見架構模式


1. Daemonset



採集端 agent 通過 Daemonset 的方式部署在每個節點上。該模式下,通常是由 agent 主動採集的方式來獲取指標,常見的 agent 有 telegraf、metricbeat、cadvisor 等。


應用場景:

  • 通常用來採集節點級別的指標,例如:節點資源指標、節點上的容器資源指標、節點的效能指標等。


2. 推 & 拉


當我們需要採集程式的內部指標時,通常採用 agent 主動拉取指標或客戶端主動推送指標的方式。


應用場景:

  • 對於 Web 服務、中介軟體等長時間執行的服務來說,我們一般採用定時拉取的方式採集;
  • 對於 CI/CD、大資料等短時任務,則一般是以客戶端主動推送的方式採集,例如:推送任務的執行耗時、錯誤數等指標。

那麼,到底是採用推還是拉的方式呢?

我認為這取決於實際應用場景。例如:短時任務,由於 agent 可能還沒開始採集它就已經結束了,因此我們採用推的方式;而對於 Web 服務則不存在這個問題,採用拉的方式還能減少使用者側的負擔。

  開源方案介紹



Prometheus 作為 CNCF 的 2 號畢業選手,一出生就基本成為雲原生尤其是 Kubernetes 的官配監控方案了。


它實際是一套完整的解決方案,這裡我們主要介紹它的採集功能。


  • 場景下,Prometheus server 中的 Retrieval 模組,負責定時抓取監控目標暴露的指標。

  • 場景下,客戶端推送指標到 Pushgateway,再由 Retrieval 模組定時抓取 Pushgateway。


其與推&拉方案基本相同,不過由於其即為豐富的 exporter 體系,基本可以採集包括節點級別的各種指標。


  Erda 採用的架構方案



在 Erda 中,當前的方案是通過二開了 telegraf, 利用其豐富的採集外掛,合併了 Daemonset 和推拉方案。


  • telegraf[DS]:作為Daemonset採集節點級別的指標;
  • telegraf-app[DS]:不採集指標,僅用於轉發上報 trace 資料;
  • telegraf-platform: 採集服務級別的指標;
  • collector:收集 telegraf 上報的指標,以及客戶端程式主動推送的指標。

日誌採集方案介紹


  常見架構模式


1. Daemonset



容器內應用的日誌若輸出到 stdout 中,容器執行時會通過 logging-driver 模組輸出到其他媒介上,通常是本機的磁碟上,例如 Docker 通常會通過 json-driver 輸出日誌到 /var/log/docker/containers/<cid>/*.log 檔案中。


對於這種場景,我們一般採用 Daemonset 的方案,即在每個節點上部署一個採集器,通過讀取機器上的日誌檔案來採集日誌。


2. Sidecar


Daemonset 方案也有一些侷限性,例如,當應用日誌是輸出到日誌檔案時,或者想對日誌配置一些處理規則(例如,多行規則、日誌提取規則)時。


此時可採用 Sidecar 的方案,通過 logging-agent 與應用容器通過共享日誌目錄、主動上報等方式來採集。


3. 主動上報



當然,還可以主動(一般通過供應商提供的 SDK)上報日誌。


常見應用場景有:
  • 當你想轉發日誌到外部系統時可以使用主動上報的模式,例如,轉發阿里雲的日誌到 Erda;
  • 當你不想或者不具備部署任何 logging-agent 時,例如:當你只想試用下 Erda 的日誌分析時。

  開源方案介紹



業界中,比較有名的就是使用 ELK 來作為日誌方案,當然也是整套解決方案。採集模組主要是 beats 作為採集端,logstash 作為日誌收集總入口,elasticsearch 作為儲存,kibana 作為展示層。


  Erda 的架構方案




在 Erda 中,我們使用了 fluent-bit 作為日誌採集器:


  • 針對容器日誌:我們採用 Daemonset 的方案進行採集;
  • 針對 ECI 等無法部署 Daemonset 的場景:我們採用 Sidecar 的方案採集;
  • 針對第三方的日誌:我們在 collector 端支援使用者的自定義主動上報。

小結


不難看出,無論是指標還是日誌,其資料採集方案還是比較簡單清晰的,我們可以根據實際場景隨意搭配。

然而隨著叢集規模的增長以及使用者自定義需求的增加,往往會出現如下難點:


  • 資料洪流問題:如何保障監控資料的時效性以及降低資料傳輸與儲存成本;


  • 配置管理問題:如何管理大量的自定義配置,例如自定義指標採集規則、日誌多行規則、日誌分析規則等等


對於這些問題,我們也在不斷探索實踐中,並會在後續的文章中進行分享。


  參考連結 & 延伸閱讀
  • Logging Architecture

    https://kubernetes.io/docs/concepts/cluster-administration/logging/

  • 什麼是 ELK Stack?

    https://www.elastic.co/cn/what-is/elk-stack

  • Overview|Prometheus

    https://prometheus.io/docs/introduction/overview/#architecture



戳原文,瞭解更多!

本文分享自微信公眾號 - 爾達 Erda(gh_0f507c84dfb0)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。