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

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

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

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

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

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