背景

各个服务的日志输出没有统一的格式，导致日志采集及后续的分析无法统一流程，需要进行定制，浪费人力。因此，在此对各个业务当前的日志输出进行整理汇总，并征集各方意见，以期得到一个满足大多数业务场景的日志输出格式，方便后续的归一化处理，包括日志检索、打标、链路追踪等等，为整个企业邮的长期演进打下基础。

  • 日志力求简洁明了，只输出必要的信息，key的名称尽量用缩写，控制字符长度，减少总体日志的体积。
  • 一般操作日志后面均增加time=xxx，用于表示该次操作耗时，单位是ms，便于后续追踪排查问题。

tomcat/springboot访问日志

%h %l %u %t “%r” %s %b “%{X-Forwarded-For}i” %D %{P_INFO}c

netty等RPC访问日志

TODO

业务日志

以logback为主：%d{yyyy-MM-dd HH:mm:ss} [%t] [%p] tid=%X{traceid},%m%n
文件名为stdout.log.yyyy-MM-dd
后续其他日志组件可参考配置。 注：

  • 1，如果业务自身输出tid就不用在logback里面配置了。
  • 2，用于采集分析的数据，统一格式：k1=v1,k2=v2…
  • 3，不做分析的日志内容，可以不使用k=v格式，直接输出描述内容；（此时无法创建需要的索引，直接存储数据）

TID生成策略

格式

参考严选：agenId^agentTime^subLong
其中：

  • 1）agentId取值可为：servicename， ip，hostname （servicename相对冲突概率高，区分度高）
  • 2）agentTime（Long，毫秒值）取值可为：进程启动时间，请求到达时间，当前时间（进程启动时间相对冲突概率高，CPU损耗小）
  • 3）subLong（Long）取值可为：随机值，一定返回内递增数（随机数计算耗cpu，递增则需要保持原子性） 实际思路与雪花算法类似。

建议一：

servicename^请求达到时间^随机数
该场景，相同服务内部可能存在重复

建议二：

ip^请求达到时间^递增数
在高并发场景下，可以保证唯一

生成时机

  • 内部请求
    由请求发起方生成该id，并负责向下游传递。
  • 外部请求
    阶段一：由对外提供服务的模块进行id生成；
    阶段二：由网关进行id的生成；
    阶段三：由客户端进行id的生成；

传输方式

服务内部

日志输出基于mdc，传递可基于Threadlocal，跨线程需要额外引入其他组件支持；

服务之间

基于HTTP的请求：
需要参考API接口规范进行传递：通过header传递，key为NTES-TRACEID。
RPC请求： //TODO