争议 | 银行信息系统日志分析的两种方案,该选哪一种?

来自twt社区同行交流，欢迎更多同行参与交流

在银行信息系统中，应该如何选择日志分析道路？

推广统一平台，自带日志。

推广统一日志平台，推广服务。

问题来自社区会员@supersdzg 北京银行 项目经理，下文来自twt社区众多同行实践经验分享，欢迎大家参与交流，各抒己见。

* “争议”栏目内容来自同行分享的一手体验和观察，仅代表个人观点

@penghuasheng 广发证券 数字化运维研发团队负责人：

1、问题中，第1点需要企业从SDLC的软件研发阶段即落地标准化日志的输出，第2点重点是引入成熟的日志管理系统，1也需要。

2、虽然日志中有很多业务、客户方面的知识有待挖掘，但当前对日志的分析目前主要是运维侧在做，因问题中看起来只指应用系统日志（系统或硬件日志成熟方案很多），我觉得如果是运维侧做可以考虑如下：

1）定义企业的日志分析方向是什么：满足监管要求存储日志数据？根据关键字的监控报警？梳理出日志中的业务数据、客户体验、性能、链路关系等等？以及日志分析是提升业务连续性，还是提升IT系统交付速度，或向业务侧赋能？不同的方向，针对的平台、日志规范、日志运营不同。

2）平台建设：选择商用产品主要基于企业希望花钱减少人力资源投入，现在开源ELK的解决方案也很成熟，ES版本更新很快，且国内代理厂商也多，如果愿意投入人力资源做日志分析，值得选ELK相关方案。如要对日志进行进一步分析，可能需要对非结构化的日志进行二次加工，才能更好的使用。

3）日志规范：日志很乱，如果不只是为了简单的监控，或配置一些可视化信息，那需要推动研发侧优化日志格式与标准，需要针对特定系统进行特定的日志分析，需要加强日志运营。

1）2）3）应该是并行，没有先后，持续推动。

@anonymous 银行系统工程师：

以个人大型股份银行的建立历程与经验来看，比较倾向于第一种方案：

首先让自带日志标准、规范、可读、可控、可关联后，后续的服务才能发挥更大的价值；

这样的缺点是前期投入的成本较高，以明确的目标为导向。

第二种方案优点是短平快，短期收益较快，属于过程导向，如何后续要达成有效的目标会付出更高的成本。

@luxh08 科技部门副总 某互联网银行：

我们的规划路径是，首先要制定统一的日志规范和标准，需要考虑的因素非常多，比如有应用需求、业务需求、监控需求、智能化需求、数据化需求等等；再接着要建立统一的日志平台，在日志平台上实现统一日志检索、业务逻辑告警、问题告警、全链路追踪等功能；之后可以实现一些数字化需求，比如业务监控展示、业务交易分析决策、统一的监控告警；最终的目的是要通过日志实现智能化，比如通过日志信息实现事件的分析，问题的自愈，资源的自动弹性伸缩等高级功能。

@ljosef 某股份制银行 系统架构师：

个人认为日志作为核心的数据能力，应集中存储。而日志平台作为解决问题的技术能力，应在多场景中进行嵌入式开发。

具体思路如下：

（1）涉及到日志存储中分类、索引、生命周期等相关能力具有通用的技术储备，可以考虑结合分布式存储、集群、归档的技术进行统一建设，成立独立的数据团队。

（2）日志采集往往是日志存储的基础，针对日志采集的过程，与日志规范相关，也有场景相关，针对系统、业务、链路等数据应设计各自统一的规范，并在全组织进行推广。

（3）而日志分析与展示的能力各平台差异性较大，可以基于日志存储的能力进行扩展性及个性化开发。

@jason2006xu 昆仑银行 技术经理：

银行信息系统日志分析应该从以下几个方面考虑：

1、制定日志规范和标准，规范应用日志，包括日志文件名、日志格式等，改造存量业务系统日志、新建系统日志必须根据规范执行。

2、搭建企业级日志管理平台，收集网络设备日志、存储设备日志、数据库日志、安全设备（IPS、IDS等）日志、中间件日志、应用日志等。

3、实现目标包括统一日志存储、检索、监控告警、故障定位、审计分析等。

@秋名山车神 日志易 项目经理：

建议推广统一日志平台，推广服务。这样在管理的角度会有统一的收口，后期运维部门可以新系统上线或服务变更时对系统层日志进行统一的纳管，应用层和业务层日志接入需求、统计需求、告警需求及分析场景可通过ITIL工单进行申请，日志平台权限管理对接ldap或IAM进行初始权限分配，后期在日志平台进行微调整，从安全角度和平台使用上会达到一个平衡。

在日志平台使用及维护过程中，第一责任部门为运维，其次是项目所属的业务部门或项目组，最后为运营或辅助决策，因此运维部门可结合企业现状进行日志规范的制定及推广，近几年各互联网的大厂或金融公司都在推动这方面的工作，实际改造过程会比较痛苦，有较多的外部系统及老的平台，改造工作量较大，但是后期效果都会比较好。

有比较好的行业日志改造实践，通过系统开发人员对现有日志进行归纳总结，生成summary日志，这样就大大的减少了开发工作。

@赵海  技术经理：

我觉得银行系统的日志分析这个事情，需要从以下几个方面分步推进：

1. 日志的标准化问题。

应用系统、中间件、数据库、操作系统、设备等都会有自己的日志。每一种日志都会有自己的控制参数，比如日志的级别、日志的格式、日志的标识等等。如果日志的内容、格式、提取标识不能统一，那么就算把所有的日志都能收集起来又又何用呢？

2. 日志分析的模型设计问题。

收集日志无非有这么几个功能：实时报警，趋势分析、防患未然，深度挖掘、主动优化。除了实时报警无需二次设计相关模型，其他两个功能都需要进行二次加工，从日志的时间维度和内容维度去分析可能和潜在的问题和风险，这本身是需要找到日志与日志甚至日志与其他信息的相关性。这需要在实践当中结合具体系统特点不断分析摸索。

3. 日志分析的工具和平台问题。

我们知道，日志量是非常大的，尤其是级别开得越低，日志的量级就越大。那么对于这样大的数据量，我们采用什么样的平台既能处理这样大的数据量，又能将我们的分析模型嵌入到其中，这个是需要仔细斟酌的。

所以，综合考虑，日志报警也好分析也罢，此类问题是需要从这几个方面，有先有后来考虑的。特别加一句，如果第一个问题（标准化的问题）无法逾越，那么不妨考虑二次标准化的建立，也就是说通过 “数据收集 -> 标准化加工” 的方式来形成初步的标准化，然后再跨越到第二步、第三步。

@jackliberty 哈尔滨银行 监控管理岗：

1、推广统一平台，自带日志，这种方式需要研发投入，并且对于有大量采购系统而非自研系统的金融行业来说，对项目管理能力，协调能力等有很高的要求。

2、统一日志平台的方式相对可落地性更高一些，同时也可以兼容不类型的日志，但是针对日志平台的解析开发工作可能会相对多一点，但是毕竟涉及到的部门和项目都比较少，可行性和可推动性高一些。

当然在有统一日志平台的同时，也可以推动各业务系统日志标准化，简化日志平台的解析开发工作复杂度，有利于日志分析的覆盖面和适应性。

到社区阅读和讨论交流，发表您的看法

 资料/文章推荐：

• 100 篇银行 IT 建设实用参考！请收好，一定有你需要的→

https://www.talkwithtrend.com/Topic/2961

下载 twt 社区客户端 APP

或到应用商店搜索“twt”