关键词:
点击关注公众号,实用技术文章及时了解
来源:blog.csdn.net/linsongbin1/article/
details/90349661
概述
日常工作中,程序员需要经常处理线上的各种大小故障,如果业务代码没打印日志或者日志打印的不好,会极大的加大了定位问题的难度,使得解决bug的时间变长了。对于那种影响比较大的bug,处理时间是分秒必争的,慢几秒处理完,可能GMV就哗啦啦的掉了很多。
一个程序员是否优秀,其中一个判断维度就是:处理线上问题是否快狠准,而其中日志是帮我们快速定位问题的绝佳手段。
下面分享一下笔者平时在业务系统里记日志的一些手法和习惯,希望对大家有一些帮助。
请统一日志格式
日志格式最好是统一的,即方便查看定位问题又方便统计收集。我一般喜欢定义一个LogObject对象,里面定义日志的各个字段。例如:
import com.fasterxml.jackson.annotation.JsonInclude;
import com.fasterxml.jackson.annotation.JsonInclude.Include;
import com.fasterxml.jackson.annotation.JsonProperty;
public class LogObject
@JsonProperty(index = 1)
private String eventName;
@JsonProperty(index = 2)
private String traceId;
@JsonProperty(index = 3)
private String msg;
@JsonProperty(index = 4)
private long costTime;
@JsonProperty(index = 6)
private Integer userId;
@JsonProperty(index = 7)
private Object others;
@JsonProperty(index = 8)
private Object request;
@JsonProperty(index = 9)
private Object response;
public String getEventName()
return eventName;
public LogObject setEventName(String eventName)
this.eventName = eventName;
return this;
public Object getRequest()
return request;
public LogObject setRequest(Object request)
this.request = request;
return this;
public Object getResponse()
return response;
public LogObject setResponse(Object response)
this.response = response;
return this;
public String getMsg()
return msg;
public LogObject setMsg(String msg)
this.msg = msg;
return this;
public long getCostTime()
return costTime;
public LogObject setCostTime(long costTime)
this.costTime = costTime;
return this;
public Integer getUserId()
return userId;
public LogObject setUserId(Integer userId)
this.userId = userId;
return this;
public Object getOthers()
return others;
public LogObject setOthers(Object others)
this.others = others;
return this;
public String getTraceId()
return traceId;
public LogObject setTraceId(String traceId)
this.traceId = traceId;
return this;
traceId: 调用链id
eventName: 事件名称,一般就是业务方法名称
userId: C端用户id
msg: 结果消息
costTime: 接口响应时间
request: 接口请求入参
response: 接口返回值
others: 其他业务参数
使用链式的风格,方便设置字段的值:
long endTime = System.currentTimeMillis();
LogObject logObject = new LogObject();
logObject.setEventName(methodName)
.setMsg(msg)
.setTraceId(traceId)
.setUserId(backendId)
.setRequest(liveRoomPushOrderReqDto)
.setResponse(response)
.setCostTime((endTime - beginTime));
LOGGER.info(JSON.toJSONString(logObject));
当然最好还是封装出一个工具类出来,例如叫:LogTemplate,作为一个统一的入口。另外可以使用JsonProperty注解,指定字段的顺序,例如通过index=1,将eventName放置在最前面。
@JsonProperty(index = 1)
private String eventName;
将request和response放置在一起
将请求和返回值,放置在同一条日志里,有个好处,就是非常方便查看上下文日志。如果打印成两条,返回值那条可能被冲到很后面,而且也得再做一次grep操作,影响效率。
具体的日志如下:
"eventName":"createOrder",
"traceId":"createOrder_1574923602015",
"msg":"success",
"costTime":317,
"request":
"uId":111111111,
"skuList":[
"skuId":22222222,
"buyNum":1,
"buyPrice":8800,
]
,
"response":
"code":0,
"message":"操作成功",
"data":
"bigOrderId":"BIG2019",
"m2LOrderIds":
"MID2019":
"22222222":"LIT2019"
为了能拼成一条,有两种方案,一种是比较low的,直接在代码里使用try catch finally,例如:
@PostMapping(value = "/createOrder")
public JsonResult createOrder(@RequestBody Object request) throws Exception
String methodName = "/createOrder";
Integer backendId = null;
String msg = "success";
long beginTime = System.currentTimeMillis();
String traceId = "createOrder_"+beginTime;
JsonResult response = null;
try
OrderCreateRsp orderCreateRsp = orderOperateService.createOrder(request, traceId);
response = JsonResult.success(orderCreateRsp);
catch (Exception e)
msg = e.getMessage();
LOGGER.error(methodName+",userId:"+backendId+",request:"+ JsonHelper.toJson(request),e);
throw new BizException(0,"下单失败");
finally
long endTime = System.currentTimeMillis();
LogObject logObject = new LogObject();
logObject.setEventName(methodName)
.setMsg(msg)
.setTraceId(traceId)
.setUserId(backendId)
.setRequest(request)
.setResponse(response)
.setCostTime((endTime - beginTime));
LOGGER.info(JSON.toJSONString(logObject));
return response;
这种方案呢,有个缺点,就是每个业务方法都得处理日志,更好的方案是使用aop加thread local的方式,将请求统一拦截且将返回值和请求参数串起来,这个网络上的方案很多,这里就不阐述了。
对于对性能要求比较高的应用,反而推荐第一种方案,因为使用aop,有一些性能损耗。像我之前在唯品会参与的商品聚合服务,用的就是第一种方案,毕竟每一秒要处理上百万的请求。
另外,附送学习资源:Java进阶视频资源
日志里加入traceId
如果应用中已经使用了统一调用链监控方案,且能根据调用链id查询接口情况的,可以不用在代码里手动加入traceId。如果应用还没接入调用链系统,建议加一下traceId,尤其是针对聚合服务,需要调用中台各种微服务接口的。像聚合层下单业务,需要调用的微服务就有如下这么些:
营销系统
订单系统
支付系统
下单业务调用这些接口的时候,如果没有使用traceId进行跟踪的话,当下单失败的时候,到底是哪个微服务接口失败了,就比较难找。下面以小程序端,调用聚合层下单接口的例子作为展示:
//营销系统
"eventName":"pms/getInfo",
"traceId":"createOrder_1575270928956",
"msg":"success",
"costTime":2,
"userId":1111111111,
"request":
"userId":1111111111,
"skuList":[
"skuId":2222,
"skuPrice":65900,
"buyNum":1,
"activityType":0,
"activityId":0,
],
,
"response":
"result":1,
"msg":"success",
"data":
"realPayFee":100,
//订单系统
"eventName":"orderservice/createOrder",
"traceId":"createOrder_1575270928956",
"msg":"success",
"costTime":29,
"userId":null,
"request":
"skuList":[
"skuId":2222,
"buyNum":1,
"buyPrice":65900,
],
,
"response":
"result":"200",
"msg":"调用成功",
"data":
"bigOrderId":"BIG2019",
"m2LOrderIds":
"MID2019":
"88258135":"LIT2019"
//支付系统
"eventName":"payservice/pay",
"traceId":"createOrder_1575270928956",
"msg":"success",
"costTime":301,
"request":
"orderId":"BIG2019",
"paySubject":"测试",
"totalFee":65900,
,
"response":
"requestId":"test",
"code":0,
"message":"操作成功",
"data":
"payId":123,
"orderId":"BIG2019",
"tradeType":"JSAPI",
"perpayId":"test",
"nonceStr":"test",
"appId":"test",
"signType":"MD5",
"sign":"test",
"timeStamp":"1575270929"
可以看到聚合层需要调用营销、订单和支付三个应用的接口,调用的过程中,使用traceId为createOrder_1575270928956
的串了起来,这样我们只需要grep这个traceId就可以把所有相关的调用和上下文找出来。
traceId如何生成呢,一种简单的做法是,使用System.currentTimeMillis()
加上业务接口名字,如:
long beginTime = System.currentTimeMillis();
String traceId = "createOrder_"+beginTime;
加traceId会侵入到业务方法里,比如说:
public void createOrder(Object obj)
long beginTime = System.currentTimeMillis();
String traceId = "createOrder_"+beginTime;
pmsService.getInfo(obj,traceId);
orderService.createOrder(obj,traceId);
payService.getPrepayId(obj,traceId);
像pmsService这些内部的service方法,都需要加一个traceId字段,目前我觉得还好,要是觉得入侵了,也可以考虑thread local的方式,处理请求的时候,为当前线程存储一下traceId,然后在业务方法里,再从当前线程里拿出来,避免接口方法里的traceId满天飞。
推荐:
PS:因为公众号平台更改了推送规则,如果不想错过内容,记得读完点一下“在看”,加个“星标”,这样每次新文章推送才会第一时间出现在你的订阅列表里。点“在看”支持我们吧!
刷脸认证如何实现人脸又快又准完成校验?
互联网飞速发展的今天,各种App的验证方法也越来越方便用户,从一开始的密码输入,到后来的指纹解锁,演变成如今的刷脸认证。刷个脸,就可以解锁设备、在线/线下支付、通过门禁、快速检票等。与此同时也伴随了很多安... 查看详情
yolov6又快又准的目标检测框架已开源
siou精度是最高的,其次是yoloe,但是没开源:即插即用|SIoU实现50.3AP+7.6ms检测速度精度、速度完美超越YoloV5、YoloX_AI视觉网奇的博客-CSDN博客先看YOLOv6精度:ModelSizemAPval0.5:0.95SpeedV100fp16b32(ms)SpeedV100fp32b32(ms)Spe 查看详情
别再乱打日志了,这样才是定位bug打日志的方式!(代码片段)
概述日常工作中,程序员需要经常处理线上的各种大小故障,如果业务代码没打印日志或者日志打印的不好,会极大的加大了定位问题的难度,使得解决bug的时间变长了。对于那种影响比较大的bug,处理时间... 查看详情
[js入门到进阶]手写解析url参数的工具,并部署。用起来又快又爽!(代码片段)
...端日志系统搜索。面试字节跳动和阿里巴巴时,都遇到了这样的面试题:(不许查阅任何API,使用没代码提示的记事本)请手写函数,可以解析URL中的参数。解决思路针对上文第一个场景,我们更常见的做法是,搜索「URL解析」... 查看详情
yolov6:又快又准的目标检测框架开源啦
近日,美团视觉智能部研发了一款致力于工业应用的目标检测框架YOLOv6,能够同时专注于检测的精度和推理效率。在研发过程中,视觉智能部不断进行了探索和优化,同时吸取借鉴了学术界和工业界的一些前沿进... 查看详情
又快又好,行人检测和人脸检测和人脸关键点检测(c++/android源码)(代码片段)
又快又好,行人检测(人体检测)和人脸检测和人脸关键点检测(C++/Android)目录又快又好,行人检测(人体检测)和人脸检测和人脸关键点检测(C++/Android)1.前言2.项目说明... 查看详情
别乱用uuid了,自增id和uuid性能差距你测试过吗?(代码片段)
点击关注公众号,实用技术文章及时了解目录一、准备表&数据二、500w级数据测试2.1录入500W数据,自增ID节省一半磁盘空间2.2单个数据走索引查询,自增id和uuid相差不大2.3范围like查询,自增ID性能优于UUID2.4写入... 查看详情
如何利用开源插件?又快又好地搞好数据接口开发,连通不同应用系统(代码片段)
目录前言介绍:开源插件TapdataPDK快速开始目标数据库接入准备环境下载源码并编译创建目标数据库的Connector工程开发完成之后通过TDD进行测试验证如何提交到PDK开源项目彩蛋前言介绍:毫不夸张地说,没有开发者还... 查看详情
卧槽,物色了一款隐秘拍摄神器,别乱用!
大家好,我是鸟哥,一个半路出家的程序员!又是一篇废旧手机改造系列!最近刚提新车,所以这次我准备把一台不用的手机改造成一台功能超级强大的行车记录仪。你肯定会说,“简单!手机本身就... 查看详情
看了这篇文章,比同事更快找到bug!(代码片段)
...?下面给大家介绍几种方法,帮助你轻松找到程序的bug。日志篇在上篇文章中,笔者介绍了《在Java代码中打日志需要注意什么?》。打日志是非常重要的,因为日志能够提供一些运行时的信息,非常有助于我们快速定位问题。... 查看详情
五分钟实现,一个rnapp开发调试工具(代码片段)
...开发人员,我们经常做着费力不“讨好”的事情,这样占用我们不少时间:定位bug,通常流程是:按测试同学的的bug描述,登录指定的账号走一遍验证一下问题是否存在。若bug存在则,在app的调试模式下再验证是否存在,... 查看详情
bug定位分析方法(代码片段)
...出相应的逻辑流转图,根据业务逻辑重现梳理一遍。这样可以协助自己更快的定位到问题。如果觉得麻烦,可以直接使用脑图来绘制,更为简单快捷。比如像这样日志分析在业务出现一些异常情况时,需要增加日... 查看详情
bug定位分析方法(代码片段)
...出相应的逻辑流转图,根据业务逻辑重现梳理一遍。这样可以协助自己更快的定位到问题。如果觉得麻烦,可以直接使用脑图来绘制,更为简单快捷。比如像这样日志分析在业务出现一些异常情况时,需要增加日... 查看详情
别乱用了,这才是springboot停机的正确方式!!!
点击关注公众号,实用技术文章及时了解来源:blog.csdn.net/alex_xfboy/article/details/90404691再谈为了提醒明知故犯(在一坑里迭倒两次不是不多见),由于业务系统中大量使用了springBootembeddedtomcat的模式运行,... 查看详情
所谓的动态ip和静态ip的区别是什么?(代码片段)
...?下面给大家介绍几种方法,帮助你轻松找到程序的bug。日志篇在上篇文章中,笔者介绍了《在Java代码中打日志需要注意什么?》。打日志是非常重要的,因为日志能够提供一些运行时的信息,非常有助于我们快速定位问题。... 查看详情
怎么让word编辑公式又快又好
...几个简单的公式。那这篇文章就告诉Word公式怎么编辑才又快又好。想要在Word中编辑出完美的公式,那MathType是一个非常有必要的工具。如 查看详情
it运维如何又快又好的进行数据备份?
...机的硬盘或阵列复制到其它的存储介质的过程。那么如何又快又好的进行数据备份?用什么工具好?如何又快又好的进行数据备份?这里我给大家推荐一个非常好用的数据自动化备份工具,那就是行云管家。在行... 查看详情
lombok同时使用@data和@builder的巨坑,千万别乱用!
来源:juejin.cn/post/7103011031672176677问题背景Lombok同时使用@Data和@Builder,会出现构建无参构造器报错!最终导致编译不通过。如下图:Lombok@Data和@Builder分别单独分析用法Lombok使⽤@Data可以⽣成⽆参构造... 查看详情