日志分析的那些挑战计算机的系统日志提供了对运行系统状态的描述。日志的内容和格式在不同的系统之间，甚至在系统中的不同组件之间可能会有很大差异。硬件驱动程序可能会生成指示与硬件通信出现问题的消息，并且Web服务器可能会记录请求了哪些页面以及何时请求了其他服务。因为日志的内容不同，目的也不同。有关硬件的日志可用于故障排除，而Web服务器日志用于研究流量模式以最大化业务收入。事实上，单个日志可用于多种用途：关于不同网络的路由信息??（称为流量）可能有助于用户优化网络性能或检测恶意入侵；或者通话记录可以监控谁打了电话，什么时候打的，通过进一步分析可以揭示整个城市的通话量和掉话率。日志分析是一个丰富的研究领域，但它仍然面临着许多挑战。那么为什么日志分析既重要又困难呢？理解日志的挑战许多日志旨在方便调试。“最有效的调试工具仍然是仔细思考，再加上明智的打印语句。”尽管今天的程序比30年前复杂了四个数量级，但许多人仍然使用printf将输出记录到控制台或本地磁盘。日志，并使用手动检查和正则表达式的某种组合来定位特定消息或模式。调试日志最简单和最常见的用途是对特定消息进行grep。如果您认为程序因网络故障而崩溃，您可能会尝试在服务器日志中查找“连接丢失”消息。在许多情况下，很难确定要搜索的内容，因为日志消息和观察到的症状之间没有明确定义的映射。当Web服务突然变慢时，不太可能看到明显的错误消息，“错误：服务延迟增加了10%，因为第x行的错误被触发。”相反，用户通常会搜索严重性关键字，例如“错误”或“失败”。然而，这样的严重级别通常不会被准确使用，因为开发人员很少完全了解代码最终将如何使用。当开发人员为日志消息编写打印语句时，它会绑定到程序源代码的上下文中。然而，信息的内容通常排除了这种情况。如果不了解print语句周围的代码，或者是什么导致程序进入执行路径，消息的某些语义可能会丢失，即，如果没有上下文，日志消息可能难以理解。另一个挑战是日志文件通常被设计为表示单个事件流。但是，来自多个源的消息可能在运行时（来自多个线程或进程）和静态模块交错。对于运行时交错，线程ID不能解决问题，因为线程可以重复用于独立任务。已努力自动包含消息上下文（例如，X-Trace），或从消息内容中推断它，但这些并没有完全捕捉开发人员的意图和期望。静态交错场景更具挑战性，因为不同的模块可能由不同的开发人员编写。因此，单个日志消息可能有多种解释。例如，“失去连接”对于网络库的作者来说可能非常重要，但对于通过底层抽象来避免错误的应用程序作者来说就不那么重要了。共享库的作者通常不可能预测哪些消息对用户有用。日志记录通常意味着一些内部同步。通过更改线程交错模式和模糊问题，这会使多线程系统的调试复杂化。一个程序只在某些执行点表现出不确定性，比如时钟中断和I/O通过记录所有不确定的执行点，一般需要重新运行整个程序来观察，并且可以在重新运行之前修改一些代码Watch程序中的任何内容。但是，这种方法对于并发程序或确定性执行依赖于大量数据的程序可能不切实际。在大型系统上，日志量可能过多。例如，记录锁对象上的每个获取和释放操作以调试锁争用可能非常昂贵。在多模块系统中，比较困难，因为日志也是异构的，不太适合直接分析。收集、存储、排序或索引大量日志消息存在固有成本，其中许多可能永远不会被使用。调试日志记录的ROI来自其诊断功能，这很难衡量。一些用户想要聚合或统计信息而不是单个消息。在这种情况下，他们只能记录聚合数据或聚合数据的近似值，并且仍然可以很好地估计所需的统计量，近似值为PCA和SVM等机器学习分析提供了有用的工具。这些技术在联网或大规模分布式系统中至关重要，在这些系统中，即使从每个组件收集一个数字也会导致沉重的性能成本。这说明了裁剪工具对特定分析的潜在好处。机器学习技术，尤其是异常检测，通常用于发现有趣的日志消息。机器学习工具通常需要输入数据作为数字特征向量，但将自由文本日志消息转换为有意义的特征并非易事。通常分析源代码，从文本日志中自动提取半结构化数据，并对从日志中提取的特征应用异常检测。统计异常检测仍然面临挑战。即使某些信息在统计上是异常的，也可能没有进一步的证据表明该信息是原因、症状或仅仅是无害的。此外，统计方法严重依赖日志质量，特别是是否记录了“重要”事件，而这些方法本身并没有定义什么是“重要”。静态程序分析可以通过分析程序中可能导致消息的路径来帮助发现特定消息的根本原因。静态分析还可以通过寻找程序执行可能进入错误路径的分叉点来揭示提高日志质量的方法；这些分歧点是日志分析的最佳候选点。目标系统的启发式方法和领域知识通常会使这种分析更加有效。性能日志分析的挑战日志分析可以帮助优化或调试系统性能。了解系统的性能通常与了解系统中的资源是如何使用的有关。有些日志和调试是一样的，比如记录和锁定操作来调试瓶颈。一些日志跟踪单个资源的使用情况，生成时间序列。资源使用统计通常以每个时间段的累积使用量（例如，最近一分钟传输的n个字节）的形式出现，使用带宽数据描述网络或磁盘性能，使用分页描述内存可用性，或CPU利用率描述负载平衡质量。与调试用例一样，性能日志必须在上下文中进行解释。其中，有两个上下文在性能分析中特别有用：性能数字出现的环境和系统的工作负载。性能问题通常是由组件之间的交互引起的，要揭示这些交互，可能需要从多个来源生成的异构日志中综合信息。合成可能是一个挑战。除了异构日志格式之外，分布式系统中的组件可能会在确切的时间上发生分歧，从而无法重建跨多个组件的事件的精确排序。此外，对一个组件无害的事件（例如，将日志刷新到磁盘）可能会对另一个组件造成严重问题（例如，I/O资源争用）。由于有问题的组件不太可能记录事件，因此很难找出这个根本原因。这只是出现的困难的一小部分。解决这个问题的一种方法是计算影响，它通过寻找令人惊讶的、时间相关的行为来推断组件或组件之间的关系。即使这些日志是稀疏的、不完整的、没有已知语义的，即使交互机制未知，也需要量化产生异构日志的组件之间的交互。在系统处理消息或请求时跟踪消息或请求的方法可以说明事件的顺序和工作负载的影响。例如，一种类型的请求可以很容易地使用缓存数据提供服务，而另一种类型的请求则不能。这种跟踪方法通常需要仪器工具来支持它，但除了了解性能之外，它还可以用于正确性调试。这方面的一个突出挑战是测量行为影响测量本身的风险。消耗资源的大量日志记录会使从这些资源开始的任务复杂化。我们测量的越多，就越不能准确了解系统的性能特征。在实践中，即使是保守的跟踪机制也经常引入不可接受的开销。减少日志记录对性能影响的一种方法是采样。危险在于抽样可能会错过罕见的事件。但是，如果您有数百万甚至数亿个采样实例在运行，您可以在捕获罕见事件的同时保持较低的采样率。采样技术的有效实施需要能够在不重新启动执行的情况下打开和关闭各个日志站点。像DTrace这样的遗留系统仍然需要静态检测的日志站点，但是，LogPostprocessing是一个用于收集、处理和分析软件执行跟踪的平台，允许用户指定他们想要测量的事件，以声明性语言表示为查询；然后，该平台将动态插件插入到正在运行的系统中，聚合测量数据，并提供分析机制，所有这些都是为了这些查询。当应用于分布式系统中的基准代码时，此类系统显示出个位数的开销百分比。动态日志记录与基于采样的日志记录相结合可能是解决需要大规模详细日志记录问题的关键方法。安全日志分析挑战日志还用于应用程序的安全分析，例如检测违规或不当行为，以及对安全事件进行事后检查。根据系统和威胁模型，几乎任何类型的日志都可以进行安全分析，例如与防火墙、登录会话、资源利用、系统调用、网络流量等相关的日志。入侵检测通常需要从日志中重建会话。考虑一个与入侵检测相关的示例，即检测对系统的未授权访问。当用户通过SSH远程登录到计算机时，计算机会生成与登录事件对应的日志。在MacOSx上，这些消息表明名为XX的用户从特定IP地址和端口号交互访问了计算机。常识告诉我们注销消息应该与之前的登录消息匹配，但是，有些日志行没有任何语法可以先验地表明它们与登录时生成的代码行有某种关联，更不用说每个其他。换句话说，每条消息都是多个语义事件的证据，包括以下内容：特定代码行的执行、SSH会话的创建或销毁以及整个SSH会话。对安全性感兴趣的日志分析可能会问一个看似简单的问题：这个SSH会话是否构成安全漏洞？答案可能取决于多种因素，包括：最近是否有异常多的失败登录尝试？用户XX的IP地址熟悉吗？XX在会话活动期间是否执行了任何可疑操作？用户名为XX的用户是否在度假，因此不应登录？请注意，使用日志答案中的数据只能识别其中的一些问题。例如，可以查询本次会话之前的大量失败登录尝试，但无法推断出XX的真实身份，更不用说他或她的假期计划了。因此，分析能力受限于日志中的信息。安全日志分析可以基于签名，用户可以在其中尝试检测已知的恶意行为；或基于异常，寻找与典型或良好行为的偏差并将其标记为可疑。签名方法可以可靠地检测与已知签名匹配的攻击，但对不匹配的攻击不敏感。另一方面，异常方法面临着设置调用可疑异常的阈值的困难：太低，错误警报使工具无用；太高，攻击可能未被发现。应用安全也面临着与敌人的斗智斗勇。为了逃避日志分析工具的注意，攻击者会试图让攻击期间生成的日志看起来与正确操作期间生成的日志相同或几乎相同。对于不完整的日志，分析也无能为力。开发人员可以尝试增加日志记录的覆盖范围，这会让对手更难避免留下活动证据，但这并不一定会更容易区分“健康”日志和“可疑”日志。预测性日志分析挑战日志数据可用于预测。预测模型有助于自动化资源供应、容量规划、工作负载管理、调度和配置优化，或提供对数据的洞察。从商业角度来看，预测模型可以指导营销策略、广告投放或库存管理。针对具体系统，建立并完善了一些分析模型。专家手动识别依赖关系和相关指标，量化组件之间的关系，并设计预测策略。这些模型通常用于构建模拟器，重放预期的工作负载扰动或负载量以提出假设问题。有一些使用分析模型对I/O子系统、磁盘阵列、数据库和静态Web服务器进行性能预测的示例。然而，这种方法有一个主要的实际缺点，即真实系统经常变化，分析技术必须跟上这些变化。尽管建模技术在不同系统中可能是通用的，但为构建模型而挖掘的日志数据以及预测指标可能会有所不同。例如，I/O子系统和事件，包括时间戳、事件类型、CPU配置文件和其他用于预测I/O子系统性能的操作系统事件，也可以使用轨道计数、队列长度和其他属性来构建分析模型以预测磁盘阵列吞吐量。许多分析模型是单层的：每个预测变量一个模型。在其他情况下，需要模型层次结构来根据其他性能指标预测单个性能指标。例如，使用包括时间戳、请求类型（GET与POST）、请求的字节数、URI和其他字段的Web服务器跟踪来预测存储响应时间、存储I/O和服务器内存。用于预测不同负载条件下的服务器响应时间的模型可以包括存储量和服务器内存模型。作为另一个示例，访问日志跟踪、块访问、物理磁盘传输、吞吐量和平均响应时间可用于对具有多级队列的网络进行建模，以预测物理和逻辑设计决策对数据库性能的影响。分析模型的一个缺点是它们需要特定于系统的领域知识。这样的模型无法无缝移植到新版本的系统中，更不用说移植到其他系统中了。随着系统变得越来越复杂，人们转向使用历史数据来预测未来工作量和性能的统计模型。回归分析是最简单的预测统计建模技术。它已应用于性能计数器，用于测量执行时间和内存子系统的影响。例如，应用于这些日志的线性回归被用来预测库的数据分区布局在并行处理器上的执行时间。相反，应用逻辑回归模型用于预测一组好的编译器标志。CART使用磁盘请求跟踪，指定到达时间、逻辑块编号、请求的块和读/写类型，以预测存储系统中请求和工作负载的响应时间。简单回归和CART模型都预测每个模型的单个指标。然而，性能指标通常是相互依赖的，必须预测每个指标才能做出明智的调度或配置决策。为了同时预测多个指标，一种方法是采用典型的相关性分析来建立一个模型，捕捉系统输入与性能特征之间的相互依赖关系，并使用该模型来预测系统在任意输入下的性能。1.虽然这些技术展示了统计学习技术在性能预测方面的强大功能，但它们的使用也带来了一些挑战。从事件日志中提取特征向量是影响预测模型有效性的关键步骤。事件日志通常包含非数字数据（例如，分类数据），但统计技术期望数字输入具有定义在数据上的分布概念。将事件中的非数字信息转换为有意义的数字数据可能很乏味，并且需要了解事件代表什么的领域知识。因此，即使给出预测，也很难确定正确的行动方案。预测模型通常提供一系列值而不是单个数字；这个范围有时代表一个置信区间，这意味着真实值很可能位于该区间内。是否根据预测采取行动是一个必须权衡信心与成本的决定，即，根据低置信度的预测采取行动并不一定比什么都不做好。执行可能取决于日志记录粒度是否与决策粒度匹配，例如每个查询资源利用率的日志记录对任务级调度决策没有帮助，因为并行性和较低级别的资源利用率指标没有得到很好的理解。报告生成和配置文件分析的挑战日志分析的另一个用途是分析资源利用率、工作负载或用户行为。记录集群工作负载中任务特征的日志可用于分析大型数据中心的资源利用率。可以利用相同的数据来了解工作负载中作业之间的相互到达时间以及昼夜模式。除了系统管理，它还可以用于业务分析。例如，Web服务器日志描述站点访问者的特征，这可以产生客户统计数据。Web日志分析技术已经从捕捉页面流行趋势的简单统计数据发展到描述跨多个用户会话的访问模式的复杂时间序列方法。该数据为营销活动、内容托管和资源供应提供信息。使用各种统计技术分析和报告日志数据。聚类算法，如k-means和层次聚类组，以获得相似的事件。马尔可夫链用于时间序列必不可少的模式挖掘。许多分析和警报技术需要以专家知识形式提供的提示。例如，K均值聚类算法要求用户指定聚类数(k)或提供用作种子聚类中心的示例事件。其他技术需要合并或分区聚类启发式方法。大多数技术依赖于事件的数学表示，分析结果用类似的术语表示。然后可能需要将这些数学表示映射回来，如果不了解日志语义，这可能会很困难。对日志事件进行分类通常也具有挑战性。例如，要对系统性能进行分类，您可以分析CPU利用率和内存消耗。假设有一个CPU利用率高和内存消耗低的性能配置文件，以及一个CPU利用率低和内存消耗高的单独配置文件；不清楚何时出现低CPU使用率和低内存消耗的事件，它应该属于两个配置文件（或两者）中的哪一个。如果此类事件足够多，最好的选择可能是包含第三个配置文件。对于如何处理跨越多个摘要的事件，或者如何预先创建此类摘要，没有普遍适用的规则。虽然总结可以有效地对类似事件进行分组并提供系统行为的高级视图，但它并不能直接转化为可操作的见解。解释摘要并使用它来做出业务决策、修改系统，甚至修改分析的任务通常落在人类身上。日志记录基础设施挑战日志记录基础设施对于支持各种应用程序至关重要。它至少需要两个特性：日志生成和日志存储。大多数通用日志都是非结构化文本。开发人员使用printf和字符串连接来生成消息，这些原语很容易理解并且无处不在。但是，这种日志记录方法也有缺点。首先，将变量序列化为文本非常昂贵。其次，分析需要解析文本消息，这也可能既复杂又昂贵。在存储方面，基础架构聚合来自各种网络源的消息。Splunk索引来自系统日志和其他来源的非结构化文本日志，并对数据执行实时和历史分析。使用Hadoop存储数据以利用分布式计算基础架构。选择正确的日志存储解决方案需要权衡以下因素：每TB成本（包括前端和维护）总容量持久性保证写访问特性（例如，带宽和延迟）读访问特性（随机访问与顺序扫描）安全考虑（访问控制和合规性）与现有基础设施的集成日志保留没有放之四海而皆准的策略。这使得选择和配置日志记录解决方案成为一项挑战。对商业智能有用的日志通常被认为比调试日志更重要，因此保存时间更长。相比之下，大多数调试日志会尽可能长时间地存储，但不能保证保留，这意味着它们可能会在资源压力下被删除。与警报和报告功能结合使用时，日志存储解决方案会更有用。这样的基础设施可用于调试、安全和其他系统管理任务。各种日志存储解决方案促进了警报和报告功能，但它们留下了许多与警报节流、报告加速和预测功能相关的开放挑战。小结今天的系统管理主要以日志为中心。无论是用于调试问题还是提供资源，日志都包含大量可以精确定位或至少暗示解决方案的信息。尽管日志分析技术取得了长足的进步，但仍然存在一些较大的挑战。首先，随着系统越来越多地包含许多分布式组件，可能很难使用单个日志文件监视系统不同部分的事件。在某些情况下，来自不同系统的日志必须相互关联才能进行分析。交错异构日志很少是直截了当的，尤其是当时间戳不同步或不存在于所有日志中，并且组件之间的语义不一致时。其次，日志记录过程本身需要额外的管理。控制日志的详细程度对于管理开销和促进分析很重要，尤其是在出现峰值或潜在攻击行为的情况下。日志记录机制也不应成为传播恶意活动的渠道。在最大化信息内容的同时最小化检测开销仍然是一个挑战。第三个挑战是，尽管各种分析和统计建模技术可以挖掘大量日志数据，但它们并不总能提供可操作的见解。例如，统计技术可以揭示工作负载中的异常情况或系统的高CPU使用率，但无法解释如何应对。信息的解释是主观的，信息是否可操作取决于许多因素。这是一项重要的调查技术，是效率、准确性和可行性之间的权衡。由于在可预见的未来人类仍将参与解释和处理日志的过程，因此对可视化技术的投资是值得的。静态和动态的程序分析方法有望提高我们自动描述导致特定日志消息序列的交互的能力，使日志更容易进行各种分析或更全面。对如何生成更有用的日志的洞察通常伴随着对如何分析现有日志的洞察，验证日志消息有效性的机制将提高日志质量并使日志分析更有效。随着许多企业越来越依赖于他们的计算机基础设施，这种关系的重要性也在增加。我们已经看到越来越多的工具试图推断系统如何影响用户：延迟如何影响购买决策；点击模式如何描述用户满意度；以及资源调度决策如何改变对这些资源的需求。此外，用户活动可能对系统调试很有用。进一步探索用户行为（工作负载）和系统行为之间的关系可能有助于理解使用什么日志、何时使用以及出于什么目的。更好的日志记录标准和最佳实践将有助于提高日志分析水平。
