我们正在使用一个相当普通的confluent cloud示例进行内部测试。因为这是基于云计算的，所以他们会提供统计数据，告诉你一个月要处理多少数据。不幸的是，这里没有详细的统计数据——只有进入示例的字节、示例的字节和存储。我们传入了存储在那里的大约2mb的数据，但是传出的数据太多了，每天大约4gb。我们没有太多的消费者，他们都是最新的-似乎没有什么奇怪的事情发生，任何消费者都在不断地从偏移量0或类似的东西查询。我的问题是：这是典型的行为吗？是因为投票吗？或者别的什么？
感谢@riferrei的评论。很抱歉给你添了麻烦。为了帮助澄清，请看以下图片：
这就是我所得到的。我的解释是，在3月份，我们至少存储了390 kb的数据，但存储量不多（390 kb=102410240.2766 gb小时/31天/24小时）。我们转入了2mb（0.0021GB），根据账单，我们转出了138GB的数据，即每天大约4GB。我在试着理解这怎么可能发生。
2条答案
按热度按时间93ze6v8z1#
我已经收到来自合流支持的消息：1）他们不会改变他们的账单来忽略管理费用。他们的计费文档已被修改，以显示他们收取协议开销的事实：
您将按传入和传出群集的数据总量计费，包括与kafka协议相关的请求开销
2） 他们在faq中为metricsapi添加了一个注解，说明它目前不能用于核对账单费用。该计划还将公开一个包含协议字节的度量，这将有助于解决这些问题，但具体细节仍在研究中。
因此，目前，建议的解决方案是将fetch.wait.max.ms从默认值100调整为更大的值，比如5000，以避免合流云账单上过度/无法解释的数据传输。这增加了消费者轮询之间的时间，因此将减少由于轮询而产生的网络开销。
qmelpv7a2#
查理，
你的问题有点让人困惑，所以在回答之前，让我试着更深入地了解真正的问题是什么。
你在问为什么有4gb的数据而不是2mb？
你指的典型行为是什么？
仅供参考，confluent cloud有一组RESTAPI，可以用来更好地监控使用情况。以下是它的文档：
https://docs.confluent.io/current/cloud/metrics-api.html
让我们知道真正的问题是什么，这样我们就可以相应地提供帮助。
谢谢，
--@里费雷