其他分享
首页 > 其他分享> > 云原生下的指标与日志采集

云原生下的指标与日志采集

作者:互联网


引言:

众所周知,对于一个云原生 PaaS 平台而言,在页面上查看日志与指标是最为基础的功能。无论是日志、指标还是链路追踪,基本都分为采集、存储和展示 3 个模块。

这里笔者将介绍云原生下的常见的指标 & 日志的采集方案,以及 Erda 作为一个云原生 PaaS 平台是如何实将其现的。


指标采集方案介绍

常见架构模式

1. Daemonset

image.png

采集端 agent 通过 Daemonset 的方式部署在每个节点上。该模式下,通常是由 agent 主动采集的方式来获取指标,常见的 agent 有 telegraf、metricbeat、cadvisor 等。

应用场景:

2. 推 & 拉

image.png

当我们需要采集程序的内部指标时,通常采用 agent 主动拉取指标或客户端主动推送指标的方式。

应用场景:

那么,到底是采用推还是拉的方式呢?

我认为这取决于实际应用场景。例如:短时任务,由于 agent 可能还没开始采集它就已经结束了,因此我们采用推的方式;而对于 Web 服务则不存在这个问题,采用拉的方式还能减少用户侧的负担。

开源方案介绍

image.png

Prometheus 作为 CNCF 的 2 号毕业选手,一出生就基本成为云原生尤其是 Kubernetes 的官配监控方案了。

它实际是一套完整的解决方案,这里我们主要介绍它的采集功能。

其与推&拉方案基本相同,不过由于其即为丰富的 exporter 体系,基本可以采集包括节点级别的各种指标。

Erda 采用的架构方案

image.png

在 Erda 中,当前的方案是通过二开了 telegraf, 利用其丰富的采集插件,合并了 Daemonset 和推拉方案。

日志采集方案介绍

常见架构模式

1. Daemonset

image.png

容器内应用的日志若输出到 stdout 中,容器运行时会通过 logging-driver 模块输出到其他媒介上,通常是本机的磁盘上,例如 Docker 通常会通过 json-driver 输出日志到 /var/log/docker/containers//*.log 文件中。

对于这种场景,我们一般采用 Daemonset 的方案,即在每个节点上部署一个采集器,通过读取机器上的日志文件来采集日志。

2. Sidecar

image.png

Daemonset 方案也有一些局限性,例如,当应用日志是输出到日志文件时,或者想对日志配置一些处理规则(例如,多行规则、日志提取规则)时。

此时可采用 Sidecar 的方案,通过 logging-agent 与应用容器通过共享日志目录、主动上报等方式来采集。

3. 主动上报

image.png

当然,还可以主动(一般通过供应商提供的 SDK)上报日志。

常见应用场景有:

开源方案介绍

image.png

业界中,比较有名的就是使用 ELK 来作为日志方案,当然也是整套解决方案。采集模块主要是 beats 作为采集端,logstash 作为日志收集总入口,elasticsearch 作为存储,kibana 作为展示层。

Erda的架构方案

image.png

在 Erda 中,我们使用了 fluent-bit 作为日志采集器:

小结

不难看出,无论是指标还是日志,其数据采集方案还是比较简单清晰的,我们可以根据实际场景随意搭配。
然而随着集群规模的增长以及用户自定义需求的增加,往往会出现如下难点:

对于这些问题,我们也在不断探索实践中,并会在后续的文章中进行分享。

参考链接 & 延伸阅读

更多技术干货请关注【尔达 Erda】公众号,与众多开源爱好者共同成长~

文中部分图片源自网络,侵删

标签:原生,方案,指标,采集,Daemonset,日志,Erda
来源: https://www.cnblogs.com/erda/p/15802619.html