系统出了异常，第一反应是查日志。打开一看，要么没有，要么只有一行报错，谁在什么时间做了什么全都查不到。这时候只能靠回忆和猜。
日志这事平时不显眼，等到需要用的时候，有没有差别很大。而且它是越早规划越省事的东西，后期补往往补不全。
一、日志至少分三类
第一类是操作日志，记人做了什么。谁在什么时候登录、改了哪条单据、改前是什么值改后是什么值、提交了什么操作。这类日志是排查纠纷和追溯责任的主力。
第二类是运行日志，记系统自己发生了什么。程序报错、接口调用失败、定时任务跑了没有、数据库连接超时。这类日志主要给技术人员看，用来定位故障原因。
第三类是安全日志，记异常的访问行为。某个账号短时间内大量登录失败、某个 IP 在半夜频繁请求接口、有人尝试访问权限范围外的数据。如果系统涉及敏感数据，这类日志不能省。
二、每条日志至少要有的字段
操作日志里，时间要精确到秒，人要有账号和姓名，动作要有类型，对象要能定位到具体是哪条数据，结果要有成功或失败。这五项少一项，日志的可用性就打折。
改动类操作还要记改前的值。只记改成什么，事后无法还原，遇到争议时说不清原来是怎样。存储上可以把改前值截断，比如只留前两百个字符，兼顾体积和可用性。
运行日志里，除了报错信息，最好带上请求标识。同一个请求经过多个模块处理时，靠这个标识能把散落在各处的日志串起来，排查效率差别很大。
三、日志存多久
操作日志建议至少存一年，涉及资金、审批、考核的，建议存三年以上。这不只是运维需求，很多行业的管理规定里对操作记录的保存期限有明确要求，做系统的时候要先去查清楚本行业的期限。
运行日志可以短一些，一到三个月足够。量大的话按天分文件，过期自动清理，别让日志把服务器空间占满。这个清理动作本身也要记日志，否则某天发现日志突然没了，不知道是被清理了还是被删了。
存储方式上，操作日志建议存进数据库，方便按人按时间按单据查询。运行日志存文件就行，没必要进库，量大且查询方式简单。
四、怎么让日志真的有人看
日志最怕的是记了没人看。做法上有两处可以下手。
一个是把日志查询界面做得顺手。管理端要能按操作人、时间范围、操作类型、单据编号组合查询，能导出。查一次要填五个条件翻三页才能看到结果，实际就没人用了。
另一个是异常主动提醒。安全日志里出现连续登录失败、权限外的访问尝试，运行日志里出现同一类报错反复发生，这些应该主动推送给管理员，而不是等人去翻。提醒不等于每次都要处理，但至少让人知道发生过。
还有个细节，日志一旦生成就不该允许普通管理员删除。系统里要区分看日志和删日志这两种权限，删日志的操作本身也要记进安全日志。否则日志的可信度就没有了。
上一篇换系统时旧数据怎么迁移