Kafka 容量规划

Question

Kafka 容量规划

4

我的雇主有一个处理有价值数据的Kafka集群。有没有办法知道我们的集群正在以多少百分比的容量运行？我们的集群能够处理更大的流量吗？如果单个节点故障，我们是否能够存活一小时或一天？

- clay

“集群运行百分比容量”--听起来你需要一个适当的硬件级别监控解决方案，而不仅仅是Kafka JVM监控。你能否存活取决于主题复制因子，这是你没有提到的，以及你的集群有多大。 - OneCricketeer

我有一个完整的Prometheus指标跟踪系统，可以跟踪通过JMX报告的所有Kafka指标，并使用Prometheus节点导出器来跟踪系统指标，如CPU / RAM / 磁盘使用等。你是不是想说JMX监控而不是JVM监控？这是一个“合适”的监控解决方案吗？ - clay

JMX是一种监视JVM的技术，这就是我的意思。Kafka占用CPU和磁盘资源，并分配一些堆空间，并进行垃圾回收...如果没有提供有关集群指标的更多信息，您要寻找什么答案并不是很清楚。 - OneCricketeer

如果我的三节点集群处理每秒10k条记录，那么我能否将流量增加到20k条/秒而不会出现性能问题？什么情况下需要5个节点的集群以及它可以提供多少额外容量？我能否查看当前集群的使用情况并大致了解我正在运行的容量？ - clay

1

你的Kafka数据磁盘平均使用率接近70%了吗？你的CPU是否快要达到极限？在20k条记录下，它是否低于50%？你是否正在饱和这些服务器的网络卡？流量或节点数量不是唯一的因素...你给Kafka多少堆内存？有多少个核心/ CPU？你可以拥有数十个小型服务器或几个强大的服务器... Kafka带有内置性能测试器，建议你尝试一些负载测试。 - OneCricketeer

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- RyanWilcox · Accepted Answer

我不确定你的意思，所以我会采取广泛的方法。

你所说的容量是指，“我的Kafka集群能否容纳所有的日志？”这取决于以下几个因素：

主题的保留期
您的日志压缩策略
Kafka消息的平均大小
您预计通过系统推送的消息数量
您的复制因子
是否开启压缩。另请参阅：Cloudflare的Squeezing The Firehose文章

如果您有两周的保留期，没有日志压缩（当一条消息消失时，它就消失了），没有日志压缩，并且在这两周内您预计推送10,000条1k大小的消息（在这两周内）并复制3次……您最好有30,000k的存储空间，或者30MB。

至于进一步的计算，如集群的大小和多少台机器可以停机而不会出现问题、磁盘空间、IO等操作问题，以下是一些关于该主题的非常棒的链接：

SO: Kafka拓扑最佳实践（答案）
SO: 如何决定Kafka集群大小（答案）
Hortonworks：Kafka 0.9配置最佳实践（我认为在这方面并没有太多变化）。

如果您说的容量是指，“我的Kafka集群，即Kafka集群中的“物理”盒子可以处理多少Kafka流量？”：也就是说，Kafka可以在您的盒子上存储数据的速度有多快，那么这是另一个问题。如果您想知道（例如）哪种AWS实例类型最适合处理Kafka数据，或者要给JVM分配多少内存/在该代理上还可以运行什么其他内容等等，那么这是一件好事。

值得注意的是，从Unix的角度来看，您在盒子上拥有的空闲内存越多，Unix内核可以用于文件缓存的空间就越多（因此不要只是简单地全部分配给JVM；)）。网络卡的类型/容量也非常重要。

这里有一些有趣的阅读材料：

考虑到理论最大值（“超过您所需的”）的想法，测试您的单个代理/安装可能是值得的。可以使用Ranger或类似工具，也可以将大量真实数据转储到其中（也许同时测试数据管道，转入下一个要点...）

如果容量是指，“一条消息通过我的数据管道需要多长时间（平均值或中位数），从生成到传递到Kafka，由微服务消耗，经过转换，生成新主题，再次消耗... 最终落在微服务集群/数据管道的末端？”

这是一个关于以下内容的函数：

您可以对数据进行分区的数量
如果您的消费者组中有足够的消费者来处理所有分区
每个微服务处理所需的时间

假设您已经有了关于分区级并发的良好策略，我建议每个消息都添加跟踪信息。如果你想保持简单，可以在消息中添加“初始摄取时间”字段。如果需要更复杂的跟踪，可以使用每个消息的跟踪ID（最初的生产者创建此ID，所有其他消费者只需将其传递或在将消息拆分为位时用于父项）。如果有初始摄取时间，则您的最后一个微服务可以检查当前时间并计算计算长度指标。

不同的微服务将花费不同的时间来处理它们的消息。如果您有追踪ID，您可以做一些有趣的事情，比如让每个微服务写入一个Kafka主题，记录当前服务处理当前消息所花费的时间。（在您的Kafka问题上应用更多Kafka！）。或者让每个主题写入带有短期TTL数据的搜索数据存储：例如，使用Elasticsearch查询最近的Kafka数据，以便您可以跨主题获取搜索结果。然后，您可以看到第5个微服务很慢，需要花费一些时间进行性能调优。

编辑：您还可以使用LinkedIn的Kafka Burrow工具（似乎在2017年仍在积极更新）监控生产管道，以查看消费者是否落后以及其他信息。

我希望这可以帮到您。这是一个看似简单，但实际上更加广泛的问题。最终，它取决于磁盘空间占用率、CPU使用率以及与数据处理流程相关的SLA百分比......有时这涉及到一些独特的因素，例如消息大小、所使用的机器类型或者想要运行的机器类型以及微服务的速度。Kafka技术可以处理大量的流量：LinkedIn不是一个小型网站，而Kafka被一些互联网上最繁忙的网站所使用。一个良好构建的broker集群应该能够理论上处理任何你投入其中的东西。实际上，当你需要考虑工作流程、需求以及实际操作等方面时，才会遇到实际问题。