Log In Action

时间 2019-11-16

标签 log action 繁體版

原文原文链接

Log In Action

0. 生产环境要关闭debug日志，严禁在生产环境打debug级别日志

1. trace/debug/info 日志输出采用占位符的方式，禁止使用字符串拼接的方式

说明：logger.debug("=====" + b)，若是当前的日志级别是warn，上述日志不会打印，但会执行字符串拼接操做，若是b是对象，会调用b的toString()方法，这样会很是浪费系统资源，特别是当b是个大对象的时候。linux

bad case:segmentfault

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. 使用[]进行参数变量隔离

这样的格式写法，可读性更好，对于排查问题又帮助。debug

good case:日志

logger.info("modify audit status, noteId: [{}], creativityId: [{}]", noteId, creativity.getId())

3. 使用warn级别日志记录用户输入参数错误的状况，不要使用error级别日志记录此类错误，避免频繁报警

bad case:code

log.error("Porch: 建立帐号失败：传入参数有误：email={}, name={}", email, name)

good case:orm

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 BaseException(ResponseCode.ITEM_SYSTEM_ERROR);
    }

good case:

try {
     ...   
    } catch (TException e) {
        // e必须传递给从新抛出的异常，不然会致使异常栈的丢失
        throw new BaseException("xxxx", e);
    }

logback VS log4j2 性能对比

linux:
8核 2.4Hz
32G 内存

50个线程，每一个线程写2W行日志

logback:
100W行日志总计耗时:7419 ms
100W行日志总计耗时:7337 ms
100W行日志总计耗时:7345 ms
100W行日志总计耗时:7263 ms
100W行日志总计耗时:7084 ms

log4j2:
100W行日志总计耗时:3815 ms
100W行日志总计耗时:3904 ms
100W行日志总计耗时:3743 ms
100W行日志总计耗时:3766 ms
100W行日志总计耗时:3755 ms

总结

将来是log4j2的。

原文连接

https://segmentfault.com/a/11...