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

3次阅读

共计 2096 个字符,预计需要花费 6 分钟才能阅读完成。


引言:

家喻户晓,对于一个云原生 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 端反对用户的自定义被动上报。

小结

不难看出,无论是指标还是日志,其数据采集计划还是比较简单清晰的,咱们能够依据理论场景随便搭配。
然而随着集群规模的增长以及用户自定义需要的减少,往往会呈现如下难点:

  • 数据洪流问题:如何保障监控数据的时效性以及升高数据传输与存储老本;
  • 配置管理问题:如何治理大量的自定义配置,例如自定义指标采集规定、日志多行规定、日志剖析规定等等

对于这些问题,咱们也在一直摸索实际中,并会在后续的文章中进行分享。

参考链接 & 延长浏览

  • https://kubernetes.io/docs/co…
  • https://www.elastic.co/cn/wha…
  • https://prometheus.io/docs/in…

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

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

正文完
 0