卡夫卡容量规划答案

【问题标题】：Kafka Capacity Planning卡夫卡容量规划
【发布时间】：2018-08-28 06:51:21
【问题描述】：

我的雇主有一个 Kafka 集群来处理有价值的数据。有什么方法可以让我们了解我们的集群运行的容量百分比是多少？我们的集群可以处理更大的流量吗？一个节点宕机，我们还能活一个小时或一天吗？

【问题讨论】：

我们的集群运行的容量百分比——听起来你需要一个适当的硬件级别监控解决方案，而不仅仅是 Kafka JVM 监控。你能不能活下来取决于你没有提到的主题复制因子或者你的集群有多大
我有一个完整的 Prometheus 指标跟踪系统，它跟踪通过 JMX 报告的所有 Kafka 指标，还使用 Prometheus 节点导出器来跟踪系统指标，例如 CPU/RAM/磁盘使用等。您是指 JMX 监控而不是 JVM 监控吗？这是否是“适当的”监控解决方案？
JMX 是一种监控 JVM 的技术，所以这就是我的意思。 Kafka 占用 CPU 和磁盘资源并分配一些堆空间，并进行 GC-ing...如果不提供有关集群指标的更多信息，您在此处寻找的答案并不清楚。
如果我的 3 节点集群处理 10k 记录/秒，我能否将流量翻倍至 20k 记录/秒而不会出现性能问题？我什么时候需要一个 5 节点集群，它会提供多少容量？我可以查看我当前的集群使用情况并大致了解我正在运行的容量吗？
那么，您的 Kafka 数据磁盘平均已接近 70% 左右吗？你的 CPU 快用完了吗？ 20k 条记录时是否低于 50%？您是否使这些服务器的网卡饱和？流量或节点数量不是唯一的因素……你给了 Kafka 多少堆？多少个内核/CPUS？你可以拥有数十台小型服务器或几台强大的服务器...... Kafka 带有一个内置的性能测试器，我建议你尝试一些负载测试

标签： apache-kafka capacity-planning

【解决方案1】：

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

你的意思是容量，“我的 Kafka 集群会保存我的所有日志吗？”。这是一个函数：

主题的保留期
你的log compaction strategy
Kafka 消息的平均大小
您希望通过系统推送的消息量。
你的复制因子
如果你有compression turned on or not。另见：Cloudflare's Squeezing The Firehose article

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

就进一步的计算而言，围绕集群的大小以及在出现问题、磁盘空间、IO 之前可以关闭多少台机器——诸如此类的操作问题，这里有一些关于该主题的很棒的链接：

SO: Kafka Topology Best Practice (answer)
SO: How to decide Kafka Cluster size (answer)
Hortonworks: Kafka 0.9 Configuration Best Practices（我认为在过渡的几年里这方面没有太大变化）。

如果你的意思是容量，“我的 Kafka 集群，也就是我的 Kafka 集群中的“物理”盒子可以处理多少 Kafka 流量？”：即 Kafka 可以多快将数据存储在你的盒子上，那么这是另一个问题。如果您想知道（例如）哪种 AWS 实例类型对于处理 Kafka 数据最快，或者为 JVM 提供多少内存/您还可以在该代理上运行什么，那么这是一件好事。

这里值得注意的是，从 Unix 的角度来看，more the Unix kernel can use for a file cache 上的可用内存越多（所以不要天真地把它全部交给 JVM ;)）。而且网卡的类型/容量也很重要。

这里有几件有趣的事情要读：

考虑到理论上的最大值（“比您需要的更多”），可能值得测试您的个人代理/安装。使用 Ranger，一个类似的工具，或者只是在其中转储大量真实数据（也许同时测试你的数据管道，过渡到我的下一点......）

如果您指的是容量，“一条消息通过我的数据管道、生成到 Kafka、被微服务消费、转换、转换需要多长时间、平均时间或中间时间，产生成新的话题，再次消费……最终落地到微服务集群/数据管道的末端？”

这是一个函数：

你多少钱can partition the data
如果您的消费者组中有足够的消费者来处理所有分区
处理每个微服务需要多长时间

假设您有一个很好的分区级并发策略，我会在每条消息中添加跟踪信息。如果您想保持简单，傻瓜，可以在您的消息中添加“初始摄取时间”字段。对于更复杂的跟踪，您可以将跟踪 ID 与每条消息一起传递（初始生产者创建此 ID，所有其他消费者只需传递它，或者如果您将消息拆分为比特，则将其用作父辈等）。如果您有初始摄取时间，那么您的最后一个微服务可以检查当前时间并计算您的计算长度指标。

不同的微服务将需要不同的时间来处理它们的消息。如果你有一个跟踪 ID，你可以做一些有趣的事情，比如让每个微服务写入一个 Kafka 主题，了解当前服务处理当前消息所花费的时间。（将更多 Kafka 应用于您的 Kafka 问题！）。或者让每个主题都写入一个带有小 TTL 数据的搜索数据存储：例如，使用 Elasticsearch 查询最近的 Kafka 数据，这样您就可以跨主题获取搜索结果，这是我见过的一个巧妙的技巧。然后你可以看到微服务 5 很慢，你需要花一些时间进行性能调优。

编辑：您可能还幸运地使用LinkedIn's Burrow tool for Kafka 监控您的生产管道（看起来它仍在 2017 年积极获得爱），将监控您的消费者是否落后，以及与其他事物。

我希望这会有所帮助。不幸的是，这是一个表面上出现的更广泛的问题。归根结底，它是 % 磁盘空间、% CPU 和 % 你的 SLA 在数据管道周围的函数......这有时归结为独特的因素，比如你的消息大小是什么，你是什么类型的机器或想要运行什么机器，以及你的微服务有多快。 Kafka 这项技术可以处理惊人的流量：LinkedIn 不是一个小网站，而 Kafka 被互联网上一些流量最大的网站使用。理论上，一个构建良好的代理集群应该能够处理你扔给它的任何东西。实际部分涉及到您的工作流程、您的需求是什么、您实际使用它做什么等等。

【讨论】：