云采集(指标采集方案介绍常见架构模式Daemons优采云采集器端agent(组图))

　　云采集(指标采集方案介绍常见架构模式Daemons优采云采集器端agent(组图))

　　介绍：

　　众所周知，对于一个云原生的PaaS平台来说，在页面上查看日志和指标是最基本的功能。无论是日志、指标还是链接跟踪，基本上都分为三个模块：采集、存储和展示。

　　在这里，笔者将介绍云原生下常用指标&日志的采集解决方案，以及Erda作为云原生PaaS平台是如何实现的。

　　指标采集程序介绍常用架构模式1.守护进程

　　采集客户端代理通过Daemonset部署在各个节点上。这种模式下，指标通常由agent主动采集获取。常用代理有 telegraf、metricbeat、cadvisor 等。

　　应用场景：

　　2. 推拉

　　当我们需要采集程序的内部指标时，我们通常使用代理主动拉取指标或客户端主动推送指标。

　　应用场景：

　　那么，是推还是拉？

　　我认为这取决于实际的应用场景。比如对于短期任务，由于agent可能还没有启动采集，所以已经结束了，所以我们使用push方式；但是对于Web服务来说，这个问题就不存在了，pull的方式也可以减少用户端。负担。

　　开源解决方案简介

　　作为 CNCF 的 2 号毕业生，Prometheus 从诞生之初就基本成为了云原生尤其是 Kubernetes 的官方监控解决方案。

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

　　和push&pull的方案基本一样，但是因为是丰富的exporter系统，所以基本可以采集在节点层面收录各种指标。

　　二达采用的架构方案

　　在Erda，目前的解决方案是通过二次打开telegraf，利用其丰富的采集插件，合并Daemonset和push-pull的解决方案。

　　日志采集程序介绍常见架构模式1.守护进程

　　如果容器中应用的日志输出到stdout，容器运行时会通过logging-driver模块输出到其他媒体，一般是本地磁盘。比如Docker通常通过json-driver docker/containers//*.log文件将日志输出到/var/log/。

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

　　2. 边车

　　Daemonset 方案也有一些限制，例如，当应用程序日志输出到日志文件时，或者当您要为日志配置一些处理规则（例如，多行规则、日志提取规则）时。

　　这时候可以使用Sidecar方案，logging-agent和应用容器可以共享日志目录，主动上报给采集。

　　3. 主动举报

　　当然也可以主动上报日志（一般是通过厂商提供的SDK）。

　　常见的应用场景有：

　　开源解决方案简介

　　在业界，比较有名的是使用ELK作为日志解决方案，当然也是一个完整的解决方案。采集模块主要使用beats作为采集端，logstash作为日志采集的主要入口，elasticsearch作为存储，kibana作为展示层。

　　尔达的建筑

　　在 Erda 中，我们使用 fluent-bit 进行日志记录采集器：

　　概括

　　不难看出，无论是指标还是日志，data采集方案都比较简单明了，我们可以根据实际场景进行混搭。但是，随着集群规模的增长和用户定义需求的增加，往往会出现以下困难：

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