《Loghub: A Large Collection of System Log Datasets for AI-driven Log Analytics》论文详细笔记

Loghub 论文详细笔记

标题: Loghub: A Large Collection of System Log Datasets for AI-driven Log Analytics (Loghub：一个用于人工智能驱动的日志分析的大型系统日志数据集集合) [cite: 1]

作者信息:
Jieming Zhu, Shilin He, Pinjia He, Jinyang Liu, Michael R. Lyu [cite: 1]

• 工作单位：香港中文大学（深圳）数据科学学院，香港中文大学计算机科学与工程系 [cite: 1]
  

摘要

• 日志因记录了丰富的运行时信息而在软件系统开发和维护中被广泛采用。 [cite: 1]
• 近年来，软件规模和复杂性的增加导致日志量迅速增长。 [cite: 2]
• 为了高效处理海量日志，研究领域开始关注开发智能和自动化的日志分析技术。 [cite: 3]
• 然而，由于缺乏公共日志数据集和开放的基准测试，只有少数技术在工业界成功部署。 [cite: 4]
• 为填补这一空白并促进更多AI驱动的日志分析研究，作者收集并发布了Loghub，一个大型系统日志数据集集合。 [cite: 5]
• Loghub提供了19个来自各种软件系统的真实世界日志数据集，包括分布式系统、超级计算机、操作系统、移动系统、服务器应用和独立软件。 [cite: 6]
• 论文总结了这些数据集的统计数据，介绍了Loghub数据集的实际使用场景，并展示了在Loghub上的基准测试结果。 [cite: 7]
• 截至论文撰写时，Loghub数据集已被学术界和工业界的数百个组织总共下载约90,000次。 [cite: 8]
• Loghub数据集可在 https://github.com/logpai/loghub 获取。 [cite: 9]

I. 引言 (INTRODUCTION)

• 日志的重要性与挑战:
  • 日志是行业标准做法，用于记录软件运行时信息，帮助开发和运维工程师追踪系统行为并进行事后分析。 [cite: 10]
  • 日志通常是非结构化文本，由代码中的日志语句打印。 [cite: 11]
  • 一条日志消息通常包含时间戳、详细级别和描述事件的自由文本内容。 [cite: 12, 13]
  • 日志记录的丰富信息支持多种分析任务，如异常检测、重复问题识别、使用统计分析和程序验证。 [cite: 14, 15]
  • 随着系统规模和复杂性的增长，日志量也急剧增加（例如，每小时50GB），使得手动日志分析变得耗时耗力。 [cite: 16, 17]
• AI驱动的日志分析:
  • 为了解决海量日志分析的难题，研究人员开始利用人工智能 (AI) 技术实现自动化日志分析。 [cite: 18]
  • AI技术通过提取运行时行为的关键信息，极大地促进了日志分析任务。 [cite: 19]
  • 一个AI驱动的日志分析框架通常包括（如图1所示）： [cite: 20, 32]
    • 开发阶段: 根据从高质量软件库中挖掘出的战略性日志实践（“在哪里记录”和“记录什么”）来指导日志记录决策。 [cite: 20]
    • 运行时阶段: 以流式方式收集和聚合日志。 [cite: 21] 可应用日志压缩技术以降低存储成本。 [cite: 22]
    • 运维阶段: 使用日志解析技术将日志解析为结构化事件，然后进行建模和挖掘以支持各种日志分析任务（如异常检测、问题识别）。 [cite: 23]
• 当前研究的不足:
  • 尽管在AI技术应用于日志记录、收集、压缩、解析和分析方面已有很多努力，但研究与实践之间仍存在巨大差距。 [cite: 24, 25]
  • 研究人员通常使用各自的日志数据，而公司出于隐私考虑不愿公开生产日志，导致公共研究数据稀缺。 [cite: 26, 27] （差分隐私）
  • 一个在某种日志数据上表现良好的方法可能在另一种类型上失效。 [cite: 28]
  • 缺乏标准基准使得研究人员和从业者难以实现方法并准确复现结果。 [cite: 29]
• Loghub的提出与贡献:
  • 为了弥合研究与实践之间的差距，本文提出了Loghub，一个用于AI驱动日志分析的大型系统日志数据集集合。 [cite: 30]
    
  • 主要贡献:
    • 收集并组织了一个包含19个数据集的大型日志集合 (Loghub)，这些数据集来自多种系统，对AI驱动的日志分析研究和实践具有重要价值。 [cite: 36, 37]
      • Among these log datasets, six of them are labeled (e.g., normal or abnormal, alerts or not alerts), which are amendable to studies for anomaly detection and duplicate issues identification.
      • 这六个数据集被标记了
    • 介绍了Loghub数据集的实际使用场景，并提供了在三个典型日志分析任务（Log parsing (日志解析)、Log compression (日志压缩)、Log-based anomaly detection (基于日志的异常检测)）上的基准测试结果，讨论了尚存的问题和挑战，为未来研究指明了方向。 [cite: 38, 39]
    • Loghub数据集已在Github上公开，并已对社区产生可衡量的影响，惠及超过450个来自工业界和学术界的组织。 [cite: 40, 41]

II. Loghub 数据集 (LOGHUB DATASETS)

• 总体情况:
  • Loghub维护一个可供研究免费访问的系统日志集合。 [cite: 42]
  • 部分日志是先前研究发布的生产数据，部分是在实验室环境中从真实系统收集的。 [cite: 43]
  • 尽可能保持日志的原始性，未进行清理、匿名化或修改。 [cite: 44]
  • 所有日志总大小约77GB。 [cite: 31, 45]
• 数据集统计信息 (见Table I): [cite: 46, 69, 70]
  • 表格列出了数据集的描述、时间跨度、行数、数据大小和标签信息。 [cite: 46]
  • 时间跨度指日志收集的时间范围。 [cite: 70]
  • 行数表示数据集中日志行的总数。 [cite: 48]
  • 数据大小显示未压缩的日志量大小。 [cite: 48]
  • “Labeled”列指示数据集是否带有异常信息标签。 [cite: 49]（具体如上介绍）
• 数据集分类:
  • 分为两类：已标记 (labeled) 和未标记 (unlabeled)。 [cite: 50]
  • 已标记数据集包含针对特定日志分析任务（如异常检测和重复问题识别）的标签。 [cite: 51] 例如，在已标记的HDFS数据集中，标签指示HDFS块上的系统操作是否异常。 [cite: 52, 53]
  • Loghub中有6个已标记数据集和13个未标记数据集。 [cite: 54]
  • 未标记数据集对于评估日志解析、日志压缩和无监督异常检测方法也很有用。 [cite: 55]
• 各类数据集详细介绍:
  • A. 分布式系统 (Distributed Systems):
    • HDFS: Hadoop分布式文件系统。 [cite: 57] 提供了三个HDFS日志集：HDFS-v1, HDFS-v2, HDFS-v3。 [cite: 59]
      • HDFS-v1: **在一个203节点的HDFS上使用基准工作负载生成，**通过手工规则手动标记异常。 [cite: 60] 日志根据块ID切分为轨迹，每个轨迹标记为正常或异常，并提供特定异常类型信息。 [cite: 61, 62, 63]
      • HDFS-v2: 从实验室环境（1个namenode和32个datanode）的HDFS集群收集并聚合的日志，数据量大（超过16GB），未做修改或标记。 [cite: 64, 65]
      • HDFS-v3: 来自跟踪导向监控的开放数据集，通过在真实IaaS环境中使用MTracer检测HDFS系统收集，包含正常和故障注入的异常日志。 [cite: 66, 67, 68]
    • Hadoop: 大数据处理框架。 [cite: 71] 日志从一个包含5台机器（46核）的Hadoop集群生成，运行WordCount和PageRank应用。 [cite: 73, 74] 通过注入机器宕机、网络断开和磁盘满等故障来模拟服务故障，并提供了不同故障的标签。 [cite: 75, 76, 77, 78]
    • Spark: 统一的分析引擎。 [cite: 79] 从实验室环境（共32台机器）运行的Spark系统收集并聚合的日志，数据量大（超过2GB），未做修改或标记，包含正常和异常应用运行。 [cite: 80, 81]
    • Zookeeper: 集中式服务，用于维护配置信息、命名、提供分布式同步等。 [cite: 82] 从实验室环境（共32台机器）的ZooKeeper服务收集并聚合的日志，时间跨度26.7天。 [cite: 83, 84]
    • OpenStack: 云操作系统。 [cite: 85] 数据集由[15]提供，在CloudLab上生成，包含正常日志和故障注入的异常案例，适用于异常检测研究。 [cite: 86, 87]
  • B. 超级计算机 (Supercomputers):
    • BGL: 从劳伦斯利弗莫尔国家实验室的BlueGene/L超级计算机系统收集的开放数据集。 [cite: 88] 日志包含通过警报类别标签识别的警报和非警报消息。 [cite: 89, 90, 91]
    • HPC: 来自[48]的开放数据集，从洛斯阿拉莫斯国家实验室的高性能计算集群的System 20收集。 [cite: 92]
    • Thunderbird: 由[55]提供的开放数据集，从桑迪亚国家实验室的Thunderbird超级计算机系统收集。 [cite: 93] 日志包含通过警报类别标签识别的警报和非警报消息。 [cite: 94, 95, 96]
  • C. 操作系统 (Operating Systems):
    • Windows: 从运行Windows 7的实验室计算机聚合的日志，主要来自C:/Windows/Logs/CBS (基于组件的服务)。 [cite: 97, 98] 日志量大（超过27GB），时间跨度226.7天。 [cite: 101]
    • Linux: 从Linux服务器上的/var/log/messages收集，时间跨度263.9天，作为公共安全日志共享站点项目的一部分。 [cite: 102]
    • Mac: 从个人Macbook上的/var/log/system.log收集，使用7天后的日志。 [cite: 103]
  • D. 移动应用 (Mobile Applications): (原文为Mobile Applications，但表格中归类在Mobile systems下)
    • Android: 流行的开源移动操作系统。 [cite: 105] 提供了在安装了大量检测模块的Android智能手机上收集的Android日志文件。 [cite: 107] 提供了两个由应用框架打印的Android日志数据集版本：Android-v1和Android-v2。 [cite: 109] Android-v1是Android-v2的一个采样小日志文件，Android-v2包含两种类型的问题，每种类型有超过10个重复问题日志。 [cite: 110]
    • HealthApp: 安卓设备的移动应用。 [cite: 112] 从一部安卓智能手机使用超过10天后收集的应用日志。 [cite: 112]
  • E. 服务器应用 (Server Applications):
    • Apache: Apache HTTP服务器，最流行的Web服务器之一。 [cite: 113] 提供了一个错误日志，用于异常检测和诊断研究。 [cite: 115] 日志文件从运行Apache Web服务器的Linux系统收集，作为公共安全日志共享站点项目的一部分。 [cite: 116]
    • OpenSSH: 用于SSH协议远程登录的主要连接工具。 [cite: 117] 从实验室的OpenSSH服务器收集，时间跨度28天。 [cite: 118]
  • F. 独立软件 (Standalone Software):
    • Proxifier: 允许不支持通过代理服务器工作的网络应用通过SOCKS或HTTPS代理及链进行操作的软件程序。 [cite: 119] 从实验室的台式计算机收集的Proxifier日志。 [cite: 120]
      

III. Loghub 数据集的使用 (USAGE OF LOGHUB DATASETS)

• 概述和行业采用情况:
  
  • Loghub数据集已发布五年。 [cite: 122]
  • 通过Zenodo进行的调查收集了关于数据集下载请求的组织和使用场景信息。 [cite: 123]
  • 吸引了IBM、微软、华为、英伟达等大公司以及Elastic.co、Splunk等初创公司的关注。 [cite: 124]
  • 许多大学也请求了Loghub数据集。 [cite: 125]
  • 迄今为止，Loghub已被超过450个组织下载超过90,000次，其中35%来自工业界，65%来自学术界。 [cite: 34, 126]
  • 对收集到的数据请求信息进行分析后，手动分类了日志使用场景，并将其分布展示在图2中。 [cite: 127, 134]
  • Loghub数据集可促进23种不同类别的研究和教育目的。 [cite: 129]
  • 前5大使用场景是：异常检测、日志分析、安全、日志解析和教育。 [cite: 130]
  • “日志分析”可能涵盖其他一些日志相关任务，但用户未明确说明。 [cite: 131]
  • “教育”指课程项目和论文项目的使用案例。 [cite: 132]
• 常见的日志分析任务:
  • B. 日志解析 (Log Parsing):
    • 大多数基于AI的日志分析方法需要结构化输入数据。 [cite: 135]
    • 软件日志通常是非结构化文本，包含多个字段和开发人员编写的自然语言描述。 [cite: 136]
    • 日志解析是将非结构化日志消息转换为结构化系统事件的关键步骤。 [cite: 137]
    • 传统依赖手动构建解析规则的方法因日志量激增而变得低效。 [cite: 138]
    • 近期研究提出了各种数据驱动的日志解析器，自动为非结构化日志消息标记相应的系统事件ID。 [cite: 139]
    • 日志解析通常被建模为一个聚类问题，将描述相同系统事件的日志消息聚类到同一组。 [cite: 140]
    • 评估日志解析方法的准确性和效率需要：(1) 大量日志；(2) 由多种系统生成的日志。 [cite: 145]
    • Loghub包含19个来自6类系统的数据集，总大小超过77GB，可用于评估不同日志解析方法的解析准确性和效率。 [cite: 146, 147]
  • C. 日志压缩 (Log Compression):
    • 日志通常需要长时间存储以用于各种系统维护任务。 [cite: 148]
    • 日志大小的爆炸式增长导致存档系统日志消耗大量存储空间和电力成本。 [cite: 149]
    • 通用压缩方法在日志压缩上效果不佳，因为它们未考虑日志消息的固有结构。 [cite: 150]
    • 为实现更高压缩率，新的研究方向提出了专门针对日志数据的压缩方法。 [cite: 151]
    • 日志压缩可被建模为一个频繁模式挖掘问题。 [cite: 152]
    • 研究问题是如何实现高效无损且压缩率高的压缩。 [cite: 155]
    • 与日志解析器评估类似，评估日志压缩方法也需要大量且多样的日志。 [cite: 156]
    • Loghub中的所有数据集均可用于评估日志压缩方法。 [cite: 157]
  • D. 异常检测 (Anomaly Detection):
    • 现代系统规模大、结构复杂，许多系统需要7x24小时运行。 [cite: 158, 159] 任何严重的停机都可能导致巨大的收入损失。 [cite: 160]
    • 为增强系统可靠性，近期研究集中于基于日志的异常检测方法，通过分析系统运行时日志报告潜在的异常系统行为。 [cite: 161]
    • 异常检测问题通常被建模为一个二分类问题。 [cite: 162] 输入是结构化系统事件列表或矩阵，输出是指示实例是否异常的标签列表。 [cite: 163]
    • 主要有两类基于日志的异常检测方法：无监督和有监督。 [cite: 164]
    • 研究问题是如何基于系统日志准确检测异常。 [cite: 165] F-measure (F1分数) 是常用的评估指标。 [cite: 166]
    • 评估异常检测方法的准确性需要包含实例异常标签的日志数据集。 [cite: 167]
    • Loghub包含6个已标记的日志数据集，可用于评估各种异常检测方法的准确性。 [cite: 168]
  • E. 重复问题识别 (Duplicate Issues Identification):
    • 为提高系统可靠性，开发人员的一项重要任务是高效处理用户报告的操作问题。 [cite: 169]
    • 为辅助问题处理过程，近期研究提出了重复问题识别技术，以减少不必要的人工劳动。 [cite: 173]
    • 重复问题识别问题可以被建模为一个聚类问题，根据相应的日志消息将重复问题聚类到同一组。 [cite: 174]
    • 研究问题是如何准确地将不同问题的日志消息（即日志序列）分离到不同的簇中。 [cite: 176]
    • 评估基于日志的重复问题识别方法的准确性需要包含问题类别的日志数据集。 [cite: 179]
    • Loghub包含3个提供此类信息的已标记日志数据集（HDFS-v1, Hadoop, Android-v2），可用于此任务。 [cite: 180, 181]

IV. Loghub 数据集的基准测试 (BENCHMARKING ON LOGHUB DATASETS)

• 本节通过对典型日志分析任务（日志解析、日志压缩和基于日志的异常检测）进行基准测试，展示Loghub数据集的用法。 [cite: 181]
• 从基准测试结果中，推导出每个任务固有的关键未解决问题和挑战。 [cite: 182]

A. 日志解析基准测试 (Benchmarking for Log Parsing) [cite: 184]

这部分内容主要包括三个方面：

1. 现有日志解析算法 (Existing Log Parsing Algorithms) [p6, p7]
2. 在 Loghub 上进行基准测试 (Benchmarking on Loghub) [p7]
3. 遗留问题与挑战 (Remaining Questions and Challenges) [p7]

1. 现有日志解析算法 [p6, p7]

论文首先回顾了现有的日志解析算法，并将它们分为四类（如表 II 所示）[p6]：

• 基于频繁模式的方法 (Frequent pattern-based methods)：
  • 代表算法：SLCT [p6], LFA [p6], LogCluster [p6]。
  • 工作原理：这些方法通常需要完整的日志数据集进行离线处理。它们首先识别出日志中的频繁模式（例如，频繁出现的词元或词元位置对），然后基于这些模式将日志消息分组到不同的集群中。最后，从每个集群中提取出事件模板。
• 基于聚类的方法 (Clustering-based methods)：
  • 代表算法：LKE [p6], LogSig [p6], SHISO [p6], LenMa [p6], LogMine [p6]。
  • 工作原理：这类方法依赖于核心的聚类算法（如层次聚类）将日志消息分组，然后为每个集群提取模板。其中，SHISO 和 LenMa 支持在线模式，可以逐条处理日志消息而无需预先加载整个数据集。
• 基于启发式的方法 (Heuristics-based methods)：
  • 代表算法：AEL [p7], IPLoM [p7], Drain [p7]。
  • 工作原理：
    • AEL：通过检查静态和可变词元的频率来对日志消息进行分组。
    • IPLoM：使用基于长度、词元位置和映射连接的逐步划分方法来对消息进行分组。
    • Drain：使用固定深度的树模型来展示日志消息并快速提取通用模式。这类方法通常能有效利用日志特征，并产生较好的结果。
• 其他方法 (Others)：
  • 代表算法：Spell [p7], MoLFI [p7]。
  • 工作原理：
    • Spell：应用基于最长公共子序列的算法进行连续的日志解析。
    • MoLFI：将日志解析构建为一个多目标优化问题，并通过进化算法来解决。

评估了13种算法，可分为基于频繁模式、基于聚类、基于启发式和其他方法。 [cite: 185]

2. 在 Loghub 上进行基准测试 [p7]

为了评估不同日志解析算法的准确性，论文定义了一个名为解析准确率 (Parsing Accuracy, PA) 的指标：
PA = (正确解析的日志数量) / (日志总数量) [p7]

一条日志消息被认为是正确解析的，当且仅当其解析出的事件模板与基准事实（ground truth）中该日志消息所属的模板一致。例如，如果一个日志序列 [E1, E2, E2] 被错误地解析为 [E1, E4, E5]，那么其 PA 就是 1/3。

论文使用 Loghub 中的数据集对表 II 中列出的日志解析算法进行了基准测试，实验结果展示在表 III 中。从表 III 可以总结出以下观察结果：

• 观察点 1 (Over 90% accuracy…): 在大多数数据集上，至少有一个日志解析器能够达到 90% 以上的准确率。在13个解析器中，有8个在至少两个数据集上表现最佳。由于 HDFS 和 Apache 数据集的事件模板相对简单，一些解析器甚至可以在这些数据集上达到100%的准确率。 [p7]
• 观察点 2 (Despite these successes…): 尽管取得了这些成功，但像 OpenStack、Linux、Mac 和 HealthApp 这样具有复杂结构和大量事件模板（例如 Mac 日志中有341个模板）的日志类型仍然带来了挑战。这表明在解析这些复杂日志数据方面仍有改进空间。 [p7]
• 观察点 3 (Regarding the overall effectiveness…): 就日志解析器的整体有效性而言，Drain 在不同数据集上的平均准确率最高，在16个数据集中有9个表现出高精度。IPLoM、AEL 和 Spell 也表现良好，在6个数据集上保持了高准确率。相反，LogSig、LFA、MoLFI 和 LKE 的平均准确率最低。 [p7]

3. 遗留问题与挑战 [p7]

基于基准测试的结果，论文总结了日志解析领域仍然存在的几个问题和挑战：

• 问题 1 (No single log parser…): 目前没有单一的日志解析器能够有效处理所有类型的日志数据集。这需要开发一种更通用的日志解析算法，能够处理各种不同类型的日志数据。 [p7]
• 问题 2 (Dealing with complex datasets…): 处理包含大量模板的复杂数据集对大多数现有方法来说是一个重大挑战。一个实用的日志解析器应该具备准确处理这类日志的能力。 [p7]
• 问题 3 (Existing log parsers can only differentiate…): 现有的日志解析器只能区分日志模板和日志参数。如果能够将日志参数（如状态码、块ID等）分类为更细粒度的类型，将有助于现场工程师的诊断过程。 [p7]
• 问题 4 (The majority of log parsers rely on identifying…): 大多数日志解析器依赖于识别频繁模式来确定模板。然而，在实际场景中，日志消息的出现分布可能是多样的，这会导致在某些日志消息出现次数较少的情况下，解析准确率下降。 [p7]

总的来说，“Benchmarking for Log Parsing” 这一部分通过对多种现有日志解析算法在 Loghub 数据集上进行系统的评估，展示了它们的性能表现，并指出了该领域未来研究的方向和亟待解决的挑战。

进一步的基准测试细节：

Loghub上的基准测试 (见Table III) [cite: 193, 205]

• 定义解析准确度 (PA) 为正确解析的日志数与总日志数的比率。 [cite: 202]
  
• 观察结果:
  • 大多数数据集上至少有一个日志解析器实现了超过90%的准确率，其中8个解析器在至少两个数据集上表现最佳。 [cite: 207] 一些解析器甚至能在HDFS和Apache数据集上达到100%的准确率。 [cite: 208]
  • 复杂日志类型（如OpenStack, Linux, Mac, HealthApp）由于其复杂的结构和大量的事件模板（如Mac日志有341个模板）仍然具有挑战性。 [cite: 209]
  • 就整体有效性而言，Drain在不同数据集上的平均准确率最高。 [cite: 211] IPLOM, AEL和Spell也表现良好。 [cite: 212] LogSig, LFA, MoLFI和LKE的平均准确率最低。 [cite: 213]

待解决的问题和挑战:

• 没有单一的日志解析器能够有效处理所有类型的数据集，需要开发更通用的算法。 [cite: 214, 215]
• 处理包含大量模板的复杂数据集对大多数现有方法来说是一个重大挑战。 [cite: 216, 217]
• 现有日志解析器只能区分日志模板和日志参数，如果能将参数分类为更细粒度的类型（如状态码、块ID），可能会增强诊断过程。 [cite: 218, 219]
• 大多数日志解析器依赖于识别频繁模式来确定模板，但在实际场景中，日志消息出现分布可能多样，导致某些日志消息仅出现几次，从而降低解析准确性。 [cite: 220, 221]

B. 日志压缩基准测试 (Benchmarking for Log Compression) [cite: 225]

现有日志压缩算法:

• 评估了6种压缩工具，包括针对日志的压缩工具 (Cowic, LogArchive, Logzip) 和通用压缩工具 (gzip, bzip2, lzma)。 [cite: 229] Logzip需要与通用压缩工具（称为Logzip的压缩内核）结合使用。 [cite: 230]

Loghub上的基准测试 (见Table IV) [cite: 223, 237]

• 使用压缩率 (CR) 作为评估指标，CR = 原始文件大小 / 压缩后文件大小。 [cite: 235]

• 观察结果:
  • 在通用压缩工具中，lzma在大多数数据集上最有效，其次是bzip2，gzip表现最差。 [cite: 238]
  • 专门为日志数据设计的LogArchive和Cowic表现各异。LogArchive的CR高于gzip，但不如bzip2和lzma。Cowic性能比gzip差，因为它优先考虑快速查询而非高CR。 [cite: 224, 239, 240]
  • 配备不同压缩内核的Logzip优于这些方法，其压缩大小取决于内核的有效性。 [cite: 227] 它在所有五个数据集上都实现了更高的CR，平均CR比gzip高4.56倍，最高可达15.1倍。 [cite: 228]

待解决的问题和挑战:

• 针对日志的压缩工具的有效性受目标日志数据中模板数量的影响，不同数据集的CR差异很大。 [cite: 241, 242]
• 当前的针对日志的压缩工具主要关注优化CR，通常以牺牲搜索效率为代价。 [cite: 244] 同时实现高CR和强大的搜索效率仍然是一个悬而未决的问题。 [cite: 246]
• 现有压缩工具的资源消耗仍未得到充分研究，实际部署中可能需要在计算能力或内存有限的节点上运行，算法必须足够轻量级。 [cite: 247, 248, 249]

C. 异常检测基准测试 (Benchmarking for Anomaly Detection) [cite: 250]

现有基于日志的异常检测方法 (见Table V) [cite: 251, 253, 254]

• 评估了9种方法，主要分为有监督和无监督两类。 [cite: 251]

• 有监督方法 (Decision Tree, SVM, LR) 需要带标签的训练数据。 [cite: 255]
• 无监督方法基于不同技术，如分类 (One-Class SVM)、隔离 (Isolation Forest)、降维 (PCA)、执行流挖掘 (Invariant Mining) 和聚类 (LOF, Clustering)。 [cite: 258]

Loghub上的基准测试 (HDFS数据集, 见Figure 3, Figure 4) [cite: 262, 263, 267]

• 使用精确率、召回率和F1分数作为评估指标。 [cite: 262] 输入是块ID-事件计数矩阵。 [cite: 265]

• 观察结果:
  • 决策树获得了最高的召回率 (0.99)、F1分数 (0.99) 和第二高的精确率 (0.99)。 [cite: 267]
  • 有监督方法取得了更好的结果，因为它们在标记数据上进行训练。 [cite: 268]
  • 在无监督方法中，Invariants Mining方法准确性最高。 [cite: 270] Clustering获得了比Invariants Mining更高的精确率 (1.00)，但其召回率 (0.72) 要低得多。 [cite: 271] One-Class SVM虽然精确率高 (0.99)，但召回率过低 (0.22)。 [cite: 272]

待解决的问题和挑战:

• 无监督方法的准确性不如有监督方法，因此迫切需要准确的无监督异常检测方法。 [cite: 277, 278]
• 在实践中，异常数量远少于正常实例，这使得有监督方法无效。如何设计不需要历史异常实例的异常检测方法仍然是一个重要且具有挑战性的问题。 [cite: 279, 280, 281, 282]
• 当前的异常检测方法都是基于日志序列的，对开发人员进行进一步诊断（如根本原因分析）的帮助有限。 [cite: 283]
• 大多数现有方法只会报告实例是否异常，而没有其他信息，缺乏帮助开发人员理解已报告异常的可视化工具。 [cite: 284, 285]
• 现有方法主要关注提高异常检测的准确性，但实际解决方案应足够高效以在运行时处理大量日志数据。 [cite: 286, 287]
• 在现实世界场景中，日志数据会随着软件开发而演变**（概念漂移）**，这对现有方法维持满意性能构成了挑战。 [cite: 288, 289]

V. 相关工作 (RELATED WORK)

• 日志实践 (Logging Practice): 缺乏关于开发人员日志记录行为的严格指南和规范。 [cite: 290] 近期的一些实证研究侧重于研究高质量软件的日志记录实践。 [cite: 291] AI辅助的日志记录决策（“在哪里记录”和“记录什么”）也得到了广泛研究。 [cite: 292]
• 日志压缩 (Log Compression): 与通用自然语言文本不同，软件日志具有特定的固有结构。 [cite: 297] 因此，为实现更好的压缩率，专门针对日志文件的压缩方法得到了很好的研究。 [cite: 298] Logzip通过日志解析技术提取冗余日志模板，改进了gzip等现有压缩工具。 [cite: 300] Loghub中的所有数据集都可以促进日志压缩方法的评估。 [cite: 304]
• 日志解析 (Log Parsing): 大多数自动化且有效的日志分析技术需要结构化数据作为输入。 [cite: 305] 因此，日志解析在AI驱动的日志分析中至关重要。 [cite: 306] 近年来，基于各种技术的日志解析器被提出，包括基于频繁模式挖掘、聚类、启发式规则和深度学习等。 [cite: 307, 308, 309, 310, 311, 313] Loghub中的所有数据集都可用于评估日志解析方法。 [cite: 314]
• 日志分析 (Log Analysis): 日志分析已被研究数十年，以促进有效和高效的系统维护。 [cite: 315] 典型的日志分析任务包括异常检测、重复问题识别、事件诊断、使用统计分析和程序验证，其中大多数设计或采用了AI算法。 [cite: 316] Loghub中的5个已标记数据集可用于评估各种日志分析方法。 [cite: 320]

VI. 结论和未来工作 (CONCLUSION AND FUTURE WORK)

• 本文描述了Loghub，一个用于AI驱动日志分析的大型日志数据集集合。 [cite: 321]
• Loghub包含19个日志数据集，总大小超过77GB。 [cite: 322]
• 论文展示了常见的使用场景以及针对日志解析、日志压缩和基于日志的异常检测等典型日志分析任务的基准测试结果。 [cite: 323]
• 基于这些基准测试结果，讨论了开放性挑战和未来方向。 [cite: 324]
• 作者展望Loghub能成为AI驱动日志分析的开放基准测试系统，惠及学术界和工业界的研究人员和从业者。 [cite: 325]
• 未来工作计划包括收集更多大规模、更丰富的日志数据集，并基于Loghub构建一个基准测试排行榜以评估日志分析模型和任务。 [cite: 326, 327]

VII. 致谢 (ACKNOWLEDGEMENT)

• 本研究得到了中国香港特别行政区研究资助局的资助（项目编号：CUHK 14206921，优配研究金）。 [cite: 328]

图表和表格引用说明

• Figure 1: AI驱动的日志分析框架图。 [cite: 32]
• Figure 2: Loghub行业采用情况摘要（不同日志用途百分比）。 [cite: 134]
• Figure 3: 有监督异常检测方法准确性图。 [cite: 252]
• Figure 4: 无监督异常检测方法准确性图。
• Table I: Loghub数据集摘要表。 [cite: 69, 70]
• Table II: 日志解析工具摘要表。 [cite: 177, 178]
• Table III: 现有日志解析方法准确性表。 [cite: 192, 193]
• Table IV: 现有日志压缩方法压缩效果表。 [cite: 222, 223]
• Table V: 基于日志的异常检测方法摘要表。 [cite: 253, 254]

附录：Loghub 数据集中的异常信息与概念漂移

本附录总结了 Loghub 数据集中异常信息的表示或定义方式，并增加了关于概念漂移的说明。至关重要的是，请查阅 logpai/loghub GitHub 仓库 (https://github.com/logpai/loghub) 中每个特定数据集目录下的 README 文件，以获取最准确和详细的信息，包括数据格式、标签文件结构和收集方法。

数据集分为“标记数据集”（提供明确的异常信息）和“未标记数据集”（缺乏预定义的异常标签，但可能包含自然发生的异常）。

I. 标记数据集

这些数据集包含异常事件或时段的明确标签或指示。它们对于有监督的异常检测研究特别有用。

1. HDFS_v1

   • 异常定义：通过人工制定的规则来识别异常。日志数据根据 block_ID 被切分为序列（traces）。每个序列随后被标记为 Normal (正常) 或 Abnormal (异常)。
   • 异常类型信息：该数据集提供有关异常类型的特定信息，通常与HDFS块操作（例如，写入失败、复制问题）相关。
   • 标签存储：通常会提供一个 anomaly_label.csv 文件，该文件将每个 BlockId 映射到其对应的标签 (Normal/Abnormal) 以及可能的异常类型。
   • GitHub 参考：请检查 logpai/loghub/HDFS_v1/anomaly_label.csv 及相关的 README 文件。

2. HDFS_v3 (也称为 TraceBench)

   • 异常定义：异常是在特定 HDFS 操作（被捕获为跟踪）期间通过故障注入生成的。
   • 异常类型信息：异常的类型直接对应于注入的故障场景（例如，模拟影响特定HDFS操作的网络故障、磁盘错误、节点崩溃）。
   • 标签存储：数据集通常由独立的跟踪日志集合组成：一部分来自正常操作，另一部分则是在特定故障注入场景下捕获的。
   • GitHub/外部参考：有关故障场景的详细信息，请参阅 logpai/loghub/TraceBench/ 和 TraceBench 项目网站 (https://mtracer.github.io/TraceBench/)。

3. Hadoop

   • 异常定义：通过在Hadoop集群中注入特定的部署级故障来引入异常。
   • 异常类型信息：论文中明确提到了三种注入的故障类型：
     1. 机器宕机 (machine down)：模拟服务器故障。
     2. 网络断开 (network disconnection)：模拟网络连接丢失。
     3. 磁盘写满 (disk full)：模拟存储耗尽。
        日志将与这些特定的故障条件相关联。
   • 标签存储：在这些故障场景期间收集的日志数据被视为异常。标签直接关联到这些预定义的故障类型。
   • GitHub 参考：logpai/loghub/Hadoop/ 中的 README 文件应提供有关这些故障注入日志如何组织或识别的上下文信息。

4. OpenStack

   • 异常定义：异常是通过在 CloudLab 上运行的 OpenStack 环境中进行故障注入产生的。
   • 异常类型信息：异常类型与注入的具体故障相关。虽然在您提供的文本中未详细说明，但这些通常涉及 OpenStack 中的计算节点故障、存储服务问题、网络组件故障或控制平面服务故障。
   • 标签存储：数据集将包含来自正常操作的日志和在注入故障期间捕获的日志。
   • GitHub 参考：logpai/loghub/OpenStack/ 中的 README 文件对于理解注入故障的性质至关重要。

5. BGL (BlueGene/L)

   • 异常定义：日志消息根据系统自身生成的“告警类别标签 (alert category tags)”被识别为异常。
   • 异常类型信息：每条日志消息的第一列充当标签。连字符 (-) 通常表示非告警（正常）消息，而其他字符或代码则表示不同类别的告警，指向潜在的硬件或软件问题。
   • 标签存储：直接嵌入在日志文件中，作为每行的第一个字段。
   • GitHub 参考：请检查 logpai/loghub/BGL/ 中的 README 文件以获取日志格式详细信息和告警类别解释（如果提供）。

6. Thunderbird

   • 异常定义：与 BGL 类似，异常是通过 Thunderbird 超级计算机系统生成的“告警类别标签 (alert category tags)”来识别的。
   • 异常类型信息：每个日志条目的第一列用作告警标签。连字符 (-) 通常表示正常消息，而其他特定代码或字符表示各种类型的系统检测到的告警或异常。
   • 标签存储：直接嵌入在日志文件中，作为每行的第一个字段。
   • GitHub 参考：有关日志格式和告警标签的具体信息，请参阅 logpai/loghub/Thunderbird/ 中的 README 文件。

II. 未标记数据集

这些数据集不附带预定义的异常标签。它们代表了系统在自然运行期间收集的日志。虽然它们可能包含真实的、未标记的异常，但识别它们通常需要无监督学习技术或领域专业知识。它们对于基准测试日志解析器、压缩工具，或作为异常检测系统“正常”行为的来源也很有价值。

• HDFS_v2：来自一个33节点HDFS集群的聚合日志。可能包含自然发生的（未标记的）操作异常。
• Spark：来自一个32台机器的Spark系统的聚合日志，包括“正常和异常的应用程序运行”，但没有为异常情况提供明确的、细粒度的标签。
• Zookeeper：从Zookeeper服务收集的日志。
• Windows：来自Windows 7计算机的基于组件的服务 (CBS) 日志 (C:/Windows/Logs/CBS)。
• Linux：从Linux服务器收集的系统日志 (/var/log/messages)。
• Mac：从个人Macbook收集的系统日志 (/var/log/system.log)。
• Android_v1 & Android_v2：
  • Android_v1：Android_v2的一个较小的采样版本。
  • Android_v2：包含与两种不同类型的“问题 (issues)”相关的日志，每种问题都有多个重复实例。论文指出，由于Android的复杂性，很难精确定位异常的日志行。因此，虽然可以识别“有问题的”序列（对重复问题识别有用），但它缺乏精确的、行级别的异常标签。
• HealthApp：来自在Android设备上运行的移动健康应用的应用程序日志。
• Apache：来自Apache HTTP Web服务器的错误日志。
• OpenSSH：从OpenSSH服务器收集的日志。
• Proxifier：来自Proxifier软件程序的日志。

III. 关于概念漂移 (Concept Drift)

• 定义：在日志分析的上下文中，概念漂移指的是系统行为和日志模式随时间发生变化。这种变化可能由多种因素引起，例如软件更新、配置更改、工作负载演变、新出现的故障模式或外部环境的变化。其核心是日志数据底层统计特性的非平稳性。
• 对日志分析的影响：概念漂移对基于历史数据训练的日志分析模型（如日志解析器、异常检测器）构成了重大挑战。当新的日志模式出现或旧模式的含义发生改变时，模型的性能可能会显著下降，因为它们所学习到的知识可能不再适用。例如，Loghub论文中提到：“在现实世界场景中，日志数据会随着软件开发而演变（概念漂移），这对现有方法维持满意性能构成了挑战。” [cite: 288, 289]
• Loghub 数据集与概念漂移：
  • 虽然 Loghub 数据集没有明确标记出概念漂移的发生点或类型，但许多跨度较长的数据集（例如 Windows、Linux、Zookeeper、HDFS_v2 等）很可能内含概念漂移的实例。这些数据集收集了系统在较长时间内的行为，期间可能经历了各种更新和变化。
  • 因此，这些数据集对于研究和开发能够适应概念漂移的日志分析方法（例如，在线学习、增量学习、漂移检测与自适应模型）具有重要价值。
• 研究者的考量：使用 Loghub 数据集（尤其是时间跨度较长的数据集）进行模型训练和评估的研究者，应意识到潜在概念漂移的存在及其对结果可能产生的影响。在设计实验和解读结果时，考虑模型的鲁棒性和自适应能力是重要的。