沈阳建站公司模板,wordpress主题官网,动画设计师是干什么的,jsp网站设计教学做一体化教程作者#xff1a;UC 浏览器后端工程师#xff0c;梁若羽
传统 ELK 方案
众所周知#xff0c;ELK 中的 E 指的是 ElasticSearch#xff0c;L 指的是 Logstash#xff0c;K 指的是 Kibana。Logstash 是功能强大的数据处理管道#xff0c;提供了复杂的数据转换、过滤和丰富…作者UC 浏览器后端工程师梁若羽
传统 ELK 方案
众所周知ELK 中的 E 指的是 ElasticSearchL 指的是 LogstashK 指的是 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 替换 LogstashHow 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 每秒也就上百数据库压力并不算特别大。
KR5iLogtail 自身状态监控
该方案可能最简单直接在心跳请求的 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 进化论重塑可观测采集的技术边界
