文章采集api 完美:Datakit，真正的统一可观测性 Agent

　　文章采集api 完美:Datakit，真正的统一可观测性 Agent

　　随着云和云原生的发展，越来越多的客户意识到“数据”的重要性，掀起了一波又一波的数据积累浪潮。

　　如今，*敏*感*词*数据量很大采集器，但采集的能力大多是单一的。比如 Telegraf 只支持指标，Filebeat 只服务日志，OpenTelemetry 的 Collector 对非云原生组件不友好。需要大量安装 Exporter 插件。为了实现系统的可观察性，需要使用多个采集器，造成资源的浪费。

　　Datakit是目前唯一真正整合各种环境（传统环境，云/云原生）数据统一的平台采集，一个进程或者Daemonset Pod就可以实现全方位的数据采集，配置体验不错，开源且可扩展。本文将对Datakit相关功能进行全面介绍。

　　（DataKit 内部架构）

　　多维可观测性数据采集

　　Datakit 支持来自各种基础设施和技术栈的采集 Metrics、Logs、Traces 等数据，并对这些数据进行结构化处理。

　　1.实时基础设施对象

　　DataKit 支持从主机、容器、k8s、进程、云产品等所有基础设施对象的实时状态，一气呵成。例如：

　　(1) Datakit hostobject用于采集基本的主机信息，如硬件型号、基本资源消耗等。

　　（2）进程采集器可以监控系统中各种正在运行的进程，获取并分析进程运行时的各种指标，包括内存使用率、CPU时间、进程当前状态、进程监控的端口等..，并且根据进程运行时各种指标的信息，用户可以在观察云中配置相关的告警，以便用户了解进程的状态，当进程发生故障时，故障进程可以及时维护。

　　二、指标

　　相比Telegraf只能采集系列数据，DataKit涵盖的数据更全面采集类型，拥有海量技术栈指标采集能力，采集器配置更简单，数据质量更好.

　　3. 日志

　　针对日志数据的整体可观测性，提供了一种足够灵活多变的信息组合方式。正因为如此，相比指标和追踪，日志有更多的采集和处理方式，以适应不同的采集环境、架构和技术栈的场景。

　　从磁盘文件中获取日志

　　这是最原创的日志处理方式。无论是开发者还是传统的日志采集方案，一般都是先将日志直接写入磁盘文件。写入磁盘文件的日志具有以下特点：

　　(1) 顺序写入：一般的日志框架可以保证日志在磁盘文件中，保持时间的序列性

　　自动分片：由于磁盘日志文件是物理增量的，为了防止日志炸毁磁盘，一般的日志框架会自动进行分片，或者通过一些外部常驻脚本来实现日志分片

　　(2) 基于以上特性，DataKit 只需要跟踪这些文件的变化（即采集 最新更新），一旦写入日志，DataKit 就可以采集 到达，其部署也很简单，在日志采集器的conf中填写文件路径（或通配符路径）为采集即可。

　　通过调用环境API获取日志

　　这个采集方法目前主要针对容器环境下的stdout日志。这种日志需要容器（或Kubernetes Pod）中运行的应用程序将日志输出到stdout，然后通过Docker的日志接口，将对应的stdout的日志同步到DataKit。

　　远程推送日志到 DataKit

　　对于远程日志推送，主要是

　　(1) 开发者直接将应用日志推送到DataKit指定的服务中。例如，Java 的 log4j 和 Python 的原生 SocketHandler 支持将日志发送到远程服务。

　　(2) 第三方平台日志访问

　　这种形式的特点是日志直接发送到DataKit，不需要把日志放在中间。

　　Sidecar 形式的日志采集

　　采集这个方法其实结合了磁盘日志采集和日志远程推送两种方法。具体来说就是在用户的Pod中添加一个兼容DataKit的Sidecar（即logfwd）。应用，采集方法如下：

　　4.链接跟踪

　　DataKit目前支持多种广泛使用的trace数据，如zipkin/jaeger/otel/skywalking/ddtrace等，只需要将对应的数据地址指向Datakit即可。

　　5.终端行为

　　DataKit支持全面采集前端行为数据，包括H5/Android/IOS/Fultter/React-native等。

　　RUM（Real User Monitor）采集器用于采集网页或移动设备上报的用户访问监控数据。建议将 RUM 单独部署在公网上，不要与现有服务（如 Kubernetes 集群）一起部署。因为RUM接口上的流量可能非常大，集群内部的流量会受到干扰，集群内部一些可能的资源调度机制可能会影响RUM服务的运行。

　　通常，生产环境中的js文件会经过各种转换和压缩，与开发时的源代码有较大差异，不方便调试。如果需要在源代码中定位错误，则必须使用 sourcemap 文件。

　　DataKit支持将js对应的sourcemap文件压缩打包，命名为--.zip，上传到/data/rum/，从而实现上报的错误指标集数据自动转换 error_stack_source 字段并将其附加到指标集。

　　6. 云原生安全

　　SChecker插件，绝对安全的安全检查器，lua沙箱只读分析，支持300+安全事件发现，用户可以自定义自己的规则文件和lib库。

　　一般来说，运维过程中一项非常重要的工作就是检查系统、软件、日志等一系列状态。传统的解决方案往往是由工程师编写shell（bash）脚本来执行类似的工作，并使用一些远程脚本来执行类似的任务。管理工具实现集群管理。然而，这种方法实际上是非常危险的。由于系统检查操作中权限过多的问题，经常以root模式运行。一旦恶意脚本被执行，后果将是灾难性的。在实践中，恶意脚本有两种，一种是恶意命令，如rm -rf，另一种是数据窃取，如通过网络IO向外部泄露数据。

　　因此，Security Checker 希望提供一种新型的安全脚本方法（限制命令执行、限制本地 IO、限制网络 IO）来保证所有行为安全可控，Security Checker 将通过统一的网络模型在日志的形式采集事件。同时，Security Checker 将提供大量可更新的规则库脚本，包括对系统、容器、网络和安全的一系列检查。scheck 是安全检查器的缩写。

　　7、基于eBPF的网络监控

　　DataKit eBPF 采集器 支持采集主机/进程/容器的网络层 4/7 性能和异常数据。

　　eBPF采集器、采集主机网络TCP、UDP连接信息、Bash执行日志等。这个采集器主要包括两种：ebpf-net和ebpf-bash：

　　ebpf 网：

　　数据类别：网络

　　完整的解决方案:面向开源软件的自动化漏洞数据采集与处理技术研究

　　漏洞数据分散在数百个资源中，数据碎片化、无格式，导致采集不便、处理复杂。然而，人工构建的漏洞数据集样本类型简单、特征单一，难以支撑真实软件漏洞检测的研究。因此，软件安全领域缺乏*敏*感*词*、真实、有效的漏洞数据集。针对这一问题，本文提出了一种开源软件漏洞数据自动化采集及处理系统，能够自动实现来自多源平台的采集补丁文件，进行冗余处理和一致性处理。得到一个缩减的数据集，进一步生成大量的漏洞样本。与现有研究相比，本文构建的系统可以采集更多源平台的漏洞数据，漏洞数据更丰富，样本质量更高。通过深度学习漏洞检测实验证明，本文在数据集上训练的模型在实际软件漏洞检测中更为有效。

　　该成果已在实验室github组织下开源，相关内容请访问。

　　背景和动机

　　在软件安全领域，漏洞检测技术是一个具有挑战性的问题。为了减少人工参与，提高漏洞的检测规模和检测速度，基于深度学习的漏洞检测模型应运而生。然而，漏洞检测领域缺乏*敏*感*词*的、真实的漏洞数据集。一方面，目前公开的人工构建的数据集，如SARD数据集，只能作为学术研究的对象，对真实漏洞的研究辅助相对有限。漏洞检测不是很有效。另一方面，漏洞数据分散在数百个资源上，没有统一的访问渠道，而且这些数据是碎片化的、无格式的，这给数据采集和处理带来了挑战。此外，不同来源的漏洞数据质量参差不齐，其中一些是安全缺陷，不一定是漏洞补丁。传统的采集方法依赖安全专家通过人工分析进行过滤，耗时耗力、效率低、成本高。为了解决这些问题，本文构建了漏洞数据自动化采集处理系统，旨在总结漏洞数据的分布规律和内容特征，突破漏洞数据准确提取等关键点。自动过滤漏洞补丁链接。技术，解决自动化问题采集和多源漏洞补丁采集 大数据环境下海量异构的漏洞信息，从而实现构建*敏*感*词*、高质量的漏洞数据集，为深度学习漏洞检测提供有效的训练数据，提高模型检测精度。设计与实现如图1所示。系统主要有三个模块： 1）Data采集模块，输入为美国国家漏洞数据库NVD和一般漏洞，输出为漏洞信息和补丁文件；2）数据处理模块，输入为多源采集的补丁文件，输出为处理后的简化补丁库；3）数据生成模块，输入为补丁库和上一步输出的开源项目的源代码，

　　图 1 系统架构图

　　在data采集模块中，我们对权威漏洞库NVD的数据进行解析提取，得到结构化的漏洞属性信息。进一步系统分析研究主流开源软件的漏洞参考链接，找出存在漏洞的平台链接，获取不同安全发布平台的漏洞补丁文件，从而获取漏洞样本，为深度学习漏洞检测提供数据支持研究。. 我们提出了一种基于多源补丁的数据自动化采集 模型，通过三种方法自动化采集补丁。首先是从补丁的安全漏洞公告平台获取补丁，软件厂商自己的漏洞公告平台，和代码管理仓库。在对数百个补丁发布平台进行系统分析总结后，总结出20多种补丁自动化。采集网站，如图2。二是通过“CVE”过滤GitHub的历史修改Commits " 关键词，查找CVE的修改记录，自动过滤历史修改。三是在bug追踪平台Bugzilla的NVD Reference中搜索与CVE匹配的bugid，得到对应的bug修复文件或补丁。

　　图2 补丁源平台

　　在数据处理模块中，我们系统地分析了多源补丁的结构和格式，总结了标准的补丁文件结构和内容信息，并对通过多种采集方法得到的补丁文件进行了合并和去冗余。相同软件版本冗余如图3，不同版本软件冗余如图4。我们提出了一套基于多种信息的补丁有效性评估机制，并结合提取的漏洞文件名，函数名和补丁源平台，判断补丁文件和漏洞的相关性。如果补丁是直接针对漏洞功能的补丁，则认为是最准确的类型1；如果补丁是针对漏洞文件的补丁，它被认为是下一个准确的类型2；如果补丁无法判断是打漏洞函数还是漏洞文件，则可以判断补丁是针对CVE的，则为Type 3；如果不能通过现有信息直接判断，需要进一步人工处理，则暂按第4类处理。

　　图 3 相同软件版本的补丁冗余

　　图 4 不同软件版本的补丁冗余

　　在数据生成模块中，我们将补丁文件与代码库进行匹配，以获取函数级别和文件级别的细粒度漏洞样本。由于源代码漏洞数据集均为线性文本形式，无法反映代码程序的控制依赖信息和层次结构信息，缺乏程序语义与漏洞特征的关系，难以获得准确的语法结构信息通过进一步分析。具有更多语义信息的中间语言形式的漏洞数据可以提供更全面、更直接的代码表示，提高漏洞检测模型的检测能力和准确性。本模块搭建各版本主流软件的编译环境，查找编译漏洞文件所需的头文件、库文件等依赖项，并使用编译器以中间语言的形式生成漏洞样本。目前已经对19个开源软件进行了数据采集和处理，得到了有效的细粒度漏洞样本库。补丁库涵盖 4643 个 CVE，收录 8685 个补丁文件。漏洞样本库有6847个漏洞文件样本、6573个无漏洞文件样本、10412个漏洞函数/非漏洞函数程序样本。统计结果见表1。并使用编译器以中间语言的形式生成漏洞样本。目前已经对19个开源软件进行了数据采集和处理，得到了有效的细粒度漏洞样本库。补丁库涵盖 4643 个 CVE，收录 8685 个补丁文件。漏洞样本库有6847个漏洞文件样本、6573个无漏洞文件样本、10412个漏洞函数/非漏洞函数程序样本。统计结果见表1。并使用编译器以中间语言的形式生成漏洞样本。目前已经对19个开源软件进行了数据采集和处理，得到了有效的细粒度漏洞样本库。补丁库涵盖 4643 个 CVE，收录 8685 个补丁文件。漏洞样本库有6847个漏洞文件样本、6573个无漏洞文件样本、10412个漏洞函数/非漏洞函数程序样本。统计结果见表1。847个漏洞文件样本，6573个无漏洞文件样本，10412个漏洞函数/非漏洞函数程序样本。统计结果见表1。847个漏洞文件样本，6573个无漏洞文件样本，10412个漏洞函数/非漏洞函数程序样本。统计结果见表1。

　　表 1 数据集统计

　　采用基于深度学习的漏洞检测框架 SySeVR() 训练最有效的模型 BGRU。实验一是原创数据集在真实漏洞数据NVD上的检测结果。原创数据集有14000个SARD程序和1591个NVD程序，包括13906个SADR易受攻击程序（包括易受攻击的函数和修补函数），94个非易受攻击程序，874个NVD易受攻击程序，717个无bug程序。实验2使用一个新的数据集，使用原创数据集中来自SARD的数据集，将部分NVD数据集替换为本文构建的6847个易受攻击程序和6573个非易受攻击程序，并在真实数据集上进行测试软件漏洞数据集 NVD。测试结果如表2所示。

　　表2 漏洞检测实验结果对比

　　可以看出，用系统构建的数据集训练的模型在真实数据集的漏洞检测方面表现更好。这体现在假阴性率和假阳性率的降低，以及准确率、准确率和召回率的提高上。这是因为在模型训练中加入了大量真实的软件漏洞数据，提供了丰富的漏洞样本，使得模型可以用于漏洞特征进行更全面的学习。