导读:众所周知,对于一个云原生 PaaS 平台而言,在页面上查看日志与指标是最为基础的功能。无论是日志、指标还是链路追踪,基本都分为采集、存储和展示 3 个模块。这里笔者将介绍云原生下的常见的指标 & 日志的采集方案,以及 Erda 作为一个云原生 PaaS 平台是如何实将其现的。
1. Daemonset
采集端 agent 通过 Daemonset 的方式部署在每个节点上。该模式下,通常是由 agent 主动采集的方式来获取指标,常见的 agent 有 telegraf、metricbeat、cadvisor 等。
应用场景:
通常用来采集节点级别的指标,例如:节点资源指标、节点上的容器资源指标、节点的性能指标等。
当我们需要采集程序的内部指标时,通常采用 agent 主动拉取指标或客户端主动推送指标的方式。
应用场景:
Prometheus 作为 CNCF 的 2 号毕业选手,一出生就基本成为云原生尤其是 Kubernetes 的官配监控方案了。
它实际是一套完整的解决方案,这里我们主要介绍它的采集功能。
拉场景下,Prometheus server 中的 Retrieval 模块,负责定时抓取监控目标暴露的指标。
推场景下,客户端推送指标到 Pushgateway,再由 Retrieval 模块定时抓取 Pushgateway。
其与推&拉方案基本相同,不过由于其即为丰富的 exporter 体系,基本可以采集包括节点级别的各种指标。
在 Erda 中,当前的方案是通过二开了 telegraf, 利用其丰富的采集插件,合并了 Daemonset 和推拉方案。
容器内应用的日志若输出到 stdout 中,容器运行时会通过 logging-driver 模块输出到其他媒介上,通常是本机的磁盘上,例如 Docker 通常会通过 json-driver 输出日志到 /var/log/docker/containers/<cid>/*.log 文件中。
对于这种场景,我们一般采用 Daemonset 的方案,即在每个节点上部署一个采集器,通过读取机器上的日志文件来采集日志。
Daemonset 方案也有一些局限性,例如,当应用日志是输出到日志文件时,或者想对日志配置一些处理规则(例如,多行规则、日志提取规则)时。
此时可采用 Sidecar 的方案,通过 logging-agent 与应用容器通过共享日志目录、主动上报等方式来采集。
业界中,比较有名的就是使用 ELK 来作为日志方案,当然也是整套解决方案。采集模块主要是 beats 作为采集端,logstash 作为日志收集总入口,elasticsearch 作为存储,kibana 作为展示层。
在 Erda 中,我们使用了 fluent-bit 作为日志采集器:
数据洪流问题:如何保障监控数据的时效性以及降低数据传输与存储成本;
配置管理问题:如何管理大量的自定义配置,例如自定义指标采集规则、日志多行规则、日志分析规则等等
本文分享自微信公众号 - 尔达 Erda(gh_0f507c84dfb0)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
|