复旦大学：集中式日志系统让数据挖掘更深入

文/陈灿华 宓詠

集中式日志系统的各个层次，既相互关联，又彼此独立，从底层的原始数据层，一直向上堆叠到任何一层，构成应用水平逐层提高、数据挖掘程度逐层深入，但又自身完备的服务系统。

网络设备、信息系统在运行过程中，往往会在本地存储上写入大量日志。这些日志中蕴含着反映系统运行状态的信息，有些信息可能关系到系统安全与稳定，乃至用户数据的隐私与保密，非常重要。

对于一定规模以上的数据中心，有太多设备系统的日志需要长期保存，也会有多个用户以不同方式利用这些日志数据。为了适应这种多日志源、多用户、用途的应用场景，有必要建立一种集中式的日志存储、管理、分析系统，相对于分散的日志系统，它有几个优势：第一，可以避免本地磁盘损坏造成的日志丢失。第二，可以延长日志滚动保存周期。第三，可以保障数据的安全可靠。第四，可以以可控的方式为不同用户提供数据服务。第五，可以提供统一的日志分析工具。

大规模日志源可能要求日志系统具有良好的分布式部署和计算的特点。多用户的场景则要求系统能有一定的用户权限管理功能，以及为不同操作系统平台的用户提供方便的读写服务。多用途的利用方式则要求系统对每一层次的数据，从原始的日志数据，到解析过的中间数据，到统计分析过的数据，乃至最后的报警数据，都具有一定的规范，都可通过固定的输出，如标准输出、管道、或网络服务，而开放出去。

本文接下来将分析日志的一般特点，以及大规模、多用户和多用途的场景对集中式日志系统的设计所提出的要求，提出集中式日志系统的一种层级框架设计，并详细说明各部分的技术要点。

集中式日志系统的层级框架

基于上述对日志的一般特点，以及大规模、多用户、多用途的场景的特点的分析，我们将设计一种集中式日志系统，为各类分散的网络设备、信息系统提供日志存储、查询、分析、统计以及告警的系统，它相当于数据中心的日志仓库。按照对数据处理加工的深入程度，集中式日志系统的架构可分为四个层次，如图1所示。最底层可称作原始数据层，对日志的原始数据进行分类、压缩、存储、备份，对第三方系统开放只读接口，例如通过本地文件系统，或者NFS、SAMBA等网络协议。第二层可称作解析层，对日志的原始数据根据日志的格式规范作语法以及初级语义解析，对单词作索引，视情况将解析结果插入数据库。第三层可称作计算层，是在解析的基础上，作统计计算，以得到所关心的信息，如系统安全、用户行为等。第四层可称作事件层，根据计算结果，判断是否发生某类事件，例如故障预兆或非法入侵。整个系统可提供网络接口与用户界面，以贯穿四个层次，提供各层的输入输出、查询及管理功能。以下详述各层。

图1 框架层级

图2 原始数据层

原始数据层

原始数据层如图2所示。含一台主机（或多台组成冗余与负载均衡结构），上面运行日志记录守护程序（syslog daemon），开放网络监听端口以接受远端日志。其他设备系统将日志通过syslog协议（或者藉由插件先转换为系统日志格式）发送到日志主机。日志主机根据日志来源主机、日志级别、产生时间等进行分类归档。日志主机的磁盘采用RAID阵列，同时定时将日志数据以增量的方式备份到特别的备份主机。日志主机将日志目录通过NFS或者SAMBA等网络文件系统的方式，对外提供日志读取服务。以此方式，集中式日志系统可以在原始数据层，构成基本而完整的日志存储、归档、备份、查询的系统。由于日志数据的高度敏感性，必须利用操作系统以及网络文件系统的的目录用户权限对数据的访问进行严格控制。

对于实际实施，建议日志主机采用Debian GNU/Linux操作系统，日志守护程序采用rsyslog，网络监听端口开放在默认的UDP 514。业界另一个比较流行的日志守护程序是syslog-ng。二者相比，rsyslog具有syslog-ng的灵活性和模块化优点，同时更为轻量、高效，配置文件语法与类UNIX系统的传统syslogd兼容，是syslogd直接替代品，是最新版Debian系统的默认日志守护程序。

收到远端日志后，rsyslogd可利用其来源主机、级别、时间，甚至对内容作正则表达式匹配，进行分类、存储、过滤、内容改写，乃至触发调用脚本等丰富多样的处理，详情参见rsyslogd的官方文档。

另外应注意设计适当的用户权限方案，将不同来源的日志数据的所有者和使用权限赋予不同用户。一个可行的方案是，对每一来源主机创建独立用户作为其日志数据的所有者，或者将所有来源主机分成几类，分别创建独立用户。另一个方案是，所有日志采用同一所有者，用户权限控制放在对外服务的网络文件系统上。

日志数据的增量备份可采用功能强大的Rsync程序，备份传输过程可采用压缩及加密方式。

原始数据层可对外提供读取服务，例如可对类UNIX系统提供NFS服务，对Windows用户提供SAMBA。二者都可在用户操作系统上映射为网络磁盘，方便操作。另外，对于Linux用户，还建议采用sshfs。sshfs可通过ssh将远端文件系统映射到本地目录，免除NFS的繁琐配置。对于需要抗网断的可靠连接，则可考虑文件系统的多路径方案（Multipath I/O）。

此层是集中式日志系统的数据基础，同时也足以独立提供基本而完备的日志服务系统。如果条件不成熟，可忽略之上的解析层、计算层及事件层，而仅在这一层上运行。

解析层

解析层如图3所示。在原始数据层的基础上，可以进一步根据日志的不同类型，采用不同的日志解析器对日志进行语法和初级语义解析。例如系统日志的格式，一般包括时间戳、源主机名、产生日志的程序名、日志正文。这是所有遵照系统日志格式的设备系统的日志的固定格式。因此可以首先根据这一格式将这些固定信息提取出来。日志正文一般也有格式可循，但是不同程序会定义自己的一套格式，因此与程序强相关。对于流行的软件程序，例如sshd、apache、mysql等，其日志格式是共知的，因此也可以直接作语义分析。经过分析提取之后，日志数据被切成若干语义段，插入数据库中。由于日志条目内容不一，没有固定的字段，即便是同一程序产生的日志也并非每条日志都具有完全一样的格式，因此不太适合插入关系型数据库，我们建议采用文档型的非关系型数据库，比如时下流行的Mongodb。

图3 解析层

在日志解析器编写方面，应注意到日志格式的特点是不同日志格式之间既有不同，也有相同之处，同一程序产生的不同日志格式之间甚至有继承关系。因此，为了高效灵活解析各类日志，编写各类解析器之时应注意模块化与对象化设计。可以针对一些流行软件的日志格式，相应开发解析器。正则表达式是处理文本的通用性与灵活性极高的工具，建议系统开发者编写一款通用的“解析母器”，以正则表达式为其格式语法描述语言，一般的系统管理员只需用正则表达式描述特定日志格式的字段，即可产生针对该特定日志格式的解析器。另外如果对函数式编程范式熟悉的人，可以利用所谓解析器组合子（Parser Combinator）作为日志格式描述语言。与正则表达式相比，解析器组合子表达更清晰简洁，更容易模块化设计。这类解析器以Haskell语言的Parsec最为著名，其他语言也有类似的函数库，如Python的funcparserlib、Java的Jparsec等等，可根据熟悉何种编程语言选择。

日志经过解析器解析之后，插入数据库，然后再以全文索引工具对正文作索引，以便快速查询。日志格式由于没有固定字段，因此数据库建议采用诸如Mongodb的文档型数据库，其数据表没有固定字段的限制，且具有极佳的线性扩展性，尤其适合海量数据的分布式存储。索引工具方面，Sphinx搜索引擎具有非常高效的索引效率，在单台一般个人电脑上也可支持高达十亿条级别的海量数据。

解析层的数据输入可以来自本地硬盘，也可来自远端系统，例如先通过NFS、SAMBA或者Sshfs挂载到本地文件系统，再如同本地磁盘一般作解析处理。而处理后的数据插入数据库后，数据库也可直接开放网络读取服务，或者直接将处理后的数据插入远端的数据库。换言之，此层的解析处理与数据的来源和去向是弱相关的，这为后面提到的分布式扩展，或其他灵活部署奠定了基础。

集中式日志系统到这一层，也构成完备的服务系统，此层如果对外开放服务，可对外提供格式化的具有语义的日志数据，第三方在此基础上可发展各类丰富的应用。

计算层

计算层如图4所示。在经过解析后的格式化日志数据，乃至原始数据的基础上，进行分析统计计算，可以提取蕴含在海量数据中的信息。例如首先按日志来源主机、日志级别、产生时间、产生程序等进行分类统计，则可以对数据中心的整体运行状态与规模有个大概反映。再如，可分拣出错误（error）级别以上的日志，以辨知系统潜在的故障。再如，对登录程序，如sshd的日志，分拣统计失败尝试，可了解系统账户安全威胁。

如统计网站服务器，如apache的日志，可算出网站访问量、页面热度、访问的空间时间分布，乃至可以分离跟踪单用户访问轨迹，从而计算出用户使用习惯等深度信息。对网站日志的实时分析还可预见洪水攻击，以便及时防范。

在网络设备日志方面，除了计算流量及网络压力评估外，可深入分析计算海量的数据包头，从而挖掘出较有意义的信息。例如，对于多出口的高校，通过分析统计用户访问的数量和质量，可以适时调整多出口路由策略，以便均衡负载分布，以及针对不同目标域选用相应的高速出口，提高现有出口带宽的利用率及用户体验。再者，结合图论及复杂网络等理论进行分析计算，可以检验校园网络拓扑的合理度，发现薄弱节点，为校园网升级改造提高数据参考。

在计算工具方面，一般的编程语言及其函数库都能胜任，甚至很多语言都有方便的统计分析函数库，乃至图论、复杂网络函数库。由于集中式日志系统的层级结构设计，各层之间比较独立，因此可以针对不同计算需求，在不同语言中选择成熟的函数库，而灵活组合。事实上，采用不同函数库，甚至不同语言是可能的，也是需要的，因为日志的特点是不同系统的日志可能只有其系统管理员才熟悉与理解，才能决定如何对日志数据作分析统计计算，以提取何种信息。

与解析层相似，计算层的数据输入与结果输出都可往来于网络上。也因此计算层可单独部署于独立服务器上，以构成海量数据分析的分布式架构的节点。

到计算层这一层，集中式日志系统也构成完备的系统。此层可将计算结果以网络服务方式开放给第三方应用。

图4 计算层

事件层

事件层如图5所示。在计算层对日志作统计分析计算之后，可将计算结果送入单个或多个所谓事件触发器。事件触发器与预先设定的触发条件比对，决定日志的计算结果是否触发某事件。一旦触发，如果设置了告警器，则告警器将发出相应告警。此过程构成集中式日志系统的事件层。

事件触发器可分为两类。一类可称作基本触发器，以单个计算结果为输入参数，判别其是否需要触发事件。另一类可称作复合触发器，以多个计算结果，或者其他事件为输入参数，综合判别是否触发事件。前者如网络设备日志中出现端口下线条目，即触发故障事件。后者如多个网段的网络设备中断，触发大面积网络故障的高级别事件。

与其他层一样，事件层的输入，即计算层计算结果数据，可来自本机器的文件、数据库或者管道，也可来自其他计算层服务器提供的网络服务。事件层可将其输出，即事件数据，对外提供网络接口服务，例如可提供给硬件报警器，作为事件来源；或者与运维服务系统关联，提醒运维值班人员；或者生成工单。

集中式日志系统的各个层次，既相互关联，又彼此独立，从底层的原始数据层，一直往上堆叠到任何一层，都可构成应用水平逐层提高、数据挖掘程度逐层深入，但又自身完备的服务系统。而用户界面与服务接口贯穿始终。用户界面可提供各层的查询、管理。系统各层通过开放服务接口，高级系统管理员或者第三方应用可将此日志系统看作一个提供存储、解析、统计、警报的日志平台，各类应用可由此衍生出来。

图5 事件层

分布式拓展

大规模的日志数据将对日志服务器产生巨大压力，对此可以考虑分布式架构部署。如上所述，各层都可通过网络接受下一层的数据输入，也可通过网络对外输出处理数据，因此各层都可独立部署在各自服务器上，共同组成分布式系统。此外由于日志来自不同来源主机，数据之间具有独立性，因此通过简单的分离与合并方式，可部署多台原始数据层服务器，不同来源主机的日志发送到不同服务器上，然后按分类把日志原始数据导入不同的上层服务器上作解析、计算与事件判别触发。之所以可以如此设计的关键是各层的数据输入输出是透明的，即完全无视数据是来自网络还是来自本地数据库或文件系统，而输出也是无视发往本地数据库或远端数据库。由于不同来源主机的日志数据之间的弱相关性，此一分布式架构具有大致的线性拓展的优点，利于随数据中心规模的扩大而增置服务器。

本文讨论了集中式日志系统的意义，以及针对大规模、多用户和多用途的场景提出一种层级框架设计，分析各部分技术实现要点。该框架划分成若干相对独立又自成体系的层次，以适应多用户的不同利用方式和水平。同时，各层次的独立性也为大规模数据的场景提供良好的分布式拓展空间。