一、获取Broker发送确认信息的时间戳 #

首先得明确：RecordMetadata里的timestamp其实是消息本身的时间戳——要么是生产者发送时主动设置的，要么是Broker接收消息时自动生成的，它并不等于Broker发送ACK的时间。

如果想追踪Broker发送ACK的时间，原生Kafka Producer API并没有直接提供这个字段，但可以通过两种方式实现：

• 客户端侧计时：在调用send()方法前记录当前时间戳（比如System.currentTimeMillis()），然后在Future的回调函数里记录收到ACK的时间，两者的差值就是从发送到收到确认的总延迟。示例代码如下：

  long sendStartTime = System.currentTimeMillis();
  producer.send(record, (metadata, exception) -> {
      long ackReceivedTime = System.currentTimeMillis();
      long latency = ackReceivedTime - sendStartTime;
      // 这里可以把延迟数据记录到监控系统或本地日志
  });
  

• Broker日志配合：如果需要Broker端精准的ACK发送时间，就得结合下面要讲的Broker日志来提取，对比客户端发送时间和Broker日志里的ACK发送时间，能更精准定位延迟出在哪个环节。

二、Broker日志设置打印确认相关信息 #

当然可以！Kafka Broker提供了专门的日志器来打印请求处理细节，包括Produce请求的ACK发送情况。你需要调整Broker的日志配置文件（通常是log4j.properties或log4j2.xml）：

1. 找到org.apache.kafka.server.request.logger这个日志器，把它的级别改成DEBUG：

   log4j.logger.org.apache.kafka.server.request.logger=DEBUG, requestAppender
   

2. 确保requestAppender的输出格式包含足够的信息，比如时间戳、请求类型、处理时长等。推荐配置格式：

   log4j.appender.requestAppender.layout.ConversionPattern=[%d] %p %c %m %X{request.time.ms} %X{request.duration.ms}%n
   

   其中request.time.ms是Broker开始处理请求的时间戳，request.duration.ms是请求从接收至发送ACK的总耗时，能帮你快速判断Broker端的处理延迟。

另外，如果你想深入排查延迟根源（比如磁盘IO、副本同步等），还可以把kafka.server.kafkaApis的日志级别设为DEBUG，它会打印更细节的请求处理步骤，比如消息落盘时间、副本同步状态等。

额外调试建议 #

同时开启Producer端的DEBUG日志（调整org.apache.kafka.clients.producer的日志级别），可以看到生产者发送消息的时间、网络传输细节，结合Broker的日志，就能清晰拆分延迟是来自客户端处理、网络传输还是Broker端的处理。

内容的提问来源于stack exchange，提问作者Mkt281001