LivePerson如何通过基准测试优化GCP上的Logstash和Kafka性能

如何通过基准测试优化 LivePerson 在 GCP 上的 Logstash 和 Kafka 性能

来源 URL：https://www.elastic.co/blog/liveperson-observability 发布日期：2026-06-02T00:00:00.000Z

Markdown 内容：

通过对五种 GCP 机器类型在 Logstash 和 Kafka 上进行基准测试，LivePerson 的可观测性团队发现，基础设施选择（而不仅仅是管道配置）是在大规模场景下最具杠杆效应的成本优化决策之一。

摘要

• LivePerson 对五种 GCP 机器类型配置下的 Logstash 和 Kafka 进行了基准测试，找到了高吞吐量日志管道的最佳每事件成本比。
• n4d-standard-2（AMD Milan）在 Logstash 上实现了超过 e2-standard 基线 100% 的吞吐量提升。
• 类似的性能提升也出现在 Kafka 上，特别是在压缩编解码器选择（LZ4 与 GZIP）方面，进一步增加了显著的性能差异。
• 在每月成本提高约 25% 的情况下，n4d-standard-2 将每千事件处理成本从 $5.95 降至 $2.70 —— 在大规模场景下，处理成本降低了超过 50%。
• 需要更少的高性能实例，从而减少了 Kafka 集群规模并降低了整体基础设施开销。

挑战：管道增长速度超过了其优化的基础设施

随着 LivePerson 扩展其 Google Kubernetes Engine (GKE) 覆盖范围，并将工作负载从本地迁移到 Google Cloud Platform (GCP)，其日志管道也随之扩展，但底层基础设施的选择却没有跟上步伐。

该管道使用 Filebeat 作为日志生产者，Kafka 作为消息代理，Logstash 作为消费者和处理器，最终数据存储到 Elastic 中。随着系统规模扩大，Kafka 也随之扩展。由于每个 Logstash 实例都需要一个专用分区来消费数据，因此 Logstash 实例必须按比例扩展。更多的实例意味着更多的分区，更多的分区意味着更大的、更昂贵的 Kafka 集群。这种开销呈指数级增长。

基础设施运行在 e2-standard 实例上，这是 Google 的通用型选项，也是日志工作负载的常见默认配置。LivePerson 可观测性团队的 DevOps 工程师 Kiril Karamanolev 和 Strahil Nikolov 认为，存在改进的空间。然而，团队继承了现有架构，从未有过可以比较的基线。没有数据支持，就无法判断当前设置是否具有良好的价值，或者是否存在重大错失的机会。

此外，还有一个更微妙的问题：e2-standard 实例并未绑定到单一 CPU 平台，这意味着同一种机器类型可能根据可用性运行在 AMD 或 Intel 硬件上。对于计算密集型工作负载（如 Logstash），这一区别可能会对性能产生实际影响，但只有通过基准测试才能揭示差距的实际大小。

方法：对管道两端进行基准测试

为了避免假设，团队在 Logstash 和 Kafka 上进行了结构化的基准测试，将两者视为独立的工作流。

Logstash 基准测试 使用内置的 Logstash 基准测试框架，采用标准化测试数据和配置，确保不同实例类型之间的结果一致。评估的机器类型是那些在 GCP 上用于高吞吐量日志记录时被认为合理的选项：

• e2-standard-2（AMD）
• e2-standard-2（Intel）
• n2-standard-2
• t2d-standard-2
• n4d-standard-2

考虑到 AMD 和 Intel 版本的 e2-standard-2 可能存在显著的 CPU 级别性能差异，它们被视为单独的测试案例。

Kafka 基准测试 使用 Kafka 的原生生产者和消费者基准测试脚本，并通过自定义包装器简化执行过程。团队还测试了压缩编解码器选择的影响，特别是 GZIP（Filebeat 的默认压缩编解码器）与 LZ4，在写入吞吐量（Filebeat > Kafka）和读取吞吐量（Kafka > Logstash）方面的表现。AI 辅助分析被用来快速处理和解释结果。

在整个评估过程中，衡量指标不是每月实例成本，而是每美元的吞吐量（每秒事件数）——这才是生产环境中真正重要的指标。

结果

Logstash 性能

由 AMD Milan 架构支持的 n4d-standard-2 实现了决定性的结果：

• 吞吐量相比 e2-standard-2 基线提升了 100% 以上。
• 每美元可处理 370 个事件，是所有测试实例中成本效率最高的。
• 每千事件处理成本为 $2.70，而最不高效的配置为 $5.95 —— 处理成本降低了超过 50%。
• t2d-standard-2 排名第二，为那些 n4d 不可用的地区提供了强大的性价比。
• AMD 和 Intel 版本的 e2-standard-2 之间的性能差距足够大，足以在运营层面产生显著影响。
• 尽管 n2-standard-2 的月成本与 t2d-standard-2 几乎相同，但在效率排名中却位列最后。

最清晰的结论是：最便宜的每月实例并不一定是实际吞吐量考虑后的最具成本效益的选择。

Kafka 性能

对 Kafka 进行基准测试得出了两个关键发现：

• 机器类型选择对 Kafka 吞吐量有显著影响，这与 Logstash 的结果一致。
• 压缩编解码器的选择是一个独立变量，对写入和读取性能都有显著影响。从 GZIP 切换到 LZ4 在生产者和消费者端都带来了吞吐量提升。

同时测试管道的两部分至关重要。Kafka 的瓶颈会限制整个系统的性能：如果日志写入速度不够快，Filebeat 会积压；如果读取速度不够快，Logstash 会处于未充分利用状态。只优化其中一侧会导致不完整的画面。

基础设施足迹减少

最显著的成果是结构性的。更高的每实例吞吐量直接减少了处理相同数据量所需的 Logstash 实例数量。实例数量减少意味着需要更少的 Kafka 分区。分区数量减少则意味着一个规模更小、整体开销更低的 Kafka 集群。

优化效果是累积的：更好的实例选择减少了组件数量，从而降低了运营复杂性和成本，同时提升了性能。

更广泛的启示

云服务提供商持续发布新的实例系列。在初始部署时具有高性价比的选择，可能在一两年后已不再具备竞争力。LivePerson 的团队建议将基础设施基准测试视为一项定期进行的工作，而不仅仅是一次性决策，特别是对于那些运行高吞吐量可观测性工作负载的团队而言，计算效率直接影响成本和管道稳定性。

此处的具体发现基于 GCP。如果在 AWS 或 Azure 上进行同等的基准测试，可能会得出不同的结果。我们的建议并非针对特定的机器类型，而是方法论：在做出承诺之前先进行测量，并随着云环境的变化定期重新审视这一问题。

在大规模环境中衡量效率

对于像 LivePerson 这样的公司——其平台每天支持数百万企业客户的对话，并通过分布式 GKE 基础设施处理数十 TB 的日志数据——一个经过优化的管道与默认配置之间的差异并非抽象概念。它体现在基础设施支出、系统余量以及团队能够专注于更高价值工作的能力上，而不是管理一个过度扩张的集群。

本文所述的基准测试工作只是 LivePerson 完全更新其可观测性平台的一部分，随着其云迁移的成熟逐步推进。然而，这种方法论的应用远不止于单一的迁移项目。在一个云服务提供商不断推出新一代实例的环境中，从未重新评估基础设施选择的成本会随着时间悄然累积。

_本文中描述的功能或功能的发布和发布时间完全由 Elastic 自行决定。目前不可用的功能可能无法按时交付，甚至可能永远不会推出。_