金融计算机求log,金融行业日志规范汇总

摘录改写自《客商银行日志规范》 原作者本人：林万程

《个人金融信息保护技术规范》JR/T 0171—2020

个人金融信息解释详见原文

应对个人金融信息访问与个人金融信息的增删改查等操作进行记录，

并保证操作日志的完整性、可用性及可追溯性，

操作日志包括但不限于业务操作日志、系统日志等；

系统运维管理类日志不应记录个人金融信息。

应对存储个人金融信息的数据库及操作日志实施严格的用户授权与访问控制。

日志文件和匹配规则的数据应至少保存 6 个月，

应定期对所有系统组件日志进行审计，包括但不限于存储、处理或传输个人金融信息的系统组件日志、

执行安全功能的系统组件日志(如防火墙、入侵检测系统、验证服务器等)、安全事件日志等。

《商业银行应用程序接口安全管理规范》JRIT 0185-2020

安全监控(7.3.3)

商业银行应对接口使用情况进行监控，完整记录接口访问日志。

日志应满足以下要求：

商业银行相关日志应至少包括交易流水号、应用唯一标识、接口唯一标识、调用耗时、时间戳、返回结果(成功或失败)等；

因清分清算、差错对账等业务需要，应用方接口日志应以部分屏蔽的方式记录支付账号(或其他等效信息)，

除此之外的个人金融信息不应在应用接口行接口日志中进行记录.

应用方安全能力(9.3.4 告知外部对接平台)

应留存与商业银行应用程序接口集成相关的应用系统、网络设备、主机投备、安全产品日志，

日志保留期应满足国家与行业主管部门要求，日志留存应不少于 6 个月。

商业银行交易日志应按照国家会计准则要求予以保存，系统日志保存期限不少于 1 年．

安全审计(12.3)

商业银行应具备以下安全审计能力：

完整记录商业银行应用程序接口访日志，日志记录应至少包 7.3.3 所述口志内容。

依据商业服务需求和风险控制要求，遵循最少够用原则适当保留应用方上送报文(全部或部分信息)。

应对日志记求进行完整性保护确保护，确保日志不被篡改、删除、覆改。

应用方应具备以下安全审计能力：(告知外部对接平台)

应完整记录商业银行应用程序接口访问日志，日志记录应符合 7.3.3 所述日志要求。

应对日志记录进行完整性保护，确保日志不被篡改、删除、覆改。

应提供查询应用方用户商业银行应用程序接口相关登录、授权、交易等历史操作日志功能。

《阿里规范》

【强制】应用中不可直接使用日志系统(Log4j、Logback、Log4j2)中的 API，

而应依赖使用日志框架(SLF4J)中的 API，

使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

public class Test {

private static final Logger LOG = LoggerFactory.getLogger(Test.class);

}

这里把阿里提到的JCL去掉是因为 SLF4J 避免了困扰 JCL 的类加载器问题，在设计上简单得多，而且更加可靠。

日志实现使用 logback 或 log4j2，比 log4j 性能好。

不要自行封装日志操作，在每个类getLogger可以在配置文件中灵活屏蔽。

使用大写的 LOG，因为在 PMD 扫描中小写可能被禁止，LOGGER 显得太长。

【强制】所有日志文件至少保存 15 天，因为有些异常具备以“周”为频次发生的特点。

对于当天日志，以“应用名.log”来保存，保存在/opt/logs/应用名/目录下，

过往日志格式为:

{logName}.%d{yyyy-MM-dd}.%i.log.gz

统一以文件类型拓展名 log 结尾，便于系统识别文件类型。

原文的/home/admin/应用名/logs/显得突兀，

参考之前在工商银行的风格，结合我行习惯，

用/opt/logs/应用名目录

(工商银行是 Docker 部署，放home而不是opt)

使用压缩，因为日志压缩比例非常高，可以极大地减少磁盘空间压力，下载也更快

【强制】根据国家法律，网络运行状态、网络安全事件、个人敏感信息操作等相关记录，留存

的日志不少于六个月，并且进行网络多机备份。

【强制】应用中的扩展日志(如打点、临时监控、访问日志等)命名方式：

appName_logType_logName.log。logType:日志类型，如 stats/monitor/access 等；logName:日志描

述。这种命名的好处：通过文件名就可知道日志文件属于什么应用，什么类型，什么目的，也有利于归类查

找。

WARN 和 ERROR 的选择需要好好考虑

WARN 一般我倾向于记录可自恢复但值得关注的错误，

ERROR 代表了不能自己恢复的错误。

对于业务处理遇到问题用 ERROR 不合理，对于 catch 到了异常也不是全用 ERROR。

日志最好打印一定的上下文(链路 TraceId、用户 Id、订单 Id、外部传来的关键数据)而不仅仅是打印线程栈。

记录上下文信息需考虑日志脱敏问题？可以在框架层面实现，比如自定义实现 logback 的 ClassicConverter。

正确合理的使用日志，能够指引开发人员快速查找错误、定位问题。

《阿里工程师的自我修养》如何成为优秀的技术主管？你要做到这三点

—— 作者：云狄　高级技术专家