银行科技部门为何要建设日志分析系统？

我们行最近也建设了实时的日志分析系统，在这把我们当时的想法分享给大家。

我行现有几十套应用系统在线运行，这些系统分布在Windows、AIX、Linux等多种操作系统上，大多数业务系统的日志都落到服务器本地，对日志的敏感信息的保护，日志访问权限的控制，日志生命周期的管理以及日志对于业务系统监控分析等方面存在严重缺失。与应用系统相关的中间件日志，操作系统日志，硬件日志等也没有有效收集利用。针对日志分析这块我行采用登录到每台机器上，使用grep/sed/awk等Linux／Unix脚本工具去日志里查找故障原因，这种方式排障时间长，故障根源发现困难，而且没有关联分析的能力。随着后续我行新项目不断上线，业务系统持续增加以及分布式系统的技术架构持续发展，现行通过逐台登陆服务器的操作模式存在的问题和潜在的风险与日俱增，主要体现在如下方面：
1） 操作人员逐台登陆服务器查看日志定位故障时效率差，我行在登录服务器时需要审批，影响故障定位实效性和准确性。
2） 我行整体业务系统众多，复杂度高，承载量大，业务日志日增量较大，且部分应用系统开发和运维脱离，已经不适合再使用传统模式查看及分析日志。
3） 随着业务量的增加，给执行、监控和管理均带来极大的挑战，操作人员误操作的次数随系统增加而增加。
4） 缺乏查询和报表展现，难以支持审计、统计分析、业务性能调优等更高管理需求。
5） 从外部或者业务发展角度出发，银行业务发展越来越关注业务可用性和业务连续性，对IT的要求越来越高；从IT管理内部发展角度出发，基础的运行告警已经不能满足目前越来越复杂的业务场景。传统运维监控系统围绕专业指标进行管理，各种IT组件产生专业事件后，很难通过事件以及产生事件的软硬件本身了解其对业务产生了多大影响，无法知道同一时段内产生的各种专业事件相互之间的关系，无法从大量告警中找到真正有用的告警，更无法将大量的系统运行历史数据利用起来，系统运维成了被动救火式运维，使运维工程师疲于应付。