分布式系统中的日志分析及应用
- 格式：pdf
- 大小：3.49 MB
- 文档页数：18
文档推荐
-
分布式系统的可靠性页数:52
-
分布式系统中容错技术页数:66
-
分布式系统之10容错性页数:35
-
分布式系统中容错技术导论页数:3
-
第7章分布式系统中容错技术页数:77
-
第七章分布式系统中容错技术页数:77
下载文档原格式
合集下载
利用Docker构建容器化的分布式日志收集与分析平台
利用Docker构建容器化的分布式日志收集与分析平台Docker技术的出现，为软件开发和运维提供了便捷和灵活的解决方案。
其中一个广泛应用的领域是容器化的分布式日志收集与分析平台。
本文将介绍如何利用Docker构建这样一个平台，以实现高效可靠的日志处理和分析。
一、背景在分布式系统中，日志收集与分析是非常重要的任务。
通过收集和分析大量的日志数据，我们可以了解系统的运行状况和异常情况，从而进行故障定位和性能优化。
传统的日志收集与分析方式存在一些问题。
首先，各个组件的日志需要单独配置和管理，缺乏统一的平台。
其次，日志数据量大，传统的存储和搜索方式往往效率低下。
另外，随着系统规模的增大，传统的解决方案面临着扩展困难和维护成本高的挑战。
二、Docker的优势Docker是一种轻量级的虚拟化容器技术，具有以下优势：1. 轻量和快速启动：每个容器都是独立运行的，可以在几秒钟内启动和停止。
2. 跨平台：Docker容器可以在各种操作系统上运行，不受限于特定的硬件和操作系统。
3. 可移植性：Docker容器可以在不同的环境中运行，保证了应用程序在不同环境中的一致性。
三、Docker构建容器化的日志收集与分析平台1. 日志收集使用Docker构建容器化的日志收集平台，可以实现统一的日志收集和管理。
可以使用开源的日志收集工具，如Elasticsearch、Logstash和Kibana（即ELK Stack），通过容器化的方式部署和管理这些组件。
2. 容器化的LogstashLogstash是一个用于收集、处理和转发日志的开源工具。
通过使用Docker容器，可以方便地部署和管理多个Logstash实例，以应对高并发和大数据量的日志收集需求。
同时，可以通过配置Logstash的插件和过滤器实现对日志数据的解析和转换。
3. 弹性和扩展性使用Docker容器，可以根据实际负载需求进行弹性和扩展。
根据当前的日志收集负载情况，可以动态增加或减少Logstash容器的数量。
分布式系统中的日志管理与审计策略(五)
分布式系统中的日志管理与审计策略引言：随着信息技术的快速发展，分布式系统已成为现代化企业和组织必不可少的一部分。
然而，分布式系统由于其分散性和复杂性，给日志管理和审计带来了新的挑战。
本文将讨论在分布式系统中有效管理和审计日志的策略和方法。
1. 日志管理的重要性日志是分布式系统中的重要组成部分，记录了系统的各种运行状态和操作事件。
有效的日志管理不仅可以帮助系统管理员实时监控系统运行情况，还可以为故障排除、性能调优和安全审计提供重要依据。
2. 日志收集与聚合在分布式系统中，日志通常分散在各个节点和组件中。
为了方便管理和审计，需要将分散的日志收集到一处进行统一管理。
常用的方法是使用分布式日志收集工具，如Elasticsearch、Logstash和Kibana（ELK）。
这些工具可以实现对分布式日志的实时收集、聚合和可视化展示，帮助管理员及时发现问题并做出相应处理。
3. 日志存储与保护对于分布式系统，日志的存储和保护也是至关重要的。
日志数据的大量积累需要相应的存储解决方案来确保数据完整性和可靠性。
常用的方法是使用分布式日志存储系统，如Apache Kafka、Hadoop和Cassandra，可以将日志数据进行分布式存储，提高系统的容错能力和可扩展性。
同时，为了保护日志数据的机密性和完整性，还可以使用加密和数字签名等安全机制进行保护。
4. 日志分析与异常检测分布式系统产生的日志数据非常庞大，如何从海量的日志中提取有用的信息成为一个挑战。
为了更好地利用日志数据，可以采用日志分析和异常检测技术。
通过构建机器学习模型和使用数据挖掘算法，可以自动分析日志数据并发现隐藏其中的异常行为和潜在问题，帮助管理员及时做出反应。
5. 日志审计与合规性在分布式系统中，日志审计是确保系统安全和合规性的重要手段。
通过对系统日志进行审计，可以发现潜在的安全漏洞和违规行为，并采取相应的措施进行处理。
同时，日志审计也是符合监管要求和行业标准的重要环节，可以以证据的形式呈现日志数据，为合规性审核和法律诉讼提供支持。
分布式系统中的监控与故障排查方法(五)
分布式系统是现代计算机系统中的重要组成部分，它可以在多个计算节点之间共享负载和数据，提高系统的可扩展性和容错性。
然而，由于其复杂性和分散性，分布式系统往往面临着各种监控和故障排查的挑战。
本文将探讨在分布式系统中的监控与故障排查方法。
一、监控方法在分布式系统中，监控是为了获取系统状态和性能指标的关键要素。
通过监控系统，可以及时发现并定位系统中的异常和瓶颈，并采取相应的措施进行优化。
以下是一些常用的监控方法。
1. 日志监控：日志是分布式系统中重要的监控信息来源之一。
通过分析日志文件，可以了解系统运行过程中的各种事件和异常情况。
可以使用日志分析工具来自动抽取关键信息，并建立相应的告警机制，以便及时发现问题。
2. 度量指标监控：度量指标包括系统资源使用率、处理速度、请求响应时间等，可以反映系统的性能状况。
可以使用开源工具如Prometheus，通过采集度量指标数据，并结合图表展示，进行实时监控和报警。
3. 分布式追踪：分布式追踪可以跟踪请求在分布式系统中的流程和调用链，帮助发现性能瓶颈和故障原因。
可以使用工具如Zipkin和Jaeger来实现分布式追踪，通过追踪信息的可视化和分析，找出系统中的瓶颈和问题。
二、故障排查方法在分布式系统中，故障排查是保证系统稳定性和可用性的关键环节。
当系统出现故障时，需要快速定位问题，并采取措施进行修复。
以下是一些常用的故障排查方法。
1. 利用监控数据：通过分析监控数据，可以了解系统中的异常情况和性能状况，从而定位故障原因。
比如，通过查看日志文件可以找到异常信息，通过度量指标监控可以找到性能瓶颈等。
2. 二分法定位：当系统中某个节点或组件发生故障时，可以通过采用二分法的方式逐步缩小排查范围。
首先将故障范围缩小到一半，然后继续将范围缩小，最终定位到具体的故障位置。
3. 灰度发布：在大规模的分布式系统中进行故障排查时，可以通过灰度发布来降低事故的影响范围。
首先将故障节点从系统中隔离出来，然后逐步增加流量，通过观察系统的反应和性能变化，推断故障的原因所在。
网络安全的日志分析与应用技术
网络安全的日志分析与应用技术网络安全是一个涉及到许多方面的复杂问题，其中之一就是如何对网络安全事件进行检测、分析和响应。
而日志分析技术就是在这个过程中起到至关重要的作用。
日志是网络设备和服务器记录事件的一种重要数据源，包括系统事件、用户操作、应用程序访问等等。
基于这些日志数据，可以进行网络安全事件的检测、响应和预测，以及网络优化和性能提升等方面的应用。
因此，日志分析技术也被广泛应用于各个领域，特别是网络安全领域。
本文将着重探讨网络安全的日志分析与应用技术。
一、日志分类不同的系统和应用程序所生成的日志格式不同，根据日志的格式和内容可以将其分成多个类型，比如事件日志、流量日志、系统日志、安全日志、访问日志等。
其中，安全日志是指记录与系统安全相关的事件和行为的日志，这种类型的日志对于网络安全检测和事件响应是非常重要的。
二、日志采集要进行日志分析，首先需要对日志进行采集，采集的方式多种多样，如系统日志、SNMP、syslog、调试信息等。
日志采集的方式可以分为两种：本地采集和远程采集。
本地采集是指在系统本地采集日志，通过系统内置的日志采集器和日志文件解析技术进行采集和解析。
这种方式的优点是简单易用，而且可靠性高，但是需要占用系统资源，而且对于分布式部署的系统要进行多次操作，不太适用。
远程采集是指在远程系统上进行日志采集，将采集到的日志通过网络传输到中央采集服务器进行分析，这种方式的优点是可以扩展到多个系统，能够将日志集中管理并提高采样的质量，但是需要在系统中安装采集工具，需要处理系统权限问题。
三、日志解析和存储日志解析是将日志中的有用信息进行提取的过程，通过解析可以将信息分类并格式化，将需要的信息移植到相应的数据库或者应用程序中。
通过日志解析和存储，可以对日志进行实时的监控和分析，以实现对网络瑕疵的及时发现和处理。
存储是指将采集到的日志存储到持久存储中，并建立索引，以便快速检索和查询。
日志数据的存储方式可以分为两种：关系数据库存储和非关系型数据库存储。
dlt日志解析
dlt日志解析摘要：1.日志解析简介2.DLT 日志解析的重要性3.DLT 日志解析方法4.常用的DLT 日志解析工具5.总结正文：1.日志解析简介日志解析是指对计算机系统、应用程序或网络设备等生成的日志文件进行分析，以了解其运行状态、排查问题和优化性能的过程。
在分布式系统中，日志解析尤为重要，因为它可以帮助管理员及时发现和解决问题。
2.DLT 日志解析的重要性DLT（Distributed Logging Technology）是一种分布式日志技术，广泛应用于金融、电信等行业。
DLT 日志解析在分布式系统中具有重要意义，因为它能够实现对系统运行状态的实时监控，及时发现故障，提高系统稳定性。
同时，通过对DLT 日志的分析，可以挖掘潜在的问题，为系统优化提供依据。
3.DLT 日志解析方法DLT 日志解析方法主要包括以下几个步骤：(1) 日志收集：收集分布式系统中各个节点产生的日志信息。
(2) 日志预处理：对收集到的日志信息进行清洗、格式化等预处理操作，以便于后续分析。
(3) 日志存储：将预处理后的日志信息存储到数据库或文件系统中，方便后续检索和分析。
(4) 日志分析：利用日志分析工具对存储的日志信息进行检索、统计和分析，找出潜在问题和异常行为。
(5) 日志可视化：将分析结果以图表、报告等形式展示，方便管理员快速了解系统运行状况。
4.常用的DLT 日志解析工具市场上有很多成熟的DLT 日志解析工具，例如：ELK、Splunk 等。
这些工具可以帮助管理员快速高效地完成DLT 日志解析任务。
5.总结DLT 日志解析作为分布式系统管理的重要环节，对于保障系统稳定运行、及时发现和解决问题具有重要意义。
rocketmq的使用案例
rocketmq的使用案例RocketMQ是一款开源的分布式消息中间件，具有高吞吐量、高可用性、可伸缩性和容错性的特点。
它主要用于解决分布式系统中的异步通信、解耦、削峰填谷等问题。
下面将列举10个RocketMQ 的使用案例。
1. 电商系统的订单处理：在电商系统中，订单的生成、支付、发货等操作都需要异步处理，以提高系统的并发性能和可靠性。
RocketMQ可以作为订单系统和其他系统之间的消息中间件，实现订单消息的可靠传输和异步处理。
2. 实时日志收集：在分布式系统中，日志的收集和分析是非常重要的。
RocketMQ可以作为日志系统的消息中间件，实现日志的实时收集和传输。
通过将日志消息发送到RocketMQ，可以实现多个消费者并行处理，并将日志存储到数据库或文件系统中。
3. 实时数据分析：在大数据场景下，实时数据分析对业务决策和监控非常重要。
RocketMQ可以作为数据分析系统的消息中间件，实现实时数据的传输和处理。
通过将数据消息发送到RocketMQ，可以实现多个数据分析任务并行处理，并生成实时报表或监控指标。
4. 分布式事务的处理：在分布式系统中，分布式事务的处理是非常复杂的。
RocketMQ提供了事务消息的支持，可以实现分布式事务的最终一致性。
通过发送事务消息和消费事务消息的确认，可以实现分布式事务的可靠处理。
5. 消息通知和推送：在移动互联网应用中，消息通知和推送是非常常见的功能。
RocketMQ可以作为消息推送系统的消息中间件，实现消息的可靠传输和推送。
通过将消息发送到RocketMQ，可以实现多个推送任务并行处理，并将消息推送给用户。
6. 分布式锁的实现：在分布式系统中，分布式锁的实现是非常困难的。
RocketMQ提供了分布式锁的支持，可以实现分布式锁的获取和释放。
通过发送锁消息和消费锁消息的确认，可以实现分布式锁的可靠处理。
7. 广告投放系统：在互联网广告系统中，广告的投放和统计是非常重要的。
zookeeper 日志格式解析
Zookeeper是一个开源的分布式应用程序调度服务，它主要是用于在大型分布式系统中协调和管理服务。
在Zookeeper的运行过程中，日志是非常重要的一部分，它记录了Zookeeper服务的运行状态、错误信息和重要事件。
了解Zookeeper的日志格式，可以帮助管理员更好地监控和维护Zookeeper服务。
本文将对Zookeeper的日志格式进行解析，帮助读者更深入地了解Zookeeper的运行情况。
一、Zookeeper日志的基本格式Zookeeper的日志通常包含时间戳、日志级别、线程名称、日志内容等信息。
其基本格式如下：[时间戳] [日志级别] [线程名称] 日志内容时间戳格式一般为yyyy-MM-dd HH:mm:ss,SSS，表示年-月-日时:分:秒,毫秒。
日志级别包括：DEBUG(调试)、INFO(信息)、WARN(警告)、ERROR(错误)等。
线程名称表示打印该日志的线程名称。
日志内容记录了具体的事件信息或错误信息。
二、Zookeeper日志中常见的信息1. 连接信息Zookeeper服务启动后，会生成一系列日志来记录客户端与服务端之间的连接信息。
这些日志一般以“Opening socket connection to server”的形式出现，其中包含了服务端的IP位置区域和端口号，以及客户端与服务端之间建立连接的信息。
2. 选举信息在Zookeeper集群中，存在着一个Leader节点和多个Follower节点。
当Leader节点宕机或者失去连接时，集群会进入新一轮的Leader选举过程。
这时会产生一系列关于Leader选举的日志信息，可以通过这些日志了解Leader选举的过程和结果。
3. 客户端请求Zookeeper客户端向服务端发送请求时，会产生一系列关于请求处理的日志。
这些日志记录了客户端发送的具体请求信息、请求的处理过程以及处理结果。
通过这些日志，可以了解Zookeeper服务端对客户端请求的处理情况。
dlt日志解析
dlt日志解析DLT（分布式账本技术）是一种新兴的区块链技术，它主要用于构建去中心化的数字账本，使得数据难以篡改和伪造。
DLT技术的出现对于金融、供应链、物联网等行业有着重要的意义。
然而，由于DLT技术的复杂性和高度安全性，对其日志进行解析难度较大。
本文将重点讨论DLT日志的解析过程，并探讨其施用实践。
首先，DLT日志是记录DLT网络中所有的节点操作和链上交易的记录，它可以用于追踪历史交易、事件、错误等信息。
解析DLT日志可以帮助我们了解网络的运行状况、交易的合法性和节点的行为。
解析DLT日志的一般流程包括以下几个步骤：日志收集、格式化、分析和可视化。
日志收集是解析DLT日志的第一步，它可以使用日志管理工具，如ELK（Elasticsearch、Logstash、Kibana）等，用于收集DLT节点的日志信息。
DLT技术通常基于P2P网络，因此，可以利用P2P消息传输协议（如TCP/IP、HTTP）来收集节点的日志。
在收集日志时，需要定义和配置日志收集器，以确保能够收集到所需的日志信息。
一旦收集到DLT日志，下一步是对其进行格式化。
由于DLT技术的多样性和灵活性，不同DLT系统往往具有不同的日志格式。
因此，格式化DLT日志是解析过程中的关键一步。
格式化DLT日志需要根据日志的结构、字段和格式特点，定义相应的解析规则。
解析规则可以通过正则表达式、模式匹配等方式来描述。
然后，使用日志解析工具（如Logstash）来执行解析规则，将DLT日志转化为结构化的数据格式，如JSON、CSV等。
接下来，对格式化后的DLT日志进行分析是解析过程的核心工作。
DLT日志中包含了大量的信息，如交易记录、节点通信、智能合约执行等。
通过分析DLT日志，可以了解DLT网络的交易流程、节点间的合作关系、合约执行的结果等。
在分析DLT日志时，通常需要借助数据分析工具和技术，如数据挖掘、机器学习等，来发现潜在的规律和关联。
例如，可以通过挖掘DLT日志中的异常行为、错误信息来检测潜在的恶意攻击或系统故障。
系统日志分析的主要用途
系统日志分析的主要用途系统日志分析是一种通过收集、解析和处理系统日志数据来获取有关系统运行状况的有关信息的过程。
它可以帮助我们发现和解决系统问题，提高系统的性能和稳定性，并提供有关系统运行情况的实时监控。
系统日志分析的主要用途如下：1. 故障排除：系统日志记录了系统的操作、事件和错误信息，我们可以通过分析日志来定位系统故障的原因。
例如，当系统出现宕机、应用程序崩溃、网络连接中断等问题时，可以通过分析日志来发现问题所在，从而采取适当的措施。
2. 安全监控：系统日志可以记录安全事件，如入侵尝试、异常访问、恶意软件活动等。
通过分析日志，我们可以检测潜在的安全威胁，并采取相应的安全措施，以防止信息泄露、数据丢失和系统被入侵。
3. 性能优化：系统日志包含了系统资源的使用情况、处理时间、访问模式等信息，通过分析这些日志，我们可以找出系统的瓶颈和资源浪费的地方，然后优化系统的配置和性能，提高系统的吞吐量和响应时间。
4. 预测和容量规划：通过分析历史系统日志数据，我们可以了解系统的使用模式和趋势，从而进行预测和容量规划。
这有助于我们确定系统的资源需求，并在需要增加或减少系统资源时做出相应的决策，以满足业务需求。
5. 统计分析：系统日志可以提供有关用户访问模式、应用程序使用情况、数据库查询次数等信息。
通过对这些日志进行统计分析，我们可以了解用户行为和需求，为业务决策提供数据支持。
6. 合规性和审计：许多行业和法规要求企业对其系统日志进行监测和审计。
通过对系统日志的分析，我们可以确保系统的合规性，并生成用于审计目的的报告和日志文件。
7. 操作监控：系统日志可以提供有关系统操作员和管理员的活动记录，包括登录、权限管理、配置更改等。
通过分析这些日志，我们可以监控操作员的行为，并对异常活动进行检测和报警。
总结起来，系统日志分析是一项重要的工作，它涉及到故障排除、安全监控、性能优化、容量规划、统计分析、合规性和审计以及操作监控等多个方面。
分布式数据库的性能监控与故障排查方法(系列六)
分布式数据库的性能监控与故障排查方法随着大数据时代的到来，分布式数据库系统正逐渐成为信息化建设中不可或缺的一部分。
然而，随之而来的是如何有效监控和排查分布式数据库的性能问题与故障，成为了数据库管理员面临的新挑战。
本文将探讨一些常用的分布式数据库性能监控与故障排查方法。
一、性能监控1. 数据库性能指标了解数据库的性能指标是分布式数据库监控的基础。
常见的性能指标包括：响应时间、吞吐量、并发连接数、CPU和内存利用率等。
可以通过数据库管理系统提供的监控工具获取这些性能指标的数据，并利用图表展示，以便于管理员进行分析和判断。
2. 实时监控实时监控是快速发现问题的关键。
管理员可以通过配置监控系统，实时收集和监控数据库的性能数据。
在性能指标超过预设的阈值时，监控系统可以即时发出警报，在最短的时间内通知管理员，并采取相应的措施，避免问题进一步扩大。
3. 异常检测除了实时监控，异常检测也是一种重要的性能监控方式。
管理员可以利用机器学习和统计分析的方法，构建性能模型并训练，从而预测数据库性能的变化趋势。
一旦性能数据偏离了正常范围，就可以及时发现并排查问题。
二、故障排查1. 日志分析日志是故障排查时的重要依据，因为它记录了系统运行的各种信息和事件。
管理员可以通过分析数据库的日志文件，找到异常和故障发生的时间、原因以及导致故障的操作等。
日志分析可以帮助管理员快速定位问题，并采取相应的修复措施。
2. 监控工具除了实时监控数据库的性能指标，还可以借助监控工具进行故障排查。
监控工具可以实时跟踪数据库的运行状态、节点之间的通信情况以及数据的传输过程。
管理员可以根据监控工具提供的信息，分析和定位导致故障的原因，并进行相应的处理。
3. 灰度测试灰度测试是一种先进的故障排查方法。
管理员可以通过在数据库集群的一部分节点上进行灰度测试，模拟不同的工作负载和异常情况，观察和分析数据库的响应情况。
通过灰度测试，可以发现和解决潜在的性能问题和故障，提高数据库的稳定性和可靠性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
㊀ｄｏｉ:１０.３７７２/ｊ.ｉｓｓｎ.１００２￣０４７０.２０１９.０４.００１分布式系统中的日志分析及应用①陆㊀杰②∗∗∗∗㊀李㊀丰∗∗㊀李㊀炼∗∗∗∗(∗中国科学院计算技术研究所计算机体系国家重点实验室㊀北京１００１９０)(∗∗中国科学院信息工程研究所㊀北京１００１９３)(∗∗∗中国科学院大学㊀北京１００１９０)摘㊀要㊀分布式系统是支撑当前大数据时代各种大数据应用和在线服务的基础平台ꎬ分布式系统的质量是大数据应用提供良好服务的基础和前提ꎮ伴随着大规模分布式系统的广泛应用ꎬ由分布式系统缺陷带来的影响和危害日益严重ꎮ但分布式系统在设计㊁实现和部署方面的复杂性ꎬ导致系统的开发和维护人员很难准确地理解和掌握整个系统的行为ꎬ难以及时发现系统中存在的故障并进行修复ꎮ分布式系统日志涵盖了丰富的信息ꎬ是辅助用户理解分布式系统逻辑㊁剖析系统性能㊁检测系统异常以及诊断故障原因的重要依据ꎮ但复杂的日志结构㊁庞大的日志规模以及属于不同功能模块㊁不同用户请求的日志之间相互交错ꎬ为人工分析㊁挖掘日志中的有效信息带来了巨大的困难ꎮ本文对近年来针对分布式系统日志的分析和应用技术进行综述:首先总结了分布式系统日志分析与应用的通用流程ꎬ提炼出其中的３个关键步骤ꎬ即日志的收集与解析㊁日志划分㊁以及日志特征的挖掘与应用ꎻ然后针对上述３个关键步骤ꎬ逐一分析需要解决的技术问题ꎬ分类阐述目前主流的技术方案ꎬ对比技术特征或适用场景ꎮ文章还归纳了目前常用的３类日志特征ꎬ并从４个方面就该领域未来可能的研究方向提出展望ꎮ关键词㊀分布式系统ꎬ日志分析ꎬ特征挖掘ꎬ异常检测ꎬ故障诊断０㊀引言分布式系统是支撑大数据时代各种大数据应用和在线服务的基础平台ꎬ如服务于大规模数据存储的分布式数据库ＢｉｇＴａｂｌｅ[１]和分布式文件系统ＨＤＦＳ[２]ꎬ服务于大规模数据处理的分布式计算框架ＭａｐＲｅｄｕｃｅ[３]和Ｓｐａｒｋ[４]ꎬ服务于云计算平台的ＯｐｅｎＳｔａｃｋ[５]等ꎮ这些分布式系统的正常运行是在线服务质量的基础和前提ꎮ伴随着大规模分布式系统的广泛应用ꎬ由分布式系统缺陷(如设计缺陷㊁实现缺陷㊁硬件缺陷等)带来的影响和危害日益严重ꎮ比如２０１１年ꎬ亚马逊公司的ＥＣ２平台的一个缺陷导致集群中的所有存储空间被耗尽ꎬ经过两天的修复ꎬ仍有０.０７％的用户数据无法复原[６]ꎮ此外ꎬ据文献[７ꎬ８]统计ꎬ微软㊁脸书等公司的分布式系统每年总计的宕机时间约有７.７３８小时ꎬ由此带来的经济损失高达２.８５亿美元ꎮ如何确保分布式系统持续性地提供高质量服务是学术界和工业界广泛关注的问题ꎮ为确保分布式系统持续性地提供高质量的服务ꎬ系统维护人员需要熟悉系统的整体构造和局部逻辑ꎬ从而能够及时发现系统运行时的故障㊁快速诊断出故障原因并进行修复ꎮ但是分布式系统通常规３０３㊀高技术通讯２０１９年第２９卷第４期:３０３~３２０㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀㊀①②国家重点研发计划(２０１７ＹＦＢ０２０２００２)和国家自然科学基金(６１５２１０９２)资助项目ꎮ男ꎬ１９９１年生ꎬ博士生ꎻ研究方向:编译ꎬ程序分析ꎬ日志分析ꎬ分布式系统ꎻ联系人ꎬＥ￣ｍａｉｌ:ｌｕｊｉｅ＠ｉｃｔ.ａｃ.ｃｎ(收稿日期:２０１８￣０７￣１０)模庞大并且实现逻辑复杂ꎬ其行为受运行时系统中不同机器节点的软硬件环境以及所处网络环境的影响ꎬ导致系统的开发和维护人员很难准确地理解和掌握整个系统的运行ꎬ难以及时发现系统中存在的故障并进行修复ꎮ它们通常还会和其他分布式系统交互(例如ＨＢａｓｅ[９]可以运行在ＨＤＦＳ之上)ꎬ导致开发人员很难准确地理解和掌握系统的整体结构以及各个组件间的关联ꎮ此外ꎬ由于受到自身复杂性和运行环境两方面的影响ꎬ分布式系统中的故障传播具有传播链较长㊁跨节点㊁跨组件等特点ꎬ需要维护人员深刻理解系统中各个组件的逻辑才能准确地诊断故障的根源并进行修复ꎮ比如ꎬ文献[１０]描述的故障是由６个节点间的复杂通信导致的ꎬ而文献[１１]报告的故障是由系统间的交互引起的ꎬ根本原因是ＭａｐＲｅｄｕｃｅ任务无法获取ＨＢａｓｅ的一些监控信息ꎮ因此ꎬ迫切需要有效手段来辅助用户理解大规模分布式系统㊁剖析其性能㊁监测其运行时的状态ꎬ从而及时发现故障并进行诊断ꎮ目前主流的方法可以分为侵入式(ｉｎｔｒｕｓｉｖｅ)和非侵入式(ｎｏｎ￣ｉｎｔｒｕｓｉｖｅ)两类[１２]ꎮ侵入式方法通过对被分析系统的源代码插桩ꎬ在运行时收集能够表征系统中关键执行行为的信息ꎬ并维护这些信息之间的时序依赖关系ꎮ代表性的技术是端到端跟踪技术[１３￣１５]ꎮ侵入式方法需要用户参与选择插桩位置和待收集的信息ꎬ且插桩的位置和信息需要随着系统的演进持续更新ꎬ因此更适合对系统有较为深入了解的高层次用户ꎮ相比之下ꎬ基于日志的非侵入式方法ꎬ由于能够适应更广泛的用户群体ꎬ近年来逐渐得到青睐ꎮ非侵入式方法以对分布式系统日志的分析为基础ꎮ日志由分布式系统源码中自带的日志打印语句在系统执行过程中输出到日志文件ꎮ这些日志打印语句由系统开发人员书写ꎬ用于记录系统中的关键事件或状态ꎮ日志文件可以辅助开发者和系统维护者了解系统的运行实况ꎬ及时发现和诊断系统在测试或实际运行过程中存在的问题ꎬ并在必要时借助日志ꎬ重新构建出对应的执行轨迹ꎮ为了更好地辅助用户理解分布式系统逻辑㊁分析其性能ꎬ并辅助检测分布式系统运行时的故障㊁诊断异常的原因ꎬ分布式系统的开发者通常会在源码中的关键位置输出充足的日志[１６]ꎮ第１节将通过一个Ｈａｄｏｏｐ[１７]集群及其日志构成说明分布式系统日志的作用ꎬ以及人工分析日志面临的困难ꎮ１㊀背景图１所示的６节点集群上运行了Ｈａｄｏｏｐ的分布式资源管理服务㊁计算服务以及文件系统服务ꎬ分别由Ｙａｒｎ㊁ＭａｐＲｅｄｕｃｅ和ＨＤＦＳ三个分布式系统提供ꎮＹａｒｎ采用主从结构ꎬ运行在Ｎｏｄｅ１节点上的ＲｅｓｏｕｒｃｅＭａｎｇｅｒ(ＲＭ)组件负责管理和分配集群资源(资源包括计算㊁内存㊁带宽等ꎬ资源分配的单位是ｃｏｎｔａｉｎｅｒ)ꎻ运行在其他节点上的Ｎｏｄｅｍａｎｇｅｒ(ＮＭ)组件负责监控对应节点上的资源使用情况并汇报给ＲＭꎮＭａｐＲｅｄｕｃｅ运行在Ｙａｒｎ之上(Ｙａｒｎ还支持Ｓｐａｒｋ等其他分布式计算框架)ꎬ主要包含Ｍａｐ和Ｒｅｄｕｃｅ两个功能模块ꎮＨＤＦＳ也采用主从结构ꎬ由运行在Ｎｏｄｅ６上的ＮａｍｅＮｏｄｅ(ＮＮ)组件负责管理文件命名空间ꎮ以上组件都属于集群的后台服务进程ꎬ需要在运行用户作业前启动ꎮ图１中的箭头代表了由不同用户提交的２个作业请求的执行过程ꎮ以黑色较粗箭头所示的用户请求１为例ꎬ用户通过客户端提交作业请求后ꎬＲＭ首先为它创建并启动一个专门用于管理该作业所需资源的进程ＡｐｐｌｉｃａｔｉｏｎＭａｓｔｅｒ(ＡＭ)ꎮ图１中ꎬ用户请求１的管理进程ＡＭ１启动在Ｎｏｄｅ２上ꎮ对于Ｍａ￣ｐＲｅｄｕｃｅ作业ꎬＡＭ将根据作业需要处理的数据规模创建一定数量的Ｍａｐ和Ｒｅｄｕｃｅ任务(这些任务对应Ｈａｄｏｏｐ中Ｍａｐ或Ｒｅｄｕｃｅ功能模块的一次执行)ꎬ并向ＲＭ申请资源ꎻ获取资源后ꎬ在资源所在的ＮＭ上分别启动这些任务ꎮ比如ꎬ图１中ꎬＲＭ分配给ＡＭ１的资源分别位于Ｎｏｄｅ４和Ｎｏｄｅ５上ꎬＡＭ１在这２个节点上分别启动了一个进程运行对应的Ｍａｐ或Ｒｅ￣ｄｕｃｅ任务ꎮ任务执行过程中将访问ＨＤＦＳ上的数据ꎬ或将结果写入ＨＤＦＳ图１方框中的文本即上述用户请求在执行过程中产生的日志ꎮ可以看到ꎬ这些日志分散地保存在不同节点的不同日志文件中ꎮ日志文件又分为由后台服务进程创建的日志文件４０３高技术通讯㊀２０１９年４月第２９卷第４期(比如图１中的ＹＡＲＮ￣ＲＭ.ｌｏｇ㊁Ｎａｍｅｍａｎｇｅｒ５.ｌｏｇ)和作业本身的执行日志(比如图１中的ＡＭ１.ｌｏｇ㊁ｃｏｎｔａｉｎｅｒ１３.ｌｏｇ)两类ꎮ如果日志分析的目标是理解或重构出用户请求的执行行为ꎬ就必须首先将这些分散在不同节点上的不同日志文件中隶属相同用户请求的日志提取出来ꎮ比如图中日志文件中黑体加粗的文本都是隶属用户请求１的日志ꎮ图１㊀Ｈａｄｏｏｐ的用户请求执行图㊀㊀日志中蕴含的信息不仅可以用来识别和区分用户请求ꎬ而且可以辅助理解分布式系统的执行行为㊁性能分布ꎬ发现运行过程中的功能或性能异常并提供诊断提示ꎮ仍以图１为例ꎬ变量值ａｐｐ１和ａｐｐ２可以区分不同的用户请求ꎮ对于隶属相同用户请求日志ꎬ可以进一步根据时间戳确定日志条目所代表的事件发生的先后序或时间差ꎬ对比和挖掘其中执行顺序或间隔时间有异常的事件(日志)序列ꎮ也可以通过对比一些特定的变量的值分布情况来识别异常ꎮ除了根据用户请求ꎬ也可以根据节点名将属于同一个节点的日志聚集在一起ꎬ通过分析和对比每个节点的负载㊁响应时间等ꎬ及时发现可能成为性能瓶颈的节点(ｃｕｌｐｒｉｔｎｏｄｅ[１８])ꎮ分布式系统日志虽然携带了丰富的信息ꎬ但系统每天需要处理大量的用户请求ꎬ产生海量的日志ꎮ这些日志大部分是如图１所示的非结构化日志ꎮ除了规模庞大㊁格式复杂之外ꎬ隶属不同功能模块㊁不同用户请求的日志相互交错ꎬ为人工分析和挖掘日志中的有效信息ꎬ带来了巨大的困难ꎮ针对这些问题ꎬ出现了各种自动分析日志并挖掘和应用日志特征的技术ꎮ本文对近年来利用日志分析辅助用户理解分布式系统逻辑㊁剖析系统性能㊁检测异常以及诊断故障的技术进行综述ꎮ第２节基于对现有日志分析和应用技术的归纳ꎬ总结出日志分析与应用的通用流程ꎬ并提炼出其中的３个关键步骤:日志的收集与解析㊁日志划分㊁以及日志特征的挖掘与应用ꎮ第３㊁４㊁５节分别就上述３个关键步骤中存在的技术问题以及５０３ 陆㊀杰等:分布式系统中的日志分析及应用解决方法进行归纳㊁总结和对比ꎮ其中ꎬ第３节介绍了日志收集的基本原理ꎬ阐述并对比了两类主流的日志解析方法的优缺点和适用场合ꎮ第４节将描述日志划分阶段采取的技术方案ꎬ并提炼出各个方案需要解决的关键问题ꎮ第５节将现有技术挖掘和使用的日志特征归纳成３大类ꎬ并就各类日志特征在分布式系统理解㊁剖析㊁检测和诊断方面的应用进行分类阐述ꎬ总结其中存在的问题ꎮ基于对３个关键步骤中主流技术的对比和总结ꎬ第６节就该领域面临的问题以及可能的研究方向进行了展望ꎮ２㊀日志分析及应用的基本流程本节基于近年来的代表性工作ꎬ总结了分布式系统日志分析和应用的基本流程(如图２所示)ꎮ流程包括３个主要步骤:日志的收集与解析㊁日志划分㊁日志特征的挖掘与应用ꎮ首先ꎬ收集系统中各个节点产生的日志ꎬ从中解析出各类信息ꎬ再结合不同应用需求ꎬ选取适当的信息维度对日志进行划分ꎬ并在划分得到的日志集合中进行针对性的特征挖掘ꎬ最后将挖掘结果应用于系统理解(ｓｙｓｔｅｍｕｎｄｅｒ￣ｓｔａｎｄｉｎｇ)㊁性能剖析(ｐｅｒｆｏｒｍａｎｃｅｐｒｏｆｉｌｉｎｇ)㊁异常检测(ａｎｏｍａｌｙｄｅｔｅｃｔｉｏｎ)㊁故障诊断(ｐｒｏｂｌｅｍｄｉａｇｎｏｓｉｓ)等不同实际需求中ꎮ接下来将依次介绍各个步骤的作用和原理ꎮ日志收集的目的是将分布式系统各个节点所产生的日志收集到一起ꎮ分布式系统执行过程中ꎬ各个节点产生的日志通常默认存储在该节点的本地文图２ 日志分析的整体流程件系统中(比如图１中的ＡＭ１.ｌｏｇ㊁Ｎａｍｅｎｏｄｅ.ｌｏｇ分别默认存储在Ｎｏｄｅ２和Ｎｏｄｅ６上)ꎮ但由于分布式系统提供的服务往往由运行在不同节点上的服务组件协同完成(比如图１中的ＡＭ１和ｃｏｎｔａｉｎｅｒ１３共同完成Ｒｅｄｕｃｅ模块的一次执行ꎬ产生的日志分散地存储在Ｎｏｄｅ２和Ｎｏｄｅ５上)ꎬ只有将分散在这些节点上的日志汇集在一起ꎬ才有可能掌握或重构出该功能的执行逻辑ꎮ日志收集既可以手动完成ꎬ也可以借助在线日志收集工具自动收集ꎮ部分日志收集工具还附带按照日志等级对日志分类㊁用正则表达式对日志进行过滤等功能ꎮ代表性的日志收集工具有ＬｏｇＳｔａｓｈ等[１９￣２６]ꎬ３.１节将介绍其中的关键技术ꎮ日志解析的目的是从收集到的日志中提取信息ꎮ日志解析既可以与日志的在线收集同步进行ꎬ也可以单独离线进行ꎮ日志解析技术重点关注的是６０３ 高技术通讯㊀２０１９年４月第２９卷第４期如图１所示的非结构化日志ꎮ这些日志没有统一的格式ꎮ目前用于解析非结构化日志的方法大致可以分为两类ꎮ一类是基于对源码或二进制文件的分析ꎬ自动推导出各条日志打印语句的文法ꎬ表示成正则表达式的形式ꎬ再通过正则表达式匹配识别日志中包含的信息ꎮ另一类方法只分析日志文件本身ꎮ它们使用聚类算法将相似的(即可能由相同日志打印语句产生的)日志聚集在一起ꎮ每个聚类集合中的日志ꎬ公共部分通常对应日志中的静态文本ꎬ剩余部分对应日志中的变量值ꎮ公共文本通常也被用来代表(区分)系统中不同的事件或者不同的日志类型ꎮ３.２节将介绍这两类方法的技术细节以及存在的问题ꎮ日志划分是指从日志解析得到的信息中选择某个或某几个信息维度将日志聚集在一起ꎬ得到一系列日志集合ꎮ其中每个日志集合包含的日志均存在某一方面的关联性ꎮ以图１中的日志为例ꎬ如果用户想要了解被标记为ａｔｔｅｍｐｔ１ｒ０的Ｒｅｄｕｃｅ任务的执行情况ꎬ可以将图中所有包含变量值ａｔｔｅｍｐｔ１ｒ０的日志归入同一个日志集合ꎮ通过日志划分步骤ꎬ可以过滤与用户需求无关的日志ꎬ将关联性较大的日志聚集在一起ꎬ减少待分析的日志规模ꎬ降低无关信息对后续分析过程的干扰ꎬ提高日志特征挖掘的效率与精度ꎮ第４节将详细介绍日志划分技术ꎮ挖掘日志特征的最终目的是服务于应用ꎮ目前的研究工作关注的应用大致可以分为以下４类:系统理解㊁性能剖析㊁异常检测和故障诊断ꎮ不同的应用挖掘和使用的日志特征不尽相同ꎬ也各有侧重ꎮ常见的日志特征有:时序特征[２７￣２９]㊁数量特征[１６ꎬ３０ꎬ３１]㊁时间特征[１２ꎬ３２]等(见第５节)ꎮ以图１为例ꎬ如果日志划分阶段将包含变量值ａｔｔｅｍｐｔ１ｒ０的日志归入同一个日志集合ꎬ在特征挖掘阶段ꎬ就可以通过挖掘集合内日志之间的因果关系(实际应用中常以时序关系代替因果关系)ꎬ为ａｔｔｅｍｐｔ１ｒ０代表的Ｒｅｄｕｃｅ任务构造执行流(ｒｅｑｕｅｓｔｆｌｏｗ)ꎬ再从执行流中提取诸如关键路径等信息服务于性能剖析ꎬ辅助用户发现性能瓶颈ꎮ如果特征挖掘的目的是辅助用户理解系统行为ꎬ则特征挖掘阶段更倾向于分析和提取在各个日志集合内都成立的时序特征ꎮ比如ꎬ图１中包含变量值ａｔｔｅｍｐｔ１ｍ０和ａｔ￣ｔｅｍｐｔ２ｍ０的日志分别对应Ｍａｐ模块的两个执行实例ꎬ即两个Ｍａｐ任务(这两个任务分别隶属用户请求１和用户请求２)ꎮ假设日志划分阶段将包含变量值ａｔｔｅｍｐｔ１ｍ０和ａｔｔｅｍｐｔ２ｍ０的日志分别归入两个不同的日志ꎮＡＭｃｒｅａｔｅｄｔａｓｋ ң ＡＭＤｉｓｐａｔｃｈｏｎ (１)集合ꎬ则这两个集合都满足表达式(１)所示的时序不变式ꎮ表达式(１)以日志中的静态文本代表日志类型ꎬ以 ң 代表ｈａｐｐｅｎｅｄ￣ｂｅｆｏｒｅ关系[３３]ꎬ表达的含义是:只有当一个任务被创建后ꎬ系统才能为它分配资源ꎮ如果还存在另外一个Ｍａｐ任务的日志集合ꎬ从中挖掘出的时序违反了表达式(１)ꎬ则该集合中的日志对应的程序行为将被报告为异常或突变(ｍｕｔａｔｉｏｎ)ꎮ在发现包含异常的日志集合后ꎬ故障诊断应用可以进一步分析和对比正常集合和异常集合之间的日志特征差异ꎬ为用户提供更多更详细的有关异常原因的线索ꎮ第５节将详细介绍对日志特征的挖掘及应用ꎮ３㊀日志的收集和解析如前所述ꎬ日志的收集与解析既可以在线进行ꎬ也可以离线完成ꎮ在线收集和解析能够尽早发现系统中可能存在的功能或性能异常㊁诊断它们的原因ꎬ但缺点是可能占据系统资源ꎬ影响系统正常对外提供服务ꎮ离线收集与解析虽然不影响系统性能和资源ꎬ但在异常发现和故障诊断方面存在滞后性ꎮ本文将着重描述目前比较流行的在线方法ꎮ３.１㊀日志的在线收集为了应对在线收集分布式系统日志所面临的问题ꎬ许多公司以及开源组织纷纷开发出了具有高可用性㊁高可靠性和高可扩展性的日志收集平台[１９ꎬ２４￣３２]ꎮ这些平台自身也是分布式部署ꎬ分为代理层㊁接收层和存储层ꎮ为方便管理ꎬ日志分析平台通常选用主￣从式结构ꎬ即使用一个主节点(ｍａｓｔｅｒ)统一管理所有的发送/接收节点ꎮ代理层由部署在被监控系统各个节点上的代理进程构成ꎮ代理进程７０３陆㊀杰等:分布式系统中的日志分析及应用负责监控日志文件或者指定的数据流ꎬ将新收集到的数据缓存在本地ꎬ并实时发往接收层ꎮ仅当接收层收到数据后ꎬ代理进程才将对应的数据从缓冲区删除ꎮ为了减轻带宽压力ꎬ有些日志系统支持用户书写正则表达式过滤无用的日志ꎬ或者只传输日志中被认为是关键的数据ꎮ比如Ｓｔｉｔｃｈ[３２]不只传输变量值和时间戳ꎬ还对被传输的数据进行压缩ꎬ以进一步降低对被监控系统带宽的占用ꎮ接收层开启多个接收进程接收数据ꎬ并使用负载均衡工具(如ｚｏｏｋｅｅｐｅｒ[３４])均衡接收节点的负载ꎮ接收进程数量随代理进程数量的增加而增加ꎬ但前者的数量应小于后者ꎮ日志收集平台会监控每个代理进程和接收进程的存活情况ꎬ如果发现有代理进程死掉ꎬ立刻重启ꎮ如果一个接收程序死掉ꎬ代理进程会将数据发往另一个接收进程ꎮ接收层将收到的数据存储在存储层ꎮ存储层通常选择扩展性较好的数据库或者文件系统ꎬ比如ＨＤＦＳꎮ如果数据库或文件系统宕机ꎬ接收端会将数据存储在本地磁盘ꎬ并在数据库或文件系统恢复工作后重新传输ꎮ为了方便用户对收集到的日志进行更系统地解析㊁分析和挖掘ꎬ日志收集平台端通常还会提供查询接口和可视化界面ꎮ用户既可以使用人工书写正则表达式或ＳＱＬ查询语句的方式手工查找所关心的日志ꎬ也可以集成ＭａｐＲｅｄｕｃｅ等分布式计算框架对所收集的日志进行实时自动化地分析处理[２２]ꎮ３.２㊀日志的解析如前所述ꎬ日志解析的目的是提取日志中包含的信息(如图３所示)ꎬ作为后续日志划分和特征挖掘的输入ꎮ日志解析的重点是对非结构化日志的处理ꎮ目前自动日志解析技术可以分为基于文法的方法和基于聚类的方法两类ꎮ图３㊀日志解析㊀㊀基于文法的日志解析方法此类方法将日志打印语句的文法表示成正则表达式的形式(图３第３行)ꎬ再用正则表达式匹配日志ꎬ识别其中包含的时间戳㊁静态文本㊁变量值等信息(图３第１行)ꎮ部分研究工作ꎬ如ＣＳｉｇｈｔ[２７]㊁Ｉｖａｎ[３５]和Ｌｏｇｓｔａｓｈ[２０]ꎬ在解析日志时ꎬ要求用户提供正则表达式ꎮ这类方法一方面要求用户具备一定的专家知识ꎬ另一方面不容易推广ꎮＸｕ[１６]㊁ｌｐｒｏｆ[１２]㊁ＥＬＴ[３６]基于源码分析日志打印语句的文法ꎬ形成正则表达式ꎮ由于目前大部分分布式系统都使用通用的日志库(如:Ｌｏｇ４ｊ[３７]㊁ＪａｖａＣｏｍｍｏｍＬｏｇ)函数接口打印日志ꎬ通过在源码或中间代码中搜索这些日志库接口函数(如:Ｌｏｇ４ｊ的ｆａ￣ｔａｌ㊁ｅｒｒｏｒ㊁ｗａｒｎ㊁ｉｎｆｏ㊁ｄｅｂｕｇ㊁ｔｒａｃｅ)的调用点ꎬ就可以识别出日志打印语句ꎮ在解析日志打印语句的文法构成㊁推导正则表达式的过程中ꎬＥＬＴ[３６]将其中被双引号包裹的字符串识别成静态文本ꎬ而将剩余的部分识别成变量ꎮＸｕ[１６]则根据抽象语法树上所记录的变量类型区分日志打印语句中的变量和静态文本ꎮ为了更精确地识别面向对象程序中的变量类型信息ꎬＸｕ递归地解析日志打印语句中出现的变量类型及其子类的ｔｏＳｔｒｉｎｇ函数ꎬ直到所分析的类型为基本类型ꎮ通过这个方法ꎬ为每个日志打印语句生成了所有可能用来匹配日志的正则表达式ꎮ在匹配日志条目时ꎬ根据最长匹配原则ꎬ选出匹配度最高的正则表达式ꎮｌｐｒｏｆ[１２]在解析日志时采取了和Ｘｕ相同的方法ꎮ与上述基于源码分析日志打印语句文法并形成正则表达式的工作不同ꎬＳｔｉｔｃｈ[３２]仅分析程序的可执行文件ꎮ它首先通过ｌｉｎｕｘ系统/ｐｒｏｃ目录下的文件找出正在运行的进程ꎬ再根据每个进程的文件描述符找到进程打开的文件ꎬ目的是找出打开了名称８０３ 高技术通讯㊀２０１９年４月第２９卷第４期以ｌｏｇ结尾的文件的进程ꎬ然后在该进程的可执行文件(比如:ｊａｖａｂｙｔｅｃｏｄｅ㊁ｐｙｔｈｏｎｂｙｔｅｃｏｄｅ或ＥＬＦ文件)中找出所有的静态文本ꎬ使用这些静态文本和动态规划算法最大化地匹配每条日志ꎬ最后根据匹配结果ꎬ将日志中未匹配的部分识别成变量值ꎬ再根据静态文本和变量值生成正则表达式ꎮ基于聚类的日志解析方法此类方法通常不需要分析源代码ꎬ而是基于聚类算法ꎬ将相似的(即可能由相同日志打印语句产生的)日志聚集在一起ꎮ目前的工作多使用编辑距离及其变种作为度量日志间相似度的基础ꎮ理想的聚类结果是每个聚类集合中的日志都由同一条日志打印语句产生ꎻ对于每个聚类集合ꎬ日志间公共的部分对应日志中的静态文本ꎬ剩余部分对应日志包含的变量值ꎮ对于此类技术ꎬ设计合理的日志相似度度量公式是决定解析效率和精度的关键ꎮ其中ꎬＪｉａｎｇ[３８]和Ｆｕ[３９]为了提高聚类精度ꎬ在聚类前先根据经验规则识别日志中的变量值ꎮＪｉａｎｇ识别变量值的目的是在聚类时同时考虑了静态文本和变量数量两方面的相似度ꎬＦｕ的目的则是排除变量值对相似度计算的干扰ꎮ但Ｊｉａｎｇ的经验规则过于单一ꎬ并不适合图１所示的日志ꎻＦｕ也只支持对常见变量值(如ＩＰ地址㊁ＵＲＬ㊁数字等)的识别ꎬ如果处理对象是图１中的日志ꎬ则需要用户手工补充规则ꎮＬｏｇＳｉｇ[４０]和ＬｏｇＴｒｅｅ[４１]不需要提前识别日志中的变量值ꎬＬｏｇＳｉｇ提出利用单词之间的序来提高聚类算法的精度ꎻＬｏｇＴｒｅｅ则要求由用户为被分析系统提供日志的上下文无关文法ꎬ作为分析的基础ꎮ上述工作对日志的聚类都是离线进行的ꎬＢａｒａｓｈ[４２]提出了一种线上聚类的日志解析技术ꎮ目前ꎬ基于文法的日志解析技术在解析精度上优于基于聚类的技术ꎬ对于源码可见或二进制码未经加固的分布式系统的日志解析方面更具优势ꎻ但基于聚类的方法对于使用多种语言编写的分布式系统ꎬ以及源码不可见或二进制文件经过加固的商用分布式系统ꎬ具有更强的适应性ꎮ此外ꎬ基于文法的方法更适合于在线日志解析ꎬ且可以与日志收集同时进行ꎬ基于聚类的方法则通常是在日志收集完毕后离线进行的ꎮ４㊀日志划分分布式系统每天产生大量的日志ꎮ这些日志虽然包含丰富的信息ꎬ但并非所有信息都与应用需求相关ꎮ且由于不同用户请求的日志混杂在一起ꎬ人工分析很难高效的识别出其中有价值的日志特征ꎮ为了更好地服务于日志特征的挖掘与应用ꎬ目前日志分析工作在挖掘日志特征之前ꎬ通常会对日志进行划分ꎬ将属于同一用户或时间段的日志聚集在一起(归入同一日志集合)ꎬ提高后续分析的效率与精度ꎮ４.１㊀基于用户视角划分基于用户视角划分是为了将同一用户请求产生的日志聚集在一起ꎬ这样后续的工作可以针对某个用户某次请求进行具体的分析ꎮ目前基于用户视角的划分方法首先会找到可以代表用户某次请求的变量ꎬ称之为ＩＤ变量ꎬ然后依据变量的值划分日志ꎮＭｙｓｔｅｒｙＭａｃｈｉｎｅ[２８]使用Ｆａｃｅｂｏｏｋ内部的插桩工具为每个用户请求赋予全局唯一的ＩＤꎬ并对已有的日志打印语句进行改写ꎬ使输出的日志总是包含这个ＩＤꎬ这样不仅可以区分不同的用户请求ꎬ又可以将不同分布式系统产生的日志聚集在一起ꎮＳＡＬＳＡ[４３]和Ｔａｎ[４４]基于对ＨＡＤＯＯＰ[１７]系统的理解ꎬ人为指定系统中的哪些变量可以作为区分不同用户请求的ＩＤꎬ并进一步指定哪些类型的日志属于同一个用户请求ꎮ与需要人工辅助的方法不同ꎬＳｔｉｔｃｈ[３２]基于流重构原则(ｆｌｏｗｒｅｃｏｎｓｔｒｕｃｔｉｏｎｐｒｉｎｃｉｐｌｅ)聚集同一用户请求的日志ꎮ流重构原则是指开发者为了能够根据日志重构出用户请求在系统中的执行路径ꎬ会在日志中打印足以区分不同请求㊁不同模块乃至不同执行实例的一系列ＩＤ变量ꎮ比如ꎬ如果能够从日志中识别出这一系列ＩＤ的变量以及它们之间的对应关系ꎬ就可以区分属于不同用户请求的日志ꎬ并将隶属该请求但跨越了不同系统的日志关联起来ꎮ考虑到不同的分布式系统可能使用不同的编程语言书写ꎬ且可能存在外用库源码不可得的情况ꎬ使用以下２条启发式规则筛选ＩＤ变量:(１)排除所有非名词９０３陆㊀杰等:分布式系统中的日志分析及应用。