在某客户日志数据迁移到火山引擎运用 ELK 生态的事例中，因为客户反应之前 Logstash 常常产生数据丢掉和搜集功能较差的运用痛点，咱们测验运用 Flink 代替了传统的 Logstash 来作为日志数据解析、转化以及写入 ElasticSearch 的组件，得到了该客户的认可，而且现已成功协助用户迁移到火山。现在，Flink 现已支撑该事务高峰期 1000 k/s 的数据写入。
本文首要介绍 Logstash 的运用痛点以及迁移到 Flink 的优势，探索在 ELK 生态中，Flink 替换 Logstash 的更多或许，推动用户从 EL（Logstash）K 迁移到 EF（Flink）K。
Logstash 简介
ELK 是一套开源的日志及数据监控和剖析系统，首要是三个组件的简称：Elasticsearch, Logstash and Kibana，功用涵盖了从日志搜集、解析、查询、剖析、可视化等完好的处理方案。
上图描绘了 ELK 里各组件的关系，根据 libbeat **结构的各种 beats 工具将日志及各种数据进行搜集，可以直接写入 ES，也可以先写入到 Logstash 进行解析和处理再写入到 ES。如下图所示，Logstash 首要包含三个部分：
- 输入插件：担任从各种不同的 source 读取数据，如文件、beats、Kafka等；
- 过滤插件：担任按照指定的配置修改和处理数据，如 grok 插件可以从固定日志格局中提取对应信息，drop 插件可以丢掉诸如 debug 日志等能力；
- 输出插件：担任将成果数据输出，如将处理后的日志数据写入 ES 中。
Logstash 运用痛点
数据易丢掉
Logstash 默认运用内存作为写入数据的缓存，一旦产生重启或许反常退出的时分，这部分数据就会产生丢掉。尽管 Logstash 也供给了耐久化行列来处理这个问题，但是因为数据依然是写入机器磁盘中，当产生单机毛病的时分，数据同样也会丢掉。一起，数据周期性的落盘也会对数据的处理功能带来巨大的影响。
排查本钱高
当日志数据格局不符合规范（如非规范 Json）形成丢掉数据较多的状况时，需要在数据搜集、数据解析、写 ES 等全链路排查数据丢掉的原因，一般需要检查机器日志，搜集、处理节点较多的时分，排查本钱也比较高。
除了日志数据自身不规范外，当因为其他原因导致数据不能正确处理的其他状况，比方写 ES 各种反常，这部分数据也极易产生丢掉，也需要检查日志进行跟踪和定位。尽管 Logstash 单独供给了死信行列来处理这些状况，但是在这个链路丢掉的数据依然有排查的本钱。
搜集、解析功能差
Logstash 供给的各种插件根本都是用 Ruby 实现的，尽管 Logstash 自身也运转在 Java 的 JVM 上，并通过 JRuby 将各种插件也跑在 JVM 上，但是相比 Flink 100% Java 语言运转和履行功率会更低一些。
当敞开耐久化行列（为了确保数据尽或许少丢掉），因为数据需要频繁写磁盘，Logstash 处理功能会进一步降低。一起，Logstash 处理功能较差也是业界的一大一致。
不支撑资源动态扩缩容
因为 Logstash 自身的资源布置不支撑动态扩缩容，会形成低峰期较大的资源浪费。在该客户的事例中，事务高峰期的日志数据和活动期间的日志数据是在低峰期数据的 24 倍左右（高峰期 100w QPS，低峰期 50k QPS），且呈周期性改变。因而实践在事务低峰期，运用很少的资源就可以确保日志数据的搜集和解析，所以支撑资源动态扩缩容是有必要且必要的。
Flink 运用优势
数据处理支撑“at-least-once”语义
Flink 根据状况引进分布式 checkpoint 机制，用于确保数据消费的“at-least-once”语义。其中状况保存通过定期耐久化到远端可靠存储（HDFS）来确保状况不丢掉。
需要阐明的是，Flink 自身根据状况是可以做到严格意义上的“exactly-once”语义的，即消费和处理的不丢不重。假如 ES 支撑了主键的配置，也就是相同主键写入是幂等的状况下，则能在全链路做到“exactly-once”语义。
在该客户的事例中，咱们通过工具读 Kafka 来核算写入条数，跟实践 Flink 写入 ES 的条数进行对比，证明了数据消费的“at-least-once”语义，处理了客户在友商上运用 Logstash 常常产生数据丢掉的痛点。
灵活的反常数据处理
关于 Kafka 中解析失利的数据（比方格局为非 Json 的数据），在该客户的事例中，咱们支撑了这部分的反常数据写入独立的 ES 索引，一起标识数据写入原因（非规范 Json）；关于写 ES 反常失利的数据，咱们同样会将这部分数据写入独立的 ES 索引，而且记载写 ES 失利的原因，比方字段数超 1000，数据类型和模板界说的不一致等。
可以便利用户对反常日志数据做管理，如该客户推所有的上游事务日志规范 Json 化写入 Kafka 等。相对的，在该客户运用原友商的 Lostash 写入 ES 的时分，这部分的数据丢掉不只不易排查（乃至不易知晓），而且也难以管理（丢掉了写 ES 失利的原因）。
高吞吐、低推迟的处理功能
Flink 作为当前最热的流式处理引擎，支撑高吞吐、低推迟的处理日志数据，对数据处理可以到达秒级的推迟且通过业界在其他 Kafka 数据更杂乱处理场景的大量验证，安稳而可靠。
资源主动扩缩容
在字节 Serverless Flink 中，咱们也将支撑资源随着写入 QPS 的动态调整，可以节约较大的资源。现在，该功用现已在字节内部得到了实践验证，在资源利用上取得了较大的收益。
更杂乱的数据剖析能力
相较于传统的 ELK 链路，在 Logstash 中对日志数据进行简略的数据格局匹配、内容替换等处理，Flink 还支撑更强壮的数据剖析和处理，支撑事情和事务处理时刻，支撑窗口核算、聚合、去重等。能对日志数据做更强壮的数据处理和剖析，将处理数据写入 ES 后，能实现 OLAP 数据查询和剖析。
这部分数据处理和剖析的能力也在字节内部得到了广泛的应用，为事务带来了许多实践的收益。
Flink vs Logstash 总结
对 Logstash 进行简略介绍后，结合该客户的事例，这里对比下 Flink 和 Logstash 的优劣：
【火山引擎流式核算 Flink版】
火山引擎流式核算 Flink 版是脱胎于字节跳动最佳实践的新一代全托管、 云原生 实时核算渠道。 一套代码轻松搞定流批一体，助力企业将大数据渠道向云原生、实时化、智能化方向晋级。
现在，流式核算 Flink****版 新人首购专享活动正在进行中。注册用户初次购买 Flink 产品包年包月，即可享受首月4折优惠，欢迎咨询体会。
「了解更多产品信息」
【Workshop：字节跳动云原生大数据渠道体会坊】
11月18日上海举办的 Data & AI Con Shanghai 2023 大会上，将特别设立云原生 大规模核算实践专场，您将可以亲自体会字节跳动 Flink 代替 Logstash 的日志导入方案，更有机会收取海量大礼。
「扫码报名」
参考资料
