XStack

Deep into details

0%

日志记录经验小结

发表于 更新于

日志的区分与汇总方式: 一次事务采用独特标记与事务内异步事务的附加标记方式, 说明如下:#

  1. 为每次HTTP事务分配一个id, 本次事务内全部日志都输出该标记, 方便查找时以此为唯一索引, 可以查找这次请求过程中所有相关输出
  2. 单次事务中, 所有对外部依赖的操作(包括接口请求,Redis操作,MongoDB操作等)均加独特id标记, 并附加到请求的id后, 构成形如: <user-request-id>:<redis-request-id>的形式, 内部再有细节划分则追加到后面, 以冒号分隔(其它分隔符也可以, 主要是为了更好的使用阿里云日志的搜索功能)
    id生成算法:
    1
    2
    3
    4
    5
    // 10(或11)位的短字符串
    Math.random().toString(36).substr(2)

    // 唯一程度更高的19(或18)位字符串
    Math.random().toString(36).substr(2)+new Date().getTime().toString(36)

    长内容的隐藏与查找#

    在使用id进行查找时, 存在着有些内容返回过多, 不需要展示的情况(如请求的响应信息, 只在必要时才需要查找出来), 此时, 最好不要使用id前缀, 否则容易被长内容干扰, 抓不住重点.
    为了解决这个问题, 可以在存在长内容的时候使用两条记录: 一条内容包含id, 同时包含一个随机串, 通过随机串可以查找到具体内容:
    1
    2
    log.info(logPrefix + ":请求信息key:" + uniqueKey);
    log.info(uniqueKey + ": 请求详细信息: " + result);

    日志记录的内容:#

  3. 标识部分: 用户标识/页面标识/关键判定/
  4. 内容部分: Redis的k-v/请求数据/响应数据/错误信息/步骤信息

什么时候需要加日志:#

  1. 所有的外部依赖(请求/Redis/MongoDB/文件IO等)
  2. 关键判断逻辑需要详细记录判定的依据, 次关键判断记录判定结果, 不关键的可以不加