云原生下的指標與日志采集
引言：
眾所周知，對于一個云原生 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//*.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 端支持用戶的自定義主動上報。
小結
不難看出，無論是指標還是日志，其數據采集方案還是比較簡單清晰的，我們可以根據實際場景隨意搭配。
然而隨著集群規模的增長以及用戶自定義需求的增加，往往會出現如下難點：
數據洪流問題：如何保障監控數據的時效性以及降低數據傳輸與存儲成本；
配置管理問題：如何管理大量的自定義配置，例如自定義指標采集規則、日志多行規則、日志分析規則等等
對于這些問題，我們也在不斷探索實踐中，并會在后續的文章中進行分享。
參考鏈接 & 延伸閱讀
https://kubernetes.io/docs/concepts/cluster-administration/logging/
https://www.elastic.co/cn/what-is/elk-stack
https://prometheus.io/docs/introduction/overview/#architecture
更多技術干貨請關注【爾達 Erda】公眾號，與眾多開源愛好者共同成長～
文中部分圖片源自網絡，侵刪
云原生 容器 微服務 日志分析服務 LOG
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
