跳转至

DataKit 整体架构简介


Datakit 是运行在用户本地机器上的一种基础数据采集工具,主要用于采集系统运行的各种指标、日志等数据,将它们汇总给 观测云,在观测云中,用户可以查看并分析自己的各种指标、日志等数据。

DataKit 是观测云中至关重要的一个数据采集组件,几乎所有观测云中的数据都是来源于 DataKit。

DataKit 基础网络模型

DataKit 网络模型主要分为三层,可以简单概括为用户环境、DataWay 以及观测云中心,如下图所示:

DataKit 基础网络模型
  1. DataKit 主要通过定期采集的方式,采集各种不同的指标,然后定时、定量通过 HTTP(s) 将数据发送给 DataWay。每个 DataKit 都会配置对应的 token,用于标识不同的用户

注意:如果用户内网环境没有开通外网请求,可以通过 Nginx 做一层代理出来,也可以通过 DataKit 内置的 Proxy 采集器 来实现流量代理

  1. DataWay 收到数据后,转发给观测云,在发给观测云的数据中,带有 API 签名
  2. 观测云收到合法的数据后,根据不同的数据类型,分别写入不同的存储中

对于采集类的数据业务,一般情况下,允许部分数据丢失(因为本身数据就是间歇采集的,间歇期内的数据,可视为一种数据丢失),目前整个数据传输链路做了如下丢失保护:

  1. DataKit 因为某些网络原因,发送 DataWay 失败,此时 DataKit 会缓存最大一千个点的数据。当缓存的数据超过这个量,这个缓存会被清理掉
  2. DataWay 可能因为某些原因,发送观测云失败,或者因为流量较大,来不及发送给观测云,DataWay 会将这些数据持久化到磁盘。后续待流量降低或网络恢复时,再将这些数据发送给观测云。延迟发送的数据,不影响时效性,时间戳是附着在缓存的数据中的。

在 DataWay 上,为保护磁盘,这个磁盘的最大用量也是可以配置的,以免将所在节点的存储撑爆。对于超过用量的数据,DataWay 也是选择丢弃数据。不过这个容量一般设置得比较大。

DataKit 内部架构

DataKit 内部架构相对比较简单,如下图所示:

DataKit 内部采集架构

自上往下,DataKit 内部主要分成三层:

  • 顶层:包括程序入口模块以及一些公共模块

    • 配置加载模块:DataKit 除了自己的主配置(即 conf.d/datakit.conf)之外,各个采集器的配置都是分开配置的,如果放一起,这个配置文件可能非常大,不便于编辑
    • 服务管理模块:主要负责整个 DataKit 服务的管理
    • 工具链模块:DataKit 作为一个客户端程序,除了采集数据之外,还提供了很多其它的周边功能,这些都是在工具链模块实现的,如查看文档、重启服务、更新等
    • Pipeline 模块:在日志处理中,通过 Pipeline 脚本,实现对日志的切割,将非结构的日志数据,转换成结构化数据。在其它非日志类数据中,也可以进行对应的数据处理
    • 选举模块:当部署的 DataKit 特别多时,用户可以将所有 DataKit 的配置做成一样,然后通过自动化批量部署将配置下发给各个 DataKit。选举模块的意义在于,在一个集群中,某些数据的采集(如 Kubernetes 集群指标),只应有一个 Datakit 实施采集(不然数据重复,且给被采集方造成压力)。在集群中所有 DataKit 配置都一样的情况下,通过选举模块,即可实现任意时间,最多只会有一个 DataKit 实施采集
    • 文档模块:DataKit 的文档通过自身代码生成,便于文档的自动发布
  • 传输层:负责几乎所有数据的输入输出

    • HTTP 服务模块:DataKit 支持第三方数据的接入,比如 Telegraf/Prometheus,后续还可以接入更多的数据源。目前这些数据都是通过 HTTP 接入
    • IO 模块:各个数据采集插件,每次采集完成后,都会将数据发送给 IO 模块。IO 模块封装了统一的数据构建、处理和发送接口,便于接入各个采集器插件采集的数据。另外,IO 模块会以一定的节奏(定期、定量),通过 HTTP(s) 将数据发送给 DataWay
  • 采集层:负责各种数据的采集。按照采集的类型,分成两类:

    • 主动采集型:这类采集器按照配置的固定频率来采集,比如 CPU网卡流量云拨测
    • 被动采集型:这类采集器通常是以外部数据输入来实现采集,比如 RUMTracing等。它们一般运行在 DataKit 之外,可通过 DataKit 开放的数据上传 API,对数据经过一定的标准化处理,然后再上传到观测云

    每个不同的采集器,都单独运行在独立的 goroutine 中,且做了外层保护,即使单个采集器因为某些原因奔溃(每个采集器运行期最大允许崩溃 6 次),也不会影响 DataKit 整体的运行。

    为避免采集器对用户环境造成意外的性能损耗,比如采集频率设置过高(手抖将 1m 设置成了 1ms),DataKit 有全局的保护模式(保护模式可全局关闭,类似系统防火墙),对这些意外的错误设置,DataKit 会自动调整成相对正常的设置。

DataKit 绝大部分代码(98+%)都用 Golang 开发,目前支持主流的 Linux/Mac/Windows 平台。由于 DataKit 在用户环境以服务的 方式(常驻)运行,DataKit 不能对运行环境有太多的依赖,且不应对用户的环境造成明显的性能消耗。目前 DataKit 的基本运行表现如下:

  • 极少环境依赖:绝大部分采集器都是跟 DataKit 主程序集成在一起的(也即它们都是以 Golang 开发),极少数有动态库依赖或环境依赖(比如依赖 Python 环境)的数据集采集,用户通过简单的操作即可满足
  • 控制资源消耗:常驻内存消耗大概在 30MB 左右,CPU 消耗控制在 3% 左右(测试 CPU 为 Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz 还有优化空间);磁盘消耗几乎可以忽略。网络流量则视具体采集的数量而定,DataKit 出来的流量均以行协议压缩的形式发送,在保持可读性的情况下,数据体积也很小

理论上,任何可被观测的数据,都可以通过 DataKit 来采集,随着用户观测数据的需求日益增长,DataKit 将逐步增加更多不同类型的数据采集;得益于 DataKit 插件模型的高扩展性,这一目标的实现,变得异常简单。

文档评价

文档内容是否对您有帮助? ×