巧妇难为无米之炊。对接口日志的分析管理要想管好、好管、挖掘价值，源于日志“写”的好，具体的说在于记录日志时尽量将需要分析的内容结构化保存，不要少，不要藏在文本当中。

将 http 协议的可能用于分析的组件进行结构化存储。

接口命名

1. 代码的方法名
2. 沟通的中文接口名
3. 系统命名的唯一编码

traceId 的概念，用于 trace 追踪。从产生的那一刻起，同一个对象，应该一直沿用这个 traceId，贯穿其生命历程。

单据号

请求方

1. 身份标识 应该采取一些统一的实践方式
   1. 专门做接口路由的系统，会使用 sourceApp targetApp customerId 的概念，管理请求方，放在请求参数里
   2. 需要加签的，也会使用 appKey 表明请求方唯一身份
   3. 在 请求体里添加表达请求者身份的字段，诸如 sourceSys appId 一类
2. IP 地址

响应方

1. 身份标识
2. IP 地址

请求地址

为了保证查到方法、调用地址是否错误

统一的成功失败定义

耗时

请求

返回

http 协议的其他部分：header request parameter 要不要记录

外部系统调用

1. 必须记录日志

内部系统间调用

1. 调用者 From 一方负责记录日志，不要重复记录。原因是对于没有使用 appKey 或请求中有类似 sourceSys 字段表面调用者身份的，只有调用者记录可以明确调用者。而且会有调用地址，便于排查是否调用地址错误这类原因。

最后：草台班子很难守规矩。

我所说的一切都只是我的观点。
我的观点都可能是错的。

访问量统计：0