別再亂打日誌了,這樣纔是定位 bug 打日誌的方式!

概述

日常工作中,程序員需要經常處理線上的各種大小故障,如果業務代碼沒打印日誌或者日誌打印的不好,會極大的加大了定位問題的難度,使得解決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,有一些性能損耗。像我之前在唯品會參與的商品聚合服務,用的就是第一種方案,畢竟每一秒要處理上百萬的請求。

日誌里加入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滿天飛。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章