我们正在使用一个非常普通的 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。我试图了解这怎么可能发生。
查理，
您的问题有点令人困惑，所以在尝试回答之前让我尝试更深入地了解这里的真正问题。
仅供参考，Confluent Cloud 有一组 REST API，可用于更好地监控使用情况。这是它的文档：
https://docs.confluent.io/current/cloud/metrics-api.html
让我们知道真正的问题是什么，以便我们提供相应的帮助。
谢谢，
--@riferrei
我从 Confluent 支持部门收到的消息是：1) 他们不会更改计费以省略间接费用。他们的计费文档已被修改，以说明他们收取协议开销的事实：
“您需要为传入和传出集群的数据总量付费，包括与 Kafka 协议相关的请求开销。”
2) 他们在 Metrics API 的常见问题解答中添加了一条注释，阐明它目前不能用于核对账单费用。该计划还公开一个包含协议字节的指标，这将有助于解决这些问题，但相关细节仍在研究中。
因此，目前，为了避免 Confluent Cloud 账单上出现过多/无法解释的数据传输，建议的解决方案是将 fetch.wait.max.ms 从其默认值 100 调整为更大的值，例如 5000。这会增加消费者投票之间的时间因此将减少由于轮询而产生的网络开销。