拉卡拉开放平台

系统正常时，没人会看日志；一旦出问题，日志是唯一能还原现场的材料。因此日志该记什么，应当按「出问题时要靠它回答什么」来设计。

一条有价值的日志包含什么

原始返回必须完整保留

只记录自己解析后的结论，等于丢掉了判断依据。一旦结论本身出错，就没有第二次机会。

原始返回应当原样留存，包括那些当时看起来没用的字段。

结构化还是纯文本

• 结构化：便于检索与统计，适合量大、需分析的场景；
• 纯文本：便于人工阅读，适合关键节点的详细描述；
• 常见做法：主体结构化，异常详情用文本补充。

日志分级

1. 常规信息：记录正常流转，量最大；
2. 警示信息：出现异常但已自动处理；
3. 错误信息：处理失败，需要关注；
4. 关键信息：需要立即介入的严重问题。

分级的作用在于过滤：日常只看错误及以上，排查时再放开到全部。

脱敏要在写入前完成

日志里不应出现完整的敏感信息，这一点必须在写入前处理，而不是指望事后清理。

• 密钥类信息一律不记；
• 身份类信息部分遮蔽；
• 金额类信息可保留，但应与标识分离存储。

事后清理的问题在于：日志一旦散落到多个位置，就再也无法保证清理干净。

日志保留期限

日志不能无限保留，也不能过早删除。期限的设定通常参考三个因素：

常见的做法是分层：近期日志在线可查，历史日志压缩归档，超期部分按策略清理。

日志与监控的分工

• 监控回答「有没有问题」，面向整体；
• 日志回答「哪一笔出了问题」，面向个体；
• 两者通过时间与标识建立联系。

试图用日志替代监控，会淹没在细节里；试图用监控替代日志，则无法定位到具体请求。

写入性能的取舍

日志写入本身也有成本，在高频场景下甚至可能成为瓶颈。

1. 采用缓冲写入，减少直接落盘次数；
2. 关键日志同步写入，常规日志可异步；
3. 确保缓冲中的内容在系统异常时不会大量丢失。

第三条是取舍的关键：一味追求性能而让关键日志丢失，等于在最需要的时候没有证据。

关键节点单独标记

在海量日志里找到关键的那几条，需要在写入时就做好标记。建议在涉及资金动作、状态变更、外部调用的节点，统一加上可检索的标记。

• 资金动作：任何与金额相关的处理；
• 状态变更：状态从一个值变为另一个值；
• 外部调用：发出请求与收到返回两个时刻。

有了这些标记，排查时可以先把范围缩小到关键节点，再逐步展开，效率会高很多。

日志是写给未来的自己看的。今天多记录一项信息，明天就可能少花两小时排查。这个投入产出比，在系统运行一段时间之后会格外明显。

一份设计良好的日志体系，能让排查从猜测变成检索。这两种工作方式之间的效率差距，随着系统复杂度上升会越拉越大。

日志写得好不好，标准很朴素：三个月后有人拿着一个单号来问，能否在十分钟内还原出全过程。能，就是合格的。