2同行回答
做过某农信项目，说下在没上日志分析项目时候感受：
1. 机器数量太多，查问题需要登录每一个主机去grep/awk
2. 因为是各外包团队开发，所以日志格式比较混乱，无法快速获取需要内容
3. 告警困难，还是因为格式规范化问题导致多数情景下不能使用常规手段去创建告警
4. 模块很多，查问题比较散
5. 串联分析不可能，因为日志根本不集中
目前的日志分析产品常见的有开源的ELK，国外的splunk，国内日志易、log insight、蓝鲸也有日志分析模块。建议选择成熟的产品厂商来做。因为银行不太适合ELK。因为 数据量大、日志繁杂，运维也需要专门的人来搞，使用上也需要一定的时间。
收起随着银行业务的发展，在人行、银监的监管要求下，各银行经过多年来对信息化的安全建设不断加大投入和完善建设。系统的安全防护设备也日益增多，各类安全设备每天产生大量的告警日志成千上万条。所存储的日志量每天可以按10G为单位计算。庞大的运维告警日志，难以有效的进行管理和分析。银行业务庞杂、生产系统涉及设备品牌众多，各类应用系统、中间件、数据库每天产生大量日志。运维人员在日常维护中每天分析海量日志，需要通过查看各类应用日志、主机日志、数据库日志等，去判断应用、主机等运行状态，去发现隐藏风险，去了解周期性能状态。传统方式，我们管理成百上千台服务器。需要一次登录每台服务器来查阅日志。但是这样操作非常繁琐、耗时、耗力，效率低下且无法做关联分析，对于当前的安全运营管理人员和团队来说已经呈现出疲劳态势。
现在银行运维工作存在以下问题：
1、运维工作繁杂：运维人员每天都要处理各类众多的应用系统、中间件、数据库每天产生的大量日志。无法做到对系统运行的各种指标实时进行监控，及时发现各种异常并根据各个系统不同特点满足各种个性化的需求。
2、运维效率很低：运维人员面对海量的日志采用人工分析的方式去判断应用、主机等运行状态，去发现隐藏风险，去了解周期性能状态这些工作效率很低。
3、日志在运维工作中的价值无法发挥出来，运维人员无法对各种数据进行长期有效存储用于后期的容量、性能、对比等分析，无法对各类指标进行多维度分析展现（例如以图、表的形式展现），无法实现对日志文本数据进行全文精确搜索和相似搜索，无法实现高效、可视化运维。
对于银行不同的计算机系统不断产生大量的指标数据，对于这些数据需要及时收集，实时分析，发现异常，为运维部门高效运维提供帮助。同时由于数据种类繁多、用于统计的维度也非常多样，这要求使用的统计工具要非常灵活，学习门槛要低，实施周期要短。
ELK stack（Elasticsearch（存储和搜索）、Logstash（收集）、Kibana（展示））为我们提供了这样一种选择，使每个人都能够容易掌握，使需要专业技能才能开发的监控、运维系统不再遥不可及。大家都可以参与到运维监控系统的建设中，更好地监控、运维相关系统，真正实现高效、可视化运维。ELK stack实现银行运维日志管理与日志分析的优势：
1、检索性能高效，实时快速，可以对银行的业务系统运行的各种指标实时进行监控，及时发现各种异常并根据各个系统不同特点满足各种个性化的需求，虽然每次查询都是实时计算，但是优秀的设计和实现基本可以达到全天数据查询的秒级响应。
2、扩展能力强，不管是Elasticsearch 集群还是Logstash 集群都是可以线性扩展，支持TB级以上的海量日志数据的管理和分析。
3、处理方式灵活，多种接口Elasticsearch是实时全文索引，不需要像storm那样预先编程才能使用；
4、配置简易上手，Elastisearch全部采用JSON接口，Logstash是RubyDSL设计，都是目前业界最通用的配置语法设计。
