全面的Splunk应用日志分析介绍

Splunk 是一款顶级的日志分析软件，如果你经常用 grep、awk、sed、sort、uniq、tail、head 来分析日志，那么你需要 Splunk。能处理常规的日志格式，比如 apache、squid、系统日志、mail.log 这些。对所有日志先进行 index，然后可以交叉查询，支持复杂的查询语句。然后通过直观的方式表现出来。日志可以通过文件方式传倒 Splunk 服务器，也可以通过网络实时传输过去。或者是分布式的日志收集。总之支持多种日志收集方法。

应用程序日志是系统运维人员以及开发人员特别关注的，应用日志可以全面记录应用程序的执行过程、状态以及结果，这些信息是帮助运维人员解决故障，开发人员改进程序的最有效信息。但是传统的日志管理工具往往对日志的格式有要求，很难快速适应非统一、规范的日志形式。而splunk超乎想象，除了可以处理交换机、防火墙、路由器以及操作系统的日志之外，应用程序日志处理起来也得心应手！

通常情况下，应用程序的日志信息存储在指定的目录下，采用任何文件共享的方式，比如挂载的或者网络共享的目录，只要Splunk服务器能够读取，它就能够远程采集这些日志信息。任何活动的应用程序，不管是J2EE、.Net应用程序、Web访问日志等等，只要有新的日志产生，Splunk会对其进行持续的索引。

也有朋友会担心，说如果我的应用程序产生的一个日志文件非常大，时间跨度很长，比如说一天才能产生一个日志文件，那么Splunk岂不是失去了实时性？其实不然，Splunk在监控大多数文件系统时，是即时读取日志信息的，只要检测到被监控目录有变更，Splunk就会读取新增加的数据信息，即使是日志文件正在被写入的时候，所以仍然能够保证实时性。

应用程序日志不同于一些专用设备的日志信息，比如网络设备的日志信息都有相对简短、固定和统一的格式，而应用程序则复杂的多。首先一条应用程序日志信息包含的信息量远远超出其他专用设备日志，往往有十几行，几十行，甚至几百行都很常见。其次，其格式并不是完全固定不变的，整体上结构统一，但是根据信息的类别可能有不同的字段。

所以对于应用程序日志进行监控时，Splunk提供了多条件的日志事件分割方法，以适应这种复杂结构。如果你在默认设置下监控应用程序日志时发现，Splunk把一个独立事件分割成了多个，或者把多行的日志事件按照每行一个事件给分割开了，此时不要担心，Splunk不可能自适应所有的应用程序日志格式，何况还有那么多自行定义的日志格式。

Splunk专门提供了一组参数对日志事件的分割进行控制。比如“SHOULD_LINEMERGE =”，这个参数选择“true”，则Splunk会把指定Source Type的日志事件按照多行事件来识别，也就是把多行信息识别成一个独立事件。同时配合这个参数的还有分割点的控制参数，比如“BREAK_ONLY_BEFORE_DATE =”，设置该参数把日志中发现的每个日期作为一个独立事件的分割点，我们知道每条日志事件一般都带有一个日期时间点。或者用“BREAK_ONLY_BEFORE = ”自己设置分割点的特征，特别是对于自有定义的日志格式，往往在分割时有明显的特征，这是个不错的方法。

应用程序日志事件的识别已经解决了，你可能还遇到这样的情况，你想要的字段Splunk没有自动识别出来。当然，应用程序日志格式千奇百怪，无论如何Splunk也无法保证自动完成一切。但没有关系，为此Splunk专门设计了一个字段提取功能，使用起来十分方便。在多条日志事件里面选择同一个字段的数值或者字符串，作为样本输入，Splunk会自动分析这些样本的特征，建立正则表达式界定这个字段在日志事件里的位置，并提供给你预览，确认后即可定义一个新的字段。

以上是几点在做应用程序日志监控时常常需要做的一些调试技巧，掌握这些基本就能够开始构建你自己的应用程序日志监控平台了。当然Splunk所提供的远不止这些，建立实时的应用程序关键信息统计Dashboard，建立事件查询界面，设置告警等等，一系列功能能够帮助你组建完善的管理系统，而Splunk自身的灵活性则能够快速适应新管理需求的增加和改进。

Splunk作为一款成熟的商业化日志处理分析产品无论在功能上还是用户体验上都是令人满意的，而开源方案ELK(Elasticsearch+Logstash+Kibana)相信也有很多朋友考虑或者正在使用，我在这里不想讨论孰优孰劣因为不同的业务场景出发点不同，共存也是不错的选择。