❶ log4j日志文件,要记录成什么格式的,什么样的比较常用
有几个级别：
static Level DEBUG
DEBUG Level指出细粒度信息事件对调试应用程序是非常有帮助的。
static Level INFO
INFO level表明 消息在粗粒度级别上突出强调应用程序的运行过程。
static Level WARN
WARN level表明会出现潜在错误的情形。
static Level ERROR
ERROR level指出虽然发生错误事件，但仍然不影响系统的继续运行。
static Level FATAL
FATAL level指出每个严重的错误事件将会导致应用程序的退出。
另外，还有两个可用的特别的日志记录级别:
static Level ALL
ALL Level是最低等级的，用于打开所有日志记录。
static Level OFF
OFF Level是最高等级的，用于关闭所有日志记录。
一般指定为：xxx.log
可以将service和数据操作的sql分开：
log4j.rootLogger=INFO,rootDailyRollingFile
log4j.logger.java.sql=DEBUG, SqlDailyRollingFile
##### rootDailyRollingFile#####
log4j.appender.rootDailyRollingFile=org.apache.log4j.DailyRollingFileAppender
log4j.appender.rootDailyRollingFile.File=d:\\weblog\\testprj\\root.log
log4j.appender.rootDailyRollingFile.DatePattern='.'yyyy-MM-dd
log4j.appender.rootDailyRollingFile.layout=org.apache.log4j.PatternLayout
log4j.appender.rootDailyRollingFile.layout.ConversionPattern=%-r %d [%t] %-5p %c.%M(%F:%L) %x - %m%n
❷ kafka低版本的怎么用java查询给定broker上所有的日志目录信息
1. 日志存储格式
最新版本的kafka日志是以批为单位进行日志存储的，所谓的批指的是kafka会将多条日志压缩到同一个batch中，然后以batch为单位进行后续的诸如索引的创建和消息的查询等工作。
对于每个批次而言，其默认大小为4KB，并且保存了整个批次的起始位移和时间戳等元数据信息，而对于每条消息而言，其位移和时间戳等元数据存储的则是相对于整个批次的元数据的增量，通过这种方式，kafka能够减少每条消息中数据占用的磁盘空间。
这里我们首先展示一下每个批次的数据格式：
图中K1的数据有V1、V3和V4，经过压缩之后只有V4保留了下来，K2的数据则有V2、V6和V10，压缩之后也只有V10保留了下来；同理可推断其他的Key的数据。
另外需要注意的是，kafka开启日志压缩使用的是log.cleanup.policy，其默认值为delete，也即我们正常使用的策略，如果将其设置为compaction，则开启了日志压缩策略，但是需要注意的是，开启了日志压缩策略并不代表kafka会清理历史数据，只有将log.cleaner.enable设置为true才会定时清理历史数据。
在kafka中，其本身也在使用日志压缩策略，主要体现在kafka消息的偏移量存储。在旧版本中，kafka将每个consumer分组当前消费的偏移量信息保存在zookeeper中，但是由于zookeeper是一款分布式协调工具，其对于读操作具有非常高的性能，但是对于写操作性能比较低，而consumer的位移提交动作是非常频繁的，这势必会导致zookeeper成为kafka消息消费的瓶颈。
因而在最新版本中，kafka将分组消费的位移数据存储在了一个特殊的topic中，即__consumer_offsets，由于每个分组group的位移信息都会提交到该topic，因而kafka默认为其设置了非常多的分区，也即50个分区。
另外，consumer在提交位移时，使用的key为groupId+topic+partition，而值则为当前提交的位移，也就是说，对于每一个分组所消费的topic的partition，其都只会保留最新的位移。如果consumer需要读取位移，那么只需要按照上述格式组装key，然后在该topic中读取最新的消息数据即可。