浅谈日志的采集与分析

发表于

大规模信息系统中，日志的处理其实是一个非常基础又重要的部分。对于日志Log文件的采集，一般都是分布式的集群：一方面单一的采集节点会造成流量的拥堵，另一方面，大量日志的处理与存放对于单节点来说压力巨大，这也是分布式系统常需考虑的方面。 采集的另一个重点是增量模式，对于实时系统来说，需要进行类似于流处理(Stream)的增量实时采集(类似于Flume工具的一种实现模式)；当然，采集并不是目的，只是为分析打基础的第一步——采集后实时处理，以及处理之后的实时分析参考运用才是重点。 日志文件通常是非结构化的文本，常见的一般是JSON，XML等等。很明显，非结构化的文件中包含了可以结构化出来的信息(总之就是解析啦)，因此，对于日志的存储有几种方案：

  • 使用mongoDB数据库进行存储
  • 使用Hadoop+Hive+HBase进行存储

2种方案差异不是很大，当然还有很多类似的NoSQL数据库，这里暂时不表。 对于mongoDB来说：

  • 很大程度的保留了SQL的一些友好的特性(查询，特性)
  • Master/Slave复制机制(支持自动错误恢复吗，使用sets copy)
  • 内建的分片机制
  • 支持Javascript表达式查询
  • 性能相对更好(关注性能多于功能)
  • 总体上讲，适用于有性能需求的场合，希望使用MySQL或者PostgreSQL但本身预定义分隔符无法满足要求的场合

而对于HBase来说：

  • 支持数十亿行×上百万列(很诱人)
  • 脱胎于Hadoop项目，采用分布式架构MapReduce
  • 对实时查询进行优化
  • 对配置改变和小升级都会重新回滚
  • 没有单点故障
  • 良好的随机访问性能(堪比MySQL)
  • 总体上说，适用于BigTable和需要对大数据进行随机、实时访问的场合

言归正传，存储选好之后，接下来就是对日志文件进行实时的解析与入库。 这里的难点是：需要开发对于不同格式的日志的解析规则的适配器，这里也有2种方案：

  • 对所有终端报回的日志做统一的规范，在解析端只需要简单的解析重要与次要，分开即可，在实时的情况下节约时间与流量成本，这样方便分析，也更加统一。
  • 使用正则表达式在存储之前对日志进行清洗处理，这样稍被动，但处理之后的Log更加有利于查询，容易提升未来查询的速度。

这里我们采用了第一种方案，同时汲取方案2的有点，尝试一次性解决日志的解析存储问题。通过灵活的解析配置，动态的支持所有类型的日志文件(当然是合乎统一规范的)，同时还可以自定义相关的解析规则以满足临时查询和其他情况的需要。

对于任何日志文件，这里简单的举例，基本都可以采集发生的时间，日志类型，关键词，异常信息，状态信息和标志等等。假如在mongoDB中存储可以实现本身在数据存储层面的灵活水平扩展。

在对采集的日志进行处理并持久化存储入库后，接下来的工作就相当简单，即需要开发相应的日志查询和分析功能，可以根据时间段，日志类型，可以根据具体的异常编码，异常关键字内容等对日志信息进行快速的查询和定位。进一步的，可以根据系统的具体需求建立上层的数据报表平台，进行自动化的实时分析。

在ITIL里面我们经常看到一个功能即问题树和知识库，那么基于日志的分析和处理仍然可以采用该模式，对于关键的日志异常信息的处理，我们可以将实际的处理方法和结果信息直接登记入库，同时关键日常和处理方法建立对应的关联关系，那么这就不仅仅是一个日志采集分析功能，而是一个基于日志快速的解决问题的知识库。

要将该思路实现为一个产品，涉及到诸多的分布式，云计算相关技术的应用。这个选点可能比较小，但是却有实际支撑的业务场景，能够发挥我们说的在大规模分布式集群架构下的实时流处理，实时分析，半结构化数据库的使用等。任何云技术的使用都应该根据目标驱动的方式去思考问题，而不是为了技术而技术——驱动技术的，永远是商业需求；不懂商业，技术永远只是技术；不懂包装，数据就永远只是数据。