













(1)日志记录内容的设计,应方便后续查询、统计以及日志可视化等,因此可能跨页面、跨接口记录同一日志。
(2)由于是用户操作日志,所以只能由前端触发日志记录。
(3)由前端判断日志的同一性,即哪些操作属于同一条日志的应记录内容,哪些操作需要新建一条日志。
例如,若查询获取结果并记录日志之后,将对该查询结果的导出、打印等视为同一条日志的记录内容(记录是否导出、是否打印),则用户未导出、打印,又重新查询,就需要新建一条日志。或多开页面查询相同条件,就记录多条日志。
(4)为减少请求压力,前端可批量上报日志,或在指定时间内无新日志产生时再上报日志。
(5)区分其他类型的日志,例如,用户登录日志,后端错误日志。这类日志不存在跨页面、跨接口,直接记录即可。
(1)日志完整性:包含 “谁 - 何时 - 何地 - 做了什么 - 结果如何” 核心要素。
(2)应方便后续查询、统计以及日志可视化等。
(3)性能优先,避免阻塞;
(4)可扩展性:支持后续新增操作类型、扩展日志字段;
(5)安全性:敏感数据脱敏(如用户 ID、查询参数中的隐私信息),防止日志泄露。
对操作进行分类,并且可扩展操作类型。
(1)日志表的字段:
id,日志编号,生成日志的时间,用户Id,登录ip,日志类型,日志名称,日志内容(存为json)
注:
(2)操作类型表的字段
id,名称,显示名称,描述
注:若系统有扩展需求,可对操作进行分类并单独建表。若扩展需求不大,有相应的字典即可。
(3)操作表的字段:
id,日志Id,操作发生的时间,操作类型的名称,是否成功,操作结果内容(存为json)
注:如有必要,前端依据操作类型,使用对应的界面呈现操作结果内容。
对每次查询结果进行导出跟踪,并只记录一条记录
(1)前端发起查询;
(2)后端查询同时记录日志,并返回结果与日志Id;
(2)前端获取查询结果,并记录返回的日志Id;
(3)前端点击导出按钮,请求后端生成excel文件,请求参数携带日志Id;
(4)后端生成excel文件,并提供文件流,同时根据日志Id以更新日志;
(5)前端下载excel文件。
(1)前端发起查询;
(2)后端查询并返回结果;
(2)前端获取查询结果,并生成日志;
(3)前端点击导出按钮,请求后端生成excel文件;
(4)后端生成excel文件,并提供文件流;
(5)前端下载excel文件,更新日志;
(6)前端上传/批量上传日志,或定时触发上传/批量上传日志。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。