導讀：眾所周知，對於一個雲原生 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

戳原文，瞭解更多！