Log In Action
0. 生产环境要关闭debug日志，严禁在生产环境打debug级别日志
1. trace/debug/info 日志输出采用占位符的方式，禁止使用字符串拼接的方式
说明：logger.debug("=====" + b)，如果当前的日志级别是warn，上述日志不会打印，但会执行字符串拼接操作，如果b是对象，会调用b的toString()方法，这样会非常浪费系统资源，特别是当b是个大对象的时候。
bad case:
log.info("finish import seller " + sellerId)# 有现成的占位符的方式，不要使用String.format()，代码复杂log.info(String.format("group_id=%s",groupId)) good case:
logger.info("modify audit status, noteId: [{}], creativityId: [{}]", noteId, creativity.getId());个人也不推荐条件输出形式，用这种if的方式判断，显然不够优雅
if (logger.isDebugEnabled()) { logger.debug("Processing trade with id: " + id + " and symbol: " + symbol);}2. 使用[]进行参数变量隔离
这样的格式写法，可读性更好，对于排查问题又帮助。
good case:
logger.info("modify audit status, noteId: [{}], creativityId: [{}]", noteId, creativity.getId())3. 使用warn级别日志记录用户输入参数错误的情况，不要使用error级别日志记录此类错误，避免频繁报警
bad case:
log.error("Porch: 创建账号失败：传入参数有误：email={}, name={}", email, name)good case:
logger.warn("创建单元名称重复，unit_name={}", req.getUnitName())4. 异常信息应该包含两类信息：案发现场和异常堆栈信息
bad case:
log.error("调用sellerCenter服务异常")good case:
logger.error("RPC调用[inventory.multi_get_available]失败", e);如果抛出异常，不要记录error日志，由上层进行处理
如果既打错误日志，又抛出异常，会导致错误日志的重复打印。
bad case:
try { ... } catch (TException e) { logger.error("RPC调用[item_center.multi_get_item_union]失败", e); throw new IisException(IisResponseCode.ITEM_SYSTEM_ERROR); }good case:
try { ... } catch (TException e) { throw new IisException(IisResponseCode.ITEM_SYSTEM_ERROR); }logback VS log4j2 性能对比
linux:8核 2.4Hz32G 内存50个线程，每个线程写2W行日志logback:100W行日志总计耗时:7419 ms100W行日志总计耗时:7337 ms100W行日志总计耗时:7345 ms100W行日志总计耗时:7263 ms100W行日志总计耗时:7084 mslog4j2:100W行日志总计耗时:3815 ms100W行日志总计耗时:3904 ms100W行日志总计耗时:3743 ms100W行日志总计耗时:3766 ms100W行日志总计耗时:3755 ms总结
未来是log4j2的。
原文链接
https://segmentfault.com/a/11...