iLogTail性能跃迁之路

背景

过去滴滴内部基于自研的日志采集 Agent,构建了覆盖全链路的实时日志采集体系。依托分布式架构设计,每日稳定处理数 PB 级超大规模日志数据,实现对集团内部业务应用的高并发、低延迟日志采集支持,为全公司业务监控、故障诊断、数据分析等场景提供了可靠的底层数据基础设施。

随着AMD机器(核数大幅增加)的引入,面对超大流量采集,原内部Agent逐渐力不从心。经过调研发现iLogTail的架构和性能更契合需求,因此我们决定将内部Agent升级到开源iLogTail,并基于开源版本进行了大量优化。

iLogTail简介

iLogTail是阿里云SLS于2022年6月开源的采集器项目,在阿里巴巴以及外部数万家阿里云客户内部广泛应用,装机量近千万,每天采集数十PB可观测数据。

iLogTail具有轻量级、高性能、低延迟等特点,相比竞品Agent,整体的资源开销、采集性能、以及采集延迟都有一个比较大的优势。

iLogTail架构

iLogTail架构

iLogTail架构更像一个集中式架构,每个采集任务的输入模块、处理模块和发送模块都共享一组线程资源,线程之间通过缓冲队列来交换数据。相较于单体架构(每个任务都有独立的线程资源),这种架构在代码实现上会更加复杂,需要自己去管理任务的调度,资源管控等等,但从性能的角度出发,却能极大地节省资源和提升效率。

iLogTail优势

  • 高效采集,通过Linux操作系统inotify的一个机制,感知到目录或文件的变化后,立刻进行相关的采集,借助inotify,Logtail有更低延迟和更低的性能消耗。
  • 高性能,iLogTail的采集部分及发送到SLS部分是C++编写的,C++部分拥有很高的性能,iLogTail还拥有很丰富的插件但这些都是通过Go编写,如发送到Kafka的插件,Go部分拥有功能优势,但是其垃圾回收会带来很大性能消耗,后面会针对这部分进行优化。

性能优化

在测试iLogTail的过程中,开源版本的性能并不能满足滴滴内部的需求,下面将介绍在iLogTail上的性能优化。

多行解析

多行解析指的是从日志中读取数据时,遇到带有异常堆栈的这种多行日志,需要解析合并成一行日志。

社区是通过配置正则表达式来实现的,在读取的时候正则匹配每一行数据,来判断是否属于同一行日志,这种正则匹配的方式可以适用于任何场景,但是带来的性能下降却很严重。

为解决这一问题,我们实现了基于时间规则的多行解析方法。通过解析每行日志中的时间戳,判断日志是否属于异常堆栈(异常堆栈通常不包含时间戳)。若某行日志的时间戳无法成功解析,则将其与前一行合并,从而实现对异常堆栈的准确识别与整合。
基于时间的多行解析相对于正则匹配可以减少大量字符比较,大大的提升了解析性能,优化后处理速度可以提升1倍。

在此基础之上,还引入AVX2指令集,通过向量化来解析换行符,一条指令操作32个字符。

avx2

优化之前多行解析中耗时主要集中在 GetNextLine 和 ParseTime :

优化前

优化后GetNextLine耗时大大缩短:
优化后

通过向量化优化后CPU性能可以提升8%。

C++重写FlusherKafka插件

在AMD机器上进行大流量(100+MB/s)测试时,发现性能急剧下降,开始出现大面积采集延迟,通过打印火焰图分析看到60%以上的CPU都花在垃圾回收上。
GC情况

在日志采集的场景中,大量日志对象的频繁创建和销毁会对 Go GC的性能产生很大的压力。

最初通过调大Go的堆内存和关闭触发堆GC,性能有所好转,但继续增加流量,频繁GC的问题仍会出现。

Kafka采集架构

为了彻底解决这个问题,使用C++重写FlusherKafka插件,这样从采集一直到发送都是纯C++编写,这样不仅解决了垃圾回收带来的性能消耗,同时避免了C++调Go时协议转换(C++日志对象需要序列化成字节后,由Go在反序列化成对象)带来的CPU消耗和内存消耗(Go有自己独立的内存空间)。

通过此优化后,性能得到了巨大的提升,也是支撑下面测试结果的关键。

引入支持向量化的JSON库

在解决了垃圾回收的问题后,还有一块对性能影响比较大的是Json的序列化,在将日志数据发送到Kafka之前还需要将内存中的日志对象序列化成Json格式的字符串。

为了继续压榨性能,这里引入了字节开源的高性能C++ JSON库sonic-cpp。在Json在序列化中最消耗性能的地方就时处理转义字符,这里通过向量化来加速查找转义字符(原理和上面查找换行符一致),可以显著的提高处理速度。除此之外,它还有另一个优化,支持构建Json对象的时候传递 std::string_view ,这样可以避免大量内存拷贝的开销。

到这里iLogTail的性能已经拉满了。

发送Kafka失败支持回滚offset及退避重试

在原生的FlusherKafka插件中,如果发送Kafka失败数据是会丢失的。为了解决数据丢失的问题,实现了回滚offset的功能,对于每批要发送到Kafka的数据,都保存了这批数据最小的offset,当发送失败时,会在回调函数中回滚offset,读取文件的时候将从失败的位置重新读取。

如果某个任务一直发送不成功,为此还实现了类似TCP的拥塞控制,当发送Kafka失败的时候,会迅速降低采集端速度,当发送成功后则采集速度以指数上升,通过这个机制可以有效的避免存在问题的任务浪费线程资源。

收益

iLogTail开源版本与内部优化版本性能对比

总共创建150个采集任务,测试采集文件的日志数据发送到Kafka,限制CPU上限10C,内存上限为8G, GC堆为5G。同时加载运行这150个采集任务,观察CPU资源使用的情况。
性能对比
在小流量场景下,iLogTail内部版本相比于开源版本能节省56%的CPU,继续增加流量开源版本由于GC严重性能下降。

iLogTail内部版本大流量测试

如下的测试是在AMD机器上测试的,机器配置:384核 1.5T内存,总共600个采集任务,限制CPU上限20C,内存上限20G,iLogTail加载运行这600个采集任务,观察资源使用及采集延迟的情况。
流量压测结果

iLogTail在面临多任务超大流量时,能保证采集不延迟,且使用不到5core就能采集420+MB/s的流量,已经能满足内部的需求。

总结

经过多维度性能测试与优化迭代,iLogTail内部版本在资源效率、稳定性及扩展能力方面均实现显著突破,具体表现如下:

  • 1、性能跨越式提升:在相同Kafka发送链路场景下,内部版本CPU资源消耗较开源版本降低56%,整体采集性能提升超过2倍。开源版本在流量增长时因频繁GC导致性能骤降,而内部版本通过内存管理与优化,实现高吞吐场景下的稳定运行。
  • 2、超大规模流量承载能力:在384核服务器环境下,内部版本仅需分配5个CPU核心即可完成420+MB/s的日志采集吞吐,且保持零延迟。单节点可同时支撑600个采集任务的并行处理,内存资源控制在12G以内,充分验证其弹性扩展能力。
  • 3、生产级可靠性保障:通过精细化资源隔离策略与自适应流量调控机制,内部版本成功突破在资源争抢、任务堆积等方面的瓶颈,满足企业级场景下对稳定性与资源效率的双重要求。

本次优化不仅验证了iLogTail的先进性,更使其成为支撑海量日志采集场景的核心基础设施,为后续千万级数据管道的构建提供了关键能力保障。

如何成为一名靠谱的职场人

带团队几年后,很容易快速判断一个同学是否靠谱。那什么是靠谱?即你把一个事情交给一个人后,完全不用操心后续,因为你知道他肯定能落实,就算中间有困难,他也会及时给与你反馈,然后一起协商后续应该如何快速解决此问题。如果靠谱度需要分级的话,我会将其分为三层:做完、做好、做到极致。但是靠谱度是可以培养的,我认为做好以下几点就基本可以胜出了。

1、能拿结果

即做事情要站在结果的角度去考虑和解决问题,以终为始,从目标开始考虑需要什么条件,然后主动想办法去创造条件从而达成问题的解决。但是不要把“过程导向”和“结果导向”对立起来二选一,实际上在职场中,结果导向并不意味着不重视过程,恰恰相反,而是要用以终为始的心态,带着清晰的目标,善用3W分析法,去开启和推进做事情的过程。

2、具备闭环思维

简单来说就是“凡事有计划,约定必落实,问题早知会,及时报进程,事后须反馈”。闭环思维的培养需要多使用PDCA法则指导自己。

Read More

如何打造一个高绩效团队

目标设定

目标透视镜

看大环境

  • 看行业:政治、经济、社会、技术,导致的行业规模变化
  • 看公司:行业竞争导致的公司战略变化
  • 看业务线:根据公司战略看业务导向变化

看小环境

  • 事业群/部目标和上级目标
  • 内/外部客户和资源方需求
  • 本岗位要求和自身发展需求

主抓工作

  • 三大主抓工作
  • 里程碑
  • 助力/阻力

目标设定的原则(SMART原则)

  • Specific=明确的,清晰的
  • Measurable=具体、量化、可衡量
  • Achievable=可达成并具有挑战性
  • Relevant=有相关性、实际可行
  • Time bound=有完成时限

Read More

Elasticsearch 在滴滴的应用与实践

滴滴 Elasticsearch 简介

简介

Elasticsearch 是一个基于 Lucene 构建的开源、分布式、RESTful 接口的全文搜索引擎,其每个字段均可被索引,且能够横向扩展至数以百计的服务器存储以及处理 TB 级的数据,其可以在极短的时间内存储、搜索和分析大量的数据。

滴滴 ES 发展至今,承接了公司绝大部分端上文本检索、少部分日志场景和向量检索场景,包括地图 POI 检索、订单检索、客服、内搜及把脉日志 ELK 场景等。滴滴 ES 在2020年由2.X升级到7.6.0,近几年围绕保稳定、控成本、提效能和优生态这几个方向持续探索和改进,本文会围绕这几个方向展开介绍。

架构

Read More

滴滴基于 Clickhouse 构建新一代日志存储系统

背景

此前,滴滴日志主要存储于 ES 中。然而,ES 的分词、倒排和正排等功能导致其写入吞吐量存在明显瓶颈。此外,ES 需要存储原始文本、倒排索引和正排索引,这增加了存储成本,并对内存有较高要求。随着滴滴数据量的不断增长,ES 的性能已无法满足当前需求。

在追求降低成本和提高效率的背景下,我们开始寻求新的存储解决方案。经过研究,我们决定采用 CK 作为滴滴内部日志的存储支持。据了解,京东、携程、B站等多家公司在业界的实践中也在尝试用 CK 构建日志存储系统。

挑战

面临的挑战主要来自下面三个方面:

  • 数据量大:每天会产生 PB 级别的日志数据,存储系统需要稳定地支撑 PB 级数据的实时写入和存储。
  • 查询场景多:在一个时间段内的等值查询、模糊查询及排序场景等,查询需要扫描的数据量较大且查询都需要在秒级返回。
  • QPS 高:在 PB 级的数据量下,对 Trace 查询同时要满足高 QPS 的要求。

为什么选 Clickhouse

  • 大数据量:CK 的分布式架构支持动态扩缩容,可支撑海量数据存储。
  • 写入性能:CK 的 MergeTree 表的写入速度在200MB/s,具有很高吞吐,写入基本没有瓶颈。
  • 查询性能:CK 支持分区索引和排序索引,具有很高的检索效率,单机每秒可扫描数百万行的数据。
  • 存储成本:CK 基于列式存储,数据压缩比很高,同时基于HDFS做冷热分离,能够进一步地降低存储成本。

架构升级

Read More

关于做好技术团队管理的几点心得

技术Leader核心工作是让团队拿更好的成绩,日常工作主要是制定方案、推进业务、掌控下属、协助领导等四项内容,本次分享主要分享最基础也是最重要的管理职责:

  • 调动团队同学的工作积极性
  • 让团队同学更高更快的成长

1、如何调动团队同学的工作积极性?

  • 精确的指示。需要更强调为什么做和这么做的意义,没有计划和目的的命令无法为下属提供工作的动力。
    • 举例:有个业务需要节省成本,需要要“查询性能提升2倍”。身为主管,自然不能直接告诉下属“查询性能提升2倍”。主管要做的是,考虑怎样才能使性能提升2倍,再用具体的语言指挥下属行动起来。
    • 工作边界要清晰
  • 了解下属的能力和意愿
    • 根据下属能力进行分工,整体分工需要张弛有度,有能提升硬实力的工作也有易产出有亮眼的工作
    • 针对个体而言,重点在于提升能力和个人意愿
    • 针对个体间而言,在于加强分工和协作,分工要有边界
    • 主管的行为一般有:授权型、参与型、说服型、命令型;根据下属不同性格要有不同的行为
  • 激情会传染。做主管的必须先激情四射,然后才能点燃下属们的激情
  • 要掌控业务全貌
  • 技术上能搞事情。能搞定别人解不了的事情,团队影响力越高,团队同学认同感和参与感越强;多思考技术和未来团队发展的事情
  • 提升下属对你的信任度
    • 有一技之长。技术leader某一块技术能力要做到团队最好,影响信服度
    • 能让对方感受到你是真实的帮助其成长,需要更多换位思考
    • 利用好团建和聚餐场合

Read More