除此之外，还需求将异常信息的 toString() 内容打印进同一行日志里。由于异常堆栈都是另起一行，关于一些单行日志记载的系统，比如阿里云sls，基本看不到异常信息，还得爬进效劳器找日志堆栈。所以，还是很有必要将 e.toString() 写进参数里的，有些异常只看 e.toString() 的内容就可以定位了。为什么我这里要求运用 e.toString() 而不是 e.getMessage() ?由于假设是NullPointerException异常， e.getMessage() 前往空。改良后的代码：
log.error("{}|ReqId={}|ID={}|业务执行异常|参数={}|e={}",EVENT_NAME, ReqId, ID, param, e.toString(), e);
第六、若有循环，需求绑定循环主键
将下面例子加个业务上的循环，再来看下代码：
log.info("{}|ReqId={}|ID={}|末尾执行业务逻辑|参数={}",EVENT_NAME, ReqId, ID, param);
for (Key key : KeyList) {
log.info("{}|ReqId={}|ID={}|业务逻辑执行中|参数={}",EVENT_NAME, ReqId, ID, param);
}
log.info("{}|ReqId={}|ID={}|完毕执行业务逻辑|参数={}",EVENT_NAME, ReqId, ID, param);
这样产生的日志，十分不方便定位到详细的某次循环。假设循环体内出了异常，也不清楚详细是哪个Key 引发的。所以，遇到业务逻辑位于循环内的代码，应该打印出每次处置的 Key。改良后的代码：
log.info("{}|ReqId={}|ID={}|末尾执行业务逻辑|参数={}",EVENT_NAME, ReqId, ID, param);
for (Key key : KeyList) {
log.info("{}|ReqId={}|ID={}|Key={}|业务逻辑执行中|参数={}",EVENT_NAME, ReqId, ID, key, param);
}
log.info("{}|ReqId={}|ID={}|完毕执行业务逻辑|参数={}",EVENT_NAME, ReqId, ID, param);
公式
经过下面的剖析之后，我们可以总结出日志打印的公式：
EVENT_NAME={}|ReqId={}|Key={}|childKey={}|doing something|result={}
假设没有进程的话，ReqId 是可以省略的，Key 的数量也不一定只是一个，你也可以看状况给日志加一列 [start|end] ，表示业务进程的末尾和完毕。
JSON日志
之前有段时间写过 JSON 格式的日志，就是每一个行日志都是一个 JSON 串，下面讲到的日志可以称为单行日志。
举个例子：
Map<String, Object> logMap = new HashMap<>();
try{
logMap.put("EVENT_NAME", "monitor");
// ....
}finally {
LogUtil.save(JSON.toJSONString(logMap));
}
输入日志(为了方便查看，我已格式化)：
{
"EVENT_NAME": "monitor",
"ReqId": "654321",
"ID": "123456",
"success": true,
"param": {
"name": "zs",
"age": 14
}
}
JSON 日志自然绑定了央求进程，它最大的优势是输入序列化好的 JSON 串，十分方便离线对其各种操作。但比照于单行日志，代码嵌入性太高，需求经过 try..finally 代码块停止捕捉。
PS：以前我喜欢用 JSON 日志，如今我更喜欢用单行日志
【51CTO原创稿件，协作站点转载请注明原文作者和出处为51CTO.com】
【编辑引荐】
中间件（WebServer）破绽精讲／原理／实战／进攻／日志剖析
micropython基础入门（esp32/esp8266单片机物联网开发）
ITOP实际二次开发企业运用实战视频课程
Python自动化运维开发
开发者搜索，运用魔法打败魔法
(责任编辑：admin)