云原生下的指标与日志采集云原生监控容器开发工具中间

引言：
众所周知，对于一个云原生 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