一、基于LoongCollector构建下一代可观测数据的管道

1.数据采集在可观测中的定位

每天可观测系统都会产生大量的数据，这些数据可以应用在开发运营、运维和安全等各个领域，具有极高的价值，可观测数据采集在系统中起到基石的作用，它源源不断的将高价值的可观测数据输入到平台中，当在端上和系统中采集数据的时候，往往会用到一个采集代理的技术，采集代理的技术会带来像代码解耦、资源可隔离，采集可管控的好处。随着现在端上数据源的越来越多，数据采集的可观测数据类型的变多，越来越复杂的环境使得需要安装越来越多的采集代理，太多的采集代理可能会占用过多的资源侵占本来的应用资源，这个新的问题带来安装采集代理复杂度，所以采集代理进行融合成为一个新的技术趋势。

阿里云可观测将端上的采集代理融合带来了以下几个好处，首先是只需要安装一次，用户只需要通过一次自动的代理安装，就可以采集各种类型的可观测数据。第二是可以节省代理的资源，可以通过统一技术栈、共享数据等方式，最大限度的减少对正常业务资源的挤占。第三通过统一的管控可以降低配置运维的代价，通过统一的健全机制可以提供更安全的采集链路，通过统一的采集链路可以更加简化用户侧网络的配置。

2.新采集代理方案LoongCollector

它本身是基于高性能的云原生采集器iLogtai演进而来，它融合阿里云日志服务、Prometheus以及ARMS的采集技术。LoongCollector的全新定位是打造一款可观测数据统一代理，专为构建下一代可观测数据流水线而生，它的愿景是打造业界领先的可观测统一代理和端到端的数据采集传输Pipeline。LoongCollector在采集方面的范围进行扩大，从日志采集发展到采集全部类型的可观测数据，它的本地的数据处理能力也升级为本地计算和全面的数据服务发现能力，LoongCollector将为可观测代理技术带来性能可靠性、配置可管控性、数据处理的灵活性和采集的全面性四个方面带来四大价值。

3.Loong collect的第一大价值性能可靠以及无懈可击

LoongCollector在采集速率上优势明显,这一对比的结论来自第三方对于市面上主流的开源采集器的一个横向测评，LoongCollector是继承lock tail的高性能优秀基金，并且把它进一步发扬光大，相信衡量一项技术的最佳的标准是和它的理论极限进行比较。因此在LoongCollector上进一步进行优化。

在内存管理上大量使用memory Arena,还有Zero Copy的技术进一步减少内存的分配和它的复制，在多行切分使得极简模式的采集可以达到500兆每秒的一个采集速率，在多行切分方面，升级切分状态机，现在已经支持像行尾嵌套格式的一些复杂的解析，同时对于模式匹配也进行优化，它的性能可以达到原来的七倍，在云原身上最常用的采集标准输出的插件，是对它进行c++的重构，重写后的插件能够支持日志的轮转，提高稳定性，并且它的采集速率也达到原来的三倍以上，除在性能方面的提升之外，LoongCollector的稳定性上也绝不妥协，原来用于日志的反馈队列，把它升级为通用的反馈队列，可以保证任何可回放数据源。

At Least Once的采集语义，原先支持的配置热加载，给它升级成配置间独立热加载，这样可以最大限度降低配置更新对采集连最性的一个影响，提高采集服务的在线时长。对于新接入的像Prometheus的时序数据类，新增先入先出的缓冲队列，可以容忍一定时长的发送网络异常，保证数据不丢失，在未来会推出可直求化的一个队列容忍更长时间的异常。LoongCollector带来的第二大价值是编程管道无与伦比。

LoongCollector已经全部采用模块化的设计，它的采集流水线中的插件是可以自由组合的。Input processor和Flash插件都可以灵活的进行编排，特别是processor部分支持两大处理引擎，一个是多语言处理多语言的PlugIn处理引擎，第二个是SPL的处理引擎。

重点介绍SPL的引擎，通常可以看到采集上来的数据是非结构化的，但是真正用数据时，期望的是结构化数据，因为它便于分析，能够提取它的最大价值，这个地方涉及到一个非结构化转结构化的问题，SRL正是解决问题的专家，可以看到SPL的脚本语句就已经可以完成正则提取 Jason提取，还有时间提取和字段筛选的功能，对比使用配置和插件配置，可以看到它的表达更加的自然和流畅的。

这两个引擎在LoongCollector中也是有一个比较清晰的定位，对于像多语言的plug in引擎，主要的考虑点是灵活，可组合、可编排，还有开发者的二次开发能力，对于SPL的引擎则更侧重于本身的性能和可编程性。SPL的引擎是完全由c++来构建的，因此它的特点是性能高，资源占用低。同时它已经支持100多种的算子，完全可以支持它的可编程能力。同时它的语法非常简洁，使用管道式的设计非常适合复杂的数据逻辑的表达，选择SPL还能带来另一个好处,SPL语言不仅可以在LoongCollector上进行执行，同时的话在它的接收端、消费端甚至查询端都可以运行，用户只需要编写一次SPL的语言，就可以结合实际的应用需求来选择它的执行位置。比如当需要降本增效，可以把处理的逻辑推到LoongCollector中。

如果发现LoongCollector的处理压力过大。又可以把它上移到接收端进行执行。在这里展示更多的SPL的用例，可以看到engines的日志解析、节省的日志解析、数据脱敏、字符的映射等都可以通过SPL进行轻松完成。

LoongCollector的第三大价值是配置管理无忧无虑，随采集器升级的管控服务的能力，原先可观测的商业版管控已经可以通过机器组管理百万级的采集代理，现在能力进一步提升，提升到千万级的容量。同时采集配置的下发周期从60秒下降到十秒，这次升级还新增进程级的管控，比如原先采集代理上要修改一个CPU的Limit,需要每一台机器登录手动修改配置，以后都可以通过管控能力远程的进行统一修改，在LoongCollector上和社区共建新的管控协议，这一开放的管控协议使得所有符合这一标准的配置服务都可以管理LoongCollector。

这样进一步提升LoongCollector和其他系统的集成能力，对于阿里云可观测也希望进一步提升用户配置采集的体验，首先对采集配置的结构进行升级，新的采集配置的结构完全是和采集流水线的执行步骤是对应的，最大限度降低编写采集配置的难度。无论是通过UI的控制台，通过K8SCRD还是本地进行一个配置，或者是通过API直接写配置，都是保持同样的配置结构，使得在配置时可以通过清点鼠标在UI上进行操作，从而生成一份配置，可以把它粘贴到CRD中，或者是API中,帮助大家自动化运维系统的集成，对于LoongCollector自身的可观测性进行升级，在原有的CloudLens for SLS的基础上进行升级。不仅可以看到LoongCollector的整体状况和异常监控的状况，同时完全把Pipeline中的细节进行白盒化，可以观测到Pipeline中执行的插件的细节指标，对于排查日志采集问题是十分有帮助的。

举一个例子进行说明，根据LoongCollector中的一条流水线，它输出数量是骤减，如果通过白盒化的表格可以看出这个流水线的processorfilter RAG native插件，这个插件的输出记录数显著小于输入记录数，说明在配置流水线的时候,这个插件出现问题。

LoongCollector的第四大价值是遥测数据无边无际,在日志采集的场景下,它出色的完成数据接入的任务，在可观测发展至今，会面临各种异构的环境和可观测的协议，以及种类极其繁多的可观测对象。数据类型发展不止magic  chance，还包括Profiles， Events等。LoongCollector针对上述异构的复杂环境提供一套完整且可扩展的技术解决方案，实现一个遥测数据无线边界的目标。

首先LoongCollector在新开发的重点功能,在基于c++实现的LoongCollector上提供完整的Prometheus的采集能力。并且基于master+worker的两级架构，实现一个多副本的工作模式，采集器可以在随着目标数量和指标规模上升时，实现自动的水平扩容。同时借助master出色的任务分配和调度能力，在探针的运维过程，如果重启或者升级期间，能够实现采集作业的不中断来最大化，保障用户的可观测业务的连续性，使云产品的用户和工程师都能够在一些关键的衡量点上得到收益。

通过一个简短的demo视频看效果。看到副本探针的数量是一个字监控的大盘，以及发现的服务目标的数量，master会对它的数量以及是指标数做一个分配，分配在采集实例上，接下去在容器的控制台做一次重新部署，模拟一个升级的过程，可以看到随着重新部署之后，这个采集器的pod会进入terminated的状态,然后拉起新的副本。采集器类表现在进行一个滚动升级的过程，左边是一个基于count all time,基于每一次采集动作伴随的up的信号做累加,发现在升级过程当中运维采集是不中断的，非常平稳的保持对1112个采集目标的采集，达到一个平滑升级的效果。

二、融入进入的eBPF采集技术

首先介绍eBTF的能力，对于LoongCollector新版本中更新的新的feature，是eBPF采集技术。首先eBPF是运行在linux中的虚拟机，允许动态的运行自定义代码，使用eBPF的原因主要得益于它的三大特性。

第一大特性是无侵入，可以动态的挂载，或者移除eBPF代码，不需要业务代码修改代码，甚至也不需要再去重启应用。

第二个特性是它具有高性能的能力，eBPF代码在植入内核的时候，它会被及时编译成机器码，所以它执行效率是非常高的。

第三个特性是安全性。eBPF的代码工作在linux自己的一个虚拟机中，它通常不会引起业务进程的崩溃。

根据eBPF的采集技术与传统的APM探针的区别，不管在侵入性还是覆盖程度以及性能开销还有安全性上,eBPF都有非常显著的优势，LongCollector基于eBPF构建非常多的观测插件，其中最具有代表性的是应用性能观测，它主要用来无侵入的观测，应用的黄金三指标，对于传统APM探针，如果想要观测应用的服务性能，通常需要对不同的编程语言以及不同的编程框架实现对应的采集插件。这样会有两个问题。第一个是它的侵入性非常强，要代码集成些插件。第二是它的开发复杂度比较高，需要编写大量的插件，为解决这些问题,LoongCollector使用eBPF采集网络字节流，基于网络字节流解析应用层的协议。这样就屏蔽掉编程语言和框架的影响，可以大幅的减少开发的复杂度。

把eBPF代码加载到系统调用上，采集应用的输入流量。采集到输入流量之后，进入协议解析器提取应用层的信息，比如HTTP协议的状态码和接口等信息。进入到k8sMedata进行数据的孵化,这一步主要是将IP数据映射成可读的k8s资源，比如port或者deployment。之后进入聚合器，在这一步将半结构化的数据转化成开源标准的观测数据的格式，比如metric或者log，接下来是在k8s中的简单demo，开启网络监控之后，探针就会不断的采集其中的流量，并绘制出一份网络拓扑，通过拓扑可以快速的感受到系统的架构，如果对其中的某个负载开启应用性能监控之后，就会获取更多的一些应用层信息，比如说应用的请求数，错误数，还有调用时延以及CPU，还有内存的使用率等数据。在应用拓扑中可以看到应用维度的一个上下游的依赖，并且还包含调用的基本情况。

在提供服务页面中，枚举当前应用所有的接口，并提供过滤、筛选以及排序等能力帮助快速的定位异常的接口。在依赖服务终端列举出所有的下游依赖。如果系统依赖数据库，还会在页面展示出SQL明文以及调用情况。接下来在实例监控页面，不仅展示出实例的资源开销，另外由于集成k8sMedata，可以很方便的关联Prometheus监控数据，大盘里面的很多数据都是来自于，比如sad weather coopersy metric组提供的。

面向未来LoongCollector主要有三大目标，第一目标是作为基础设施，不断的持续的推进性能和稳定性的建设,第二目标是继续朝着all in one目标提供统一的采集和处理的底层引擎。第三目标是不断探索AI赋能的智能化采集技术。最后是LoongCollector的所有代码都已经开源。