4同行回答
我们行最近也建设了实时的日志分析系统，在这把我们当时的想法分享给大家。
我行现有几十套应用系统在线运行，这些系统分布在Windows、AIX、Linux等多种操作系统上，大多数业务系统的日志都落到服务器本地，对日志的敏感信息的保护，日志访问权限的控制，日志生命周期的管理以及日志对于业务系统监控分析等方面存在严重缺失。与应用系统相关的中间件日志，操作系统日志，硬件日志等也没有有效收集利用。针对日志分析这块我行采用登录到每台机器上，使用grep/sed/awk等Linux／Unix脚本工具去日志里查找故障原因，这种方式排障时间长，故障根源发现困难，而且没有关联分析的能力。随着后续我行新项目不断上线，业务系统持续增加以及分布式系统的技术架构持续发展，现行通过逐台登陆服务器的操作模式存在的问题和潜在的风险与日俱增，主要体现在如下方面：
1） 操作人员逐台登陆服务器查看日志定位故障时效率差，我行在登录服务器时需要审批，影响故障定位实效性和准确性。
2） 我行整体业务系统众多，复杂度高，承载量大，业务日志日增量较大，且部分应用系统开发和运维脱离，已经不适合再使用传统模式查看及分析日志。
3） 随着业务量的增加，给执行、监控和管理均带来极大的挑战，操作人员误操作的次数随系统增加而增加。
4） 缺乏查询和报表展现，难以支持审计、统计分析、业务性能调优等更高管理需求。
5） 从外部或者业务发展角度出发，银行业务发展越来越关注业务可用性和业务连续性，对IT的要求越来越高；从IT管理内部发展角度出发，基础的运行告警已经不能满足目前越来越复杂的业务场景。传统运维监控系统围绕专业指标进行管理，各种IT组件产生专业事件后，很难通过事件以及产生事件的软硬件本身了解其对业务产生了多大影响，无法知道同一时段内产生的各种专业事件相互之间的关系，无法从大量告警中找到真正有用的告警，更无法将大量的系统运行历史数据利用起来，系统运维成了被动救火式运维，使运维工程师疲于应付。
总结：日志的价值被低估了！
1.为什么要建设日志分析系统，还是要从日志的功能来展开，日志的主要功能是...？
答：故障定位。但是这是传统思维了。
2.楼上有朋友提到银行日志或其它行业都有同样的问题、信息孤岛、查询慢、无关联、产生数据泄露、无法进行异常回溯等等。这里的每个问题都会推动日志分析系统建设的脚步。
3.除了上述问题还有什么问题需要解决？
答：日志特点之一是时效性，异常日志如果有效的监控可以大大降低异常发现的时间。银行日志中存在日常交易报文，这部分内容非常详细。非常适合做为用户特征分析或行为分析的基础数据。通过业务特点以及业务流程梳理后可以为运营决策提供非常好的数据支撑。
4.提高运维水平。主要是体现在将从前分布式的日志统一管理后有利于快速的挖掘异常行为。提高运维水平。
5.数据湖或为大数据部门洗数。日志分析平台最重要的一个功能就是可以快速提取日志中的关键要素。并作为数据提供者为数据湖供数。如果仅仅是把日志存起来然后出几张报表也许对5年前还可以，但已经远远不能满足今天的需求。