当前位置：首页 > news >正文

iLogtail 开源两周年：UC 工程师分享日志查询服务建设实践案例

news 文章来源：https://blog.csdn.net/alisystemsoftware/article/details/142873536 2025/4/29 18:37:57

作者：UC 浏览器后端工程师，梁若羽

传统 ELK 方案

众所周知，ELK 中的 E 指的是 ElasticSearch，L 指的是 Logstash，K 指的是 Kibana。Logstash 是功能强大的数据处理管道，提供了复杂的数据转换、过滤和丰富的数据输入输出支持。Filebeat 是师出同门的轻量级日志文件收集器，在处理大量日志文件、需要低资源消耗时，它们通常被一起使用。其经典使用场景如下图，Filebeat 将日志文件从各个服务器发送到 Kafka 解耦，然后 Logstash 消费日志数据，并且对数据进行处理，最终传输到 ElasticSearch，由 Kibana 负责可视化。这种架构兼顾了效率和功能。

iLogtail 的优势

请注意，iLogtail 也是轻量级、高性能的数据采集工具，也有不俗的处理能力，重要的是，压测显示，iLogtail 性能比 Filebeat 领先太多。究其原理，Polling + inotify 机制可能是 iLogtail 性能如此优秀的最重要原因。这方面，社区已经有详尽的文档，这里就不深入了。

让我们关注性能测试结果，实际的业务场景，比较贴近下面表格第四行“容器文件采集多配置”一项，可以看到，同流量输入下，随着采集配置增加，filebeat CPU 增加量是 iLogtail CPU 增加量的两倍。其它场景，iLogtail 在 CPU 方面的优势也是遥遥领先，有五倍的、有十倍的，具体数值可以参考下面的链接。

《容器场景 iLogtail 与 Filebeat 性能对比测试》：

https://ilogtail.gitbook.io/ilogtail-docs/benchmark/performance-compare-with-filebeat#dui-bi-zong-jie

《Logtail 技术分享(一) : Polling + Inotify 组合下的日志保序采集方案》：

https://zhuanlan.zhihu.com/p/29303600

iLogtail 替换 Logstash 可行性分析（What to do）

那么，iLogtail 能够在生产环境中替换 Filebeat 和 Logstash，直接采集日志到 ElasticSearch 呢？

如果是过去，答案是不能。主要有四个方面的原因。

插件性能。
配置管理。
容灾。
自身状态监控。

现在逐一分析一下。

插件性能

虽然 iLogtail 核心部分性能突出，但是它原先的 elasticsearch flusher 插件存在短板。

配置管理

我们生产环境有很多采集实例，缺少一个前端页面，供管理员白屏化维护采集配置。因为 Config Server 已经提供了 API 接口，所以这也是最容易实现的。
iLogtail Agent 缺少生命周期管理，当 Agent 进程退出后，该 Agent 对应的心跳信息长期保留在 Config Server 数据库中，而且没有存活状态，即使是想清理也不知道应该清理哪些记录。
我们上千个应用实例是分组部署的，每个组的采集配置可能不一样，所以 Config Server 也要支持按照标签，对各个 Agent 进行分组管理。

容灾

生产环境所有节点都要求多实例部署，Config Server 也一样，而现在的 leveldb 存储方案使得它是有状态的，需要替换为 MySQL 等具有成熟容灾方案的关系数据库。

自身状态监控

在 Agent 运行过程中，需要以合适的方式上报 CPU 使用率、内存占用等信息给 Config Server，方便管理员掌握其负载状况。

目标：iLogtail 替换 Logstash（How to do）

除去 Config Server 前端页面，针对以上四个方面留存的五大问题，我们在过去一段时间做了全面优化提升，最终实现了目标。下面，参考 OKR 工作法，介绍这五大问题的解决方案。当然，留意到现在社区开始讨论 Config Server 的通信协议修改，我们的方案是在前一段时间的基础上实现的，可能与最终方案有所不同。

KR1：解决 elasticsearch flusher 性能瓶颈

方案分为三部分，分别如下：

使用 esapi 的 BulkRequest 接口批量向后端发送日志数据。批量之后，一个请求可以发送几百上千条日志，请求次数直接降低两三个数量级。
Agent 在 flush 阶段之前，有聚合的过程，会自动生成一个随机的 pack id，以它作为 routing 参数，把同一批次的日志数据路由到同一个分片上，以免 ElasticSearch 按照自动生成的文档 ID 作为分片字段，减少不必要的计算和 IO 操作，降低负载，提高吞吐量。
启用 go routine 池，并发向后端发送日志数据。

KR2：解决 Agent 生命周期管理与存活状态判断

方案参考 HAProxy 的实现，尽量避免网络抖动带来的影响。

Config Server 只有收到连续指定次数的心跳，才会认为该 Agent 在线。
只有连续指定次数的周期内都没有收到心跳，才会认为该 Agent 离线。
Agent 离线达到一定时长后，即可自动清理该 Agent 的残余心跳信息。

KR3：解决 Agent 按标签分组

这个方案需要修改一下通信协议。原协议的相关部分如下：

message AgentGroupTag {string name = 1;string value = 2;
}message AgentGroup {string group_name = 1;...repeated AgentGroupTag tags = 3;
}message Agent {string agent_id = 1;...repeated string tags = 4;...
}

可以看到，iLogtail 的 Agent Group 和 Agent 均已经带有标签属性（tags），但两者的数据结构并不一致，Agent Group 是 Name-Value 数组，Agent 是字符串数组。

方案把它们都统一为 Name-Value 数组，并在 Agent Group 加上运算符，表达两种语义：“与”、“或”。这样，Agent Group 就拥有一个由标签和运算符组成的“表达式”，如果该表达式能够和 Agent 持有的标签匹配上，那么即可认为该 Agent 属于该分组。例如：

如果某个 Agent Group 的标签定义为 cluster: A 和 cluster: B，运算符定义为“或”，那么，所有持有 cluster: A 标签或者 cluster: B 标签其中之一的 Agent 都属于该分组。
如果某个 Agent Group 的标签定义为 cluster: A 和 group: B，运算符定义为“与”，那么，所有同时持有 cluster: A 标签和 group: B 标签的 Agent 才属于该分组。

KR4：解决 Config Server 容灾

Config Server 已经提供一套 Database 存储接口，只要实现了该接口的全部方法，即完成了持久化，leveldb 存储方案给了一个很好的示范。

type Database interface {Connect() errorGetMode() string // store modeClose() errorGet(table string, entityKey string) (interface{}, error)Add(table string, entityKey string, entity interface{}) errorUpdate(table string, entityKey string, entity interface{}) errorHas(table string, entityKey string) (bool, error)Delete(table string, entityKey string) errorGetAll(table string) ([ ]interface{}, error)GetWithField(table string, pairs ...interface{}) ([ ]interface{}, error)Count(table string) (int, error)WriteBatch(batch *Batch) error
}

于是，我们依次实现该接口的所有方法，每个方法，基本都是通过反射获得表的实体和主键，再调用 gorm 的 Create、Save、Delete、Count、Find 等方法，即完成了 gorm 的 CRUD 操作，也就是实现了持久化到 MySQL、Postgre、Sqlite、SQLServer，也实现了从数据库读取数据。

这里有一个细节，Database 接口定义了 WriteBatch 方法，本意是批量处理心跳请求，提高数据库写入的能力。如果是 MySQL，与之相应的处理办法是数据库事务。但是，在实践过程中，DBA 发现在事务中更新一批心跳数据，事务可能会变得过大，非常容易导致数据库死锁，放弃使用 WriteBatch 就恢复正常。由于心跳间隔默认 10 秒，即使一个心跳请求进行一次写入操作，在 Agent 数量上千个的规模下，那么，TPS 每秒也就上百，数据库压力并不算特别大。

KR5：iLogtail 自身状态监控

该方案可能最简单直接，在心跳请求的 extras 字段中上报 Agent 进程的 CPU 使用率和内存占用字节数。Config Server 最终会把这些信息保存到 MySQL 数据库，另外再安排一个定时任务做快照，多个快照按照时间序列形成趋势，再进行可视化分析，协助定位解决问题。

日志查询服务

上面解决了怎样把大量日志存储到 ElasticSearch 中，用户需求解决了一半。剩下一半，就是对用户提供查询服务，还需要一个界面。

理论上，Kibana 可以提供数据展示功能，但它主要面向管理员，而且是通用设计，不是面向日志服务，对于一些企业核心需求，例如：内部系统集成、多用户角色权限控制、日志库配置、多 ElasticSearch 集群管理，均无能为力，只适合在小团队、单集群使用。因此，要实现公司级别的统一界面，还需要自研一个最简版日志查询平台，才能与日志采集形成一个大的闭环，提供一个完整的解决方案。不过这一部分，基本上和 iLogtail 关系不大，暂且略过。

日志采集实践总结

逐一解决 iLogtail 替换 Logstash 的五大问题后，我们可以从容地说，iLogtail 在配置管理、采集、反馈等方面初步形成了一个小的闭环，无需过多依赖于其它工具，在技术上，是 Filebeat、Logstash 的最佳替代者。

我们使用的 iLogtail 是基于开源版 1.8.0 开发的，从 2024 年 2 月底正式上线至今，已稳定运行超过三个月，高峰期每小时采集日志超过百亿条，数据量是 TB 级别，服务业务应用 pod 上千个，ElasticSearch 存储节点数量上百个。

目前这些代码变更，在部分实现细节上，涉及到通信协议的修改，需要继续与社区负责人沟通，希望不久之后部分变更能够合并到 iLogtail 的主干分支。

以上五大问题，除了第一个 elasticsearch flusher，其它四个都与 Config Server 息息相关。因此，我曾经在社区钉钉群里说过：“Config Server 是皇冠上的明珠”，意思是它具有很高的用户价值，希望社区同学在这方面共同努力。

iLogtail 两周年系列宣传文章：

iLogtail 开源两周年：感恩遇见，畅想未来

iLogtail 进化论：重塑可观测采集的技术边界