共计 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】公众号，与泛滥开源爱好者独特成长～
文中局部图片源自网络，侵删
