融合云的过度使用

Question

我们正在使用Confluent Cloud的一个非常普通的实例进行内部测试。因为这是基于云的，所以它们可以为您提供当月过去时要处理的数据量的统计信息。不幸的是，没有详细的统计信息-只是进入实例的字节，离开实例的字节以及存储空间。我们已经转移了大约2MB的存储在其中的数据，但是我们的转移量非常大，每天大约4GB。我们没有太多的使用者，而且它们都是最新的-在任何使用者反复从偏移量0或类似的值进行查询的情况下，似乎没有什么奇怪的事情。我的问题是：这是典型行为吗？是由于轮询吗？还是其他？

感谢@riferrei的评论。对不起，我感到困惑。要尝试帮助澄清，请查看以下图片：

这就是我所得到的。我的解释是，在3月期间，我们存储了至少390 KB的数据，但没有存储更多（390 KB = 1024 * 1024 * 0.2766 GB-小时/ 31天/ 24小时）。我们传输了2MB（0.0021 GB），根据账单，我们传输了138 GB的数据，大约每天4 GB。我试图了解这可能如何发生。

Answer 1

查理，

您的问题有点令人困惑，因此在尝试回答之前，让我尝试更深入地了解什么是真正的问题。

• 您是否在问为什么有4GB的数据而不是2MB？
• 您所指的典型行为是什么？

仅供参考，Confluent Cloud具有一组REST API，可用于更好地监视使用情况。这是它的文档：

https://docs.confluent.io/current/cloud/metrics-api.html

让我们知道问题出在哪里，以便我们提供相应的帮助。

谢谢

-@riferrei

Answer 2

我收到了Confluent支持的消息： 1）他们不会更改结算方式以忽略间接费用。他们的帐单文档已被修改，以表明它们收取协议开销的事实：

“向您收取群集中传入和传出的数据总量，包括与Kafka协议相关的请求开销。”

2）他们在常见问题解答（Metrics API）的常见问题解答中添加了一条注释，以阐明该注释当前不能用于对帐费用。该计划还将公开一个度量标准，其中包括有助于解决这些问题的协议字节，但有关细节仍在研究中。

因此，就目前而言，避免在Confluent Cloud账单上进行过多/无法解释的数据传输的建议解决方案是将fetch.wait.max.ms从其默认值100调整为类似5000的更大值。这会增加时间消费者轮询之间的差异，因此将减少由于轮询引起的网络开销。