2011年12月20日
第9卷，第12期

日志分析的进展与挑战

日志包含大量信息，有助于管理系统。

Adam Oliner，加州大学伯克利分校；Archana Ganapathi，Splunk；Wei Xu，Google

计算机系统日志提供了运行系统状态的概览。仪器仪表偶尔会生成简短的消息，这些消息被收集在特定于系统的日志中。日志的内容和格式可能因系统而异，甚至在系统内的组件之间也可能不同。打印机驱动程序可能会生成消息，指示其与打印机通信时遇到问题，而 Web 服务器可能会记录请求了哪些页面以及何时请求的。

日志的内容各不相同，其用途也各不相同。打印机日志可能用于故障排除，而 Web 服务器日志用于研究流量模式以最大化广告收入。实际上，单个日志可能用于多种目的：有关沿不同网络路径（称为流）的流量信息可能有助于用户优化网络性能或检测恶意入侵；或者，呼叫详细记录可以监控谁在何时呼叫了谁，并且在进一步分析后可以揭示整个城市的呼叫量和掉线率。

本文概述了日志分析的一些最常见应用，描述了可能被分析的一些日志以及分析方法，并阐明了一些长期存在的挑战。日志分析是一个丰富的研究领域；虽然我们的目标不是提供文献综述，但我们确实打算让读者清楚地了解为什么日志分析既重要又困难。

调试

许多日志旨在促进调试。正如 Brian Kernighan 在 1979 年的《Unix for Beginners》中写道：“最有效的调试工具仍然是仔细的思考，以及明智地放置的打印语句。” 尽管今天的程序比 30 年前的程序复杂几个数量级，但许多人仍然使用日志记录printf到控制台或本地磁盘，并结合手动检查和正则表达式来定位特定消息或模式。

调试日志最简单和最常见的用途是grep用于特定消息。如果服务器操作员认为程序因网络故障而崩溃，那么他或她可能会尝试在服务器日志中查找“连接断开”消息。在许多情况下，很难弄清楚要搜索什么，因为日志消息和观察到的症状之间没有明确定义的映射。当 Web 服务突然变慢时，操作员不太可能看到明显的错误消息，例如“错误：服务延迟增加 10%，因为触发了第 Y 行的错误 X。” 相反，用户通常会搜索诸如“错误”或“失败”之类的严重性关键字。然而，此类严重性级别通常被不准确地使用，因为开发人员很少完全了解代码最终将如何使用。

此外，虚假警报消息（例如，“未检测到错误”）可能会用不相关的事件污染结果集。考虑来自 BlueGene/L 超级计算机的以下消息

YY-MM-DD-HH:MM:SS NULL RAS BGLMASTER FAILURE ciodb 正常退出，退出代码为 0

该FAILURE严重性词语没有帮助，因为此消息可能在非故障场景（例如系统维护）期间生成。

当开发人员编写print日志消息的语句时，它与程序源代码的上下文相关联。然而，消息的内容通常不包含此上下文。在不了解周围代码的情况下print语句或导致程序进入该执行路径的原因的情况下，消息的某些语义可能会丢失——也就是说，在缺少上下文的情况下，日志消息可能难以理解。

另一个挑战是，日志文件通常被设计为表示单个事件流。然而，来自多个来源的消息可能会在运行时（来自多个线程或进程）和静态（来自程序的不同模块）交错。对于运行时交错，线程 ID 并不能解决问题，因为线程可以重复用于独立任务。人们已经努力自动包含消息上下文（X-Trace,⁴ Dapper⁹）或从消息内容中推断它们¹²，但这些都不能完全捕获开发人员的意图和期望。

静态交错场景更具挑战性，因为不同的模块可能由不同的开发人员编写。因此，单个日志消息可能具有多种解释。例如，“连接丢失”消息对于系统网络库的作者来说可能非常重要，但对于被底层抽象屏蔽错误的应用程序作者来说则不那么重要。共享库作者通常无法预测哪些消息对用户有用。

日志记录通常意味着一些内部同步。这可能会通过更改线程交错模式并掩盖问题来使多线程系统的调试复杂化。（这是所谓的“海森堡 bug”的一个例子。）一个关键的观察是，程序仅在某些执行点（例如时钟中断和 I/O）表现出非确定性行为。通过记录所有非确定性执行点，您可以忠实地重放整个程序。^11,16 重放功能强大，因为您可以通过在重放之前修改检测来观察程序中的任何内容。然而，对于并发程序或确定性执行依赖于大量数据的程序，此方法可能不切实际。

在大型系统中，日志量可能过大。例如，为了调试锁争用，记录锁对象上的每个获取和释放操作可能非常昂贵。在多模块系统中，这种困难更加严重，在多模块系统中，日志也是异构的，因此更不易于直接分析。收集、存储、排序或索引大量日志消息（其中许多消息可能永远不会被使用）存在固有的成本。调试日志记录的投资回报来自于其诊断能力，而诊断能力难以衡量。

有些用户需要聚合或统计信息，而不是单个消息。在这种情况下，他们可以仅记录聚合数据或聚合数据的近似值，并且仍然可以很好地估计所需的统计信息。近似值提供了指标的统计可靠估计，这些指标对于机器学习分析（例如 PCA（主成分分析）和 SVM（支持向量机¹⁴））非常有用。这些技术在网络或大规模分布式系统中至关重要，在这些系统中，即使从每个组件收集单个数字也会带来沉重的性能成本。这说明了为特定分析定制检测的潜在好处。

机器学习技术，尤其是异常检测，通常用于发现“有趣”的日志消息。机器学习工具通常需要将输入数据作为数值特征向量。将自由文本日志消息转换为有意义的特征并非易事。最近的工作分析了源代码，以自动从遗留文本日志中提取半结构化数据，并将异常检测应用于从日志中提取的特征。¹² 在几个开源系统和两个 Google 生产系统上，作者能够分析数十亿行日志，准确检测到通常被人类忽略的异常，并将结果可视化在单页决策树图中。

统计异常检测仍然存在挑战。即使某些消息在统计意义上是异常的，也可能没有进一步的证据表明这些消息是原因、症状还是仅仅是无害的。此外，统计方法严重依赖于日志质量，尤其是“重要”事件是否被记录。这些方法本身并没有定义什么是“重要”的。

静态程序分析可以通过分析程序中可能导致消息的路径来帮助发现特定消息的根本原因。静态分析还可以通过查找发散点来揭示提高日志质量的方法，程序执行可能从这些发散点进入错误路径；这些点是日志检测的绝佳候选点。¹³ 静态分析技术通常受到目标系统的大小和复杂性的限制。分析像 Apache Web Server 这样相对简单的程序也需要数小时。目标系统的启发式方法和领域知识通常可以使此类分析更有效。

性能

日志分析可以帮助优化或调试系统性能。了解系统性能通常与了解系统中资源的使用方式有关。某些日志与调试情况下的日志相同，例如记录锁操作以调试瓶颈。某些日志跟踪各个资源的使用情况，从而生成时间序列。资源使用情况统计信息通常以每个时间段的累积使用量形式出现（例如，b 位在最后一分钟内传输）。人们可能会使用带宽数据来表征网络或磁盘性能，使用页面交换来表征内存效率，或使用 CPU 利用率来表征负载均衡质量。

与调试情况一样，性能日志必须在上下文中解释。两种类型的上下文在性能分析中尤其有用：性能数字发生的环境以及系统的工作负载。

性能问题通常是由组件之间的交互引起的，要揭示这些交互，您可能必须综合来自多个来源生成的异构日志的信息。综合可能具有挑战性。除了异构日志格式外，分布式系统中的组件可能在确切时间上存在分歧，从而使得跨多个组件重建事件的精确顺序变得不可能。此外，对于一个组件来说是良性事件（例如，日志刷新到磁盘）可能会给另一个组件带来严重问题（例如，由于 I/O 资源争用）。由于导致问题的组件不太可能记录该事件，因此可能很难捕获此根本原因。这些只是出现的一些困难。

解决此问题的一种方法是计算影响，它通过寻找随时间相关的意外行为来推断组件或组件组之间的关系。⁸ 例如，突发磁盘写入可能在时间上与客户端通信错误相关；足够强的相关性表明系统这两个部分之间存在一些共同的影响。影响可以量化产生异构日志的组件之间的交互，即使这些日志是稀疏的、不完整的且没有已知语义，甚至在交互机制未知的情况下也是如此。影响已应用于从自动驾驶汽车（如 Stanley¹⁰）（它帮助诊断了一个危险的摇摆 bug⁸）到超级计算机（如 Blue Gene/L¹）（它能够实时分析来自超过 100,000 个组件的日志⁷）的生产系统。

当系统处理消息或请求时对其进行跟踪的方法能够说明事件的顺序和工作负载的影响。例如，一种类型的请求可能很容易通过缓存数据来提供服务，而另一种类型的请求则可能无法提供服务。这种跟踪方法通常需要支持检测，但对于正确性调试和理解性能都很有用。

该领域的一个突出挑战是，测量行为本身存在影响测量的风险。消耗资源的大量日志记录可能会使计算这些资源最初是如何使用的任务变得复杂。我们测量的越多，我们就越不准确地了解系统的性能特征。即使是保守的跟踪机制通常也会在实践中引入不可接受的开销。

减少日志记录对性能影响的一种方法是采样。危险在于采样可能会遗漏罕见事件。然而，如果您有数百万甚至数十亿个相同程序运行的采样实例，您也许可以保持较低的采样率，同时仍然捕获罕见事件。

采样技术的有效实施需要能够在不重新启动执行的情况下打开和关闭单个日志站点。诸如 DTrace 之类的旧系统需要静态检测的日志站点。² 程序重写的最新进展可用于在运行时检测程序二进制文件中的任意站点。最近在这方面的一项努力是 Fay，这是一个用于收集、处理和分析软件执行跟踪的平台³，它允许用户以声明性语言的查询形式指定他们想要测量的事件；然后，Fay 将动态检测插入到运行的系统中，聚合测量结果，并提供特定于这些查询的分析机制。当应用于分布式系统中的基准代码时，Fay 显示了个位数的百分比开销。动态程序重写与基于采样的日志记录相结合，很可能成为解决需要大规模详细日志的问题的关键解决方案。

安全

日志也用于安全应用程序，例如检测违规或不当行为，以及对安全事件执行事后检查。根据系统和威胁模型，几乎任何类型的日志都可能适合安全分析：与防火墙、登录会话、资源利用率、系统调用、网络流等相关的日志。

入侵检测通常需要从日志中重建会话。考虑一个与入侵检测相关的示例——即检测对系统的未授权访问。当用户通过 ssh 远程登录到计算机时，该计算机将生成与登录事件相对应的日志条目。在 Mac OS X 上，这些看起来像以下消息（省略了时间戳和主机名），这些消息显示名为 user47 的用户从特定的 IP 地址和端口号交互式访问计算机

sshd[12109]: 接受来自 171.64.78.25 端口 49153 ssh2 的 user47 的 keyboard-interactive/pam

com.apple.SecurityServer[22]: 会话 0x3551e2 已创建

com.apple.SecurityServer[22]: 会话 0x3551e2 属性 0x20

这三条消息共同构成了用户成功登录计算机的语义事件。当会话结束时，会打印一组相应的行

com.apple.SecurityServer[22]: 会话 0x3551e2 已结束

com.apple.SecurityServer[22]: 正在终止身份验证主机

com.apple.SecurityServer[22]: 会话 0x3551e2 已销毁

常识表明，这些注销消息与之前的登录消息匹配，因为十六进制会话号匹配 (0x3551e2)；我们知道，这些行中的第二行不包含会话号，只是因为它夹在其他两行之间，所以它是注销事件的一部分。这些行在语法上没有任何东西可以先验地揭示它们以某种方式与登录时生成的行相关联，更不用说彼此相关联了。

换句话说，每条消息都是多个语义事件的证据，包括以下内容：特定代码行的执行、ssh 会话的创建或销毁以及整个 ssh 会话。

对安全感兴趣的日志分析师可能会问一个看似简单的问题：此 ssh 会话是否构成安全漏洞？

答案可能取决于许多因素。最近是否存在异常大量的登录尝试失败？与 user47 关联的 IP 地址是否熟悉？ user47 在会话处于活动状态时是否执行了任何可疑操作？用户名为 user47 的人是否在休假，因此不应登录？等等。

请注意，只有其中一些问题可以使用日志中的数据来回答。例如，您可以查找在此会话之前的大量登录尝试失败，但您无法推断 user47 的真实身份，更不用说他或她的休假时间表了。因此，特定的分析适用于与他们希望检测到的攻击类型相称的日志；更一般地，分析的能力受到日志中信息的限制。

用于安全的日志分析可能是基于签名的，用户尝试检测已知的恶意特定行为；或者基于异常的，用户查找与典型或良好行为的偏差，并将此标记为可疑。签名方法可以可靠地检测与已知签名匹配的攻击，但对不匹配的攻击不敏感。另一方面，异常方法面临着为调用可疑异常设置阈值的困难：太低，误报会使工具无用；太高，攻击可能会未被检测到。

安全应用程序面临着对手的独特挑战。为了避免日志分析工具的注意，对手将尝试以这样一种方式行事，即攻击期间生成的日志看起来——完全或近似地——与正确操作期间生成的日志相同。分析对于不完整的日志无能为力。开发人员可以尝试提高日志记录覆盖率¹³，从而使对手更难避免留下其活动证据，但这并不一定使区分“健康”日志和“可疑”日志变得更容易。

预测

日志数据可用于预测和为未来配置资源。预测模型有助于自动化或为资源配置、容量规划、工作负载管理、调度和配置优化提供见解。从业务角度来看，预测模型可以指导营销策略、广告投放或库存管理。

某些分析模型是为特定系统构建和磨练的。专家手动识别依赖关系和相关指标，量化组件之间的关系，并设计预测策略。此类模型通常用于构建模拟器，这些模拟器使用预期的工作负载扰动或负载量重放日志，以便提出假设性问题。在 I/O 子系统、磁盘阵列、数据库和静态 Web 服务器上，存在使用分析模型进行性能预测的示例。然而，这种方法存在一个主要的实际缺点，即真实系统会频繁更改，分析技术必须跟上这些更改。

尽管建模技术在各种系统中可能很常见，但挖掘用于构建模型的日志数据以及预测的指标可能会有所不同。例如，包含时间戳、事件类型、CPU 配置文件和其他每个事件指标的 I/O 子系统和操作系统检测可用于驱动模拟器以预测 I/O 子系统性能。捕获 I/O 请求率、请求大小、运行计数、队列长度和其他属性的跟踪可用于构建分析模型，以预测磁盘阵列吞吐量。

许多分析模型是单层的：每个预测指标一个模型。在其他情况下，需要模型的层次结构来预测单个性能指标，基于其他性能指标的预测。例如，Web 服务器跟踪（包含时间戳、请求类型（GET 与 POST）、请求的字节数、uri 和其他字段）可用于预测存储响应时间、存储 I/O 和服务器内存。用于预测各种负载条件下服务器响应时间的模型可以由存储指标和服务器内存的模型组成。再举一个例子，跟踪记录访问、块访问、物理磁盘传输、吞吐量和平均响应时间的日志可用于构建多层排队网络模型，以预测物理和逻辑设计决策对数据库性能的影响。

分析模型的一个缺点是需要特定于系统的领域知识。此类模型无法无缝移植到系统的新版本，更不用说其他系统了。随着系统变得越来越复杂，人们越来越倾向于使用历史数据的统计模型来预测未来的工作负载和性能。

回归是预测中最简单的统计建模技术。它已应用于性能计数器，性能计数器用于衡量执行时间和内存子系统影响。例如，应用于这些日志的线性回归用于预测并行处理器上库的数据分区布局的执行时间，而逻辑回归用于预测一组好的编译器标志。 CART（分类和回归树）使用磁盘请求的跟踪（指定到达时间、逻辑块号、请求的块和读/写类型）来预测存储系统中请求和工作负载的响应时间。

简单回归和 CART 模型都可以预测每个模型的单个指标。然而，性能指标通常具有相互依赖性，必须预测每个指标才能做出明智的调度或配置决策。人们已经探索了各种技术来同时预测多个指标。一种方法采用典型相关分析来构建一个模型，该模型捕获系统输入和性能特征之间的相互依赖性，并利用该模型来预测系统在任意输入下的性能。最近的工作使用 KCCA（核典型相关分析）来建模并行数据库系统，并根据查询特征（例如使用的运算符和估计的数据基数）预测执行时间、使用的记录、磁盘 I/O 和其他此类指标。⁶ 相同的技术被用于建模和预测 map-reduce 作业的性能。⁵

尽管这些技术显示了统计学习技术在性能预测方面的强大功能，但它们的使用也带来了一些挑战。

从事件日志中提取特征向量是一个重要但关键的步骤，它会影响预测模型的有效性。事件日志通常包含非数字数据（例如，分类数据），但统计技术期望具有在数据上定义的分布概念的数字输入。将事件中的非数字信息转换为有意义的数字数据可能很乏味，并且需要有关事件代表什么的领域知识。因此，即使给出了预测，也很难确定正确的行动方案。

预测模型通常提供一个值范围而不是单个数字；此范围有时表示置信区间，这意味着真实值可能位于该区间内。是否根据预测采取行动是一个必须权衡置信度与成本的决定（即，根据低置信度预测采取行动是否比什么都不做更好）。根据预测采取行动可能取决于日志粒度是否与决策粒度匹配。例如，每个查询的资源利用率日志无助于任务级调度决策，因为对并行性和较低级别的资源利用率指标的洞察力不足。

报告和分析

日志分析的另一个用途是分析资源利用率、工作负载或用户行为。记录集群工作负载中任务特征的日志可用于分析大型数据中心的资源利用率。相同的数据可用于了解工作负载中作业之间的到达间隔时间以及昼夜模式。

除了系统管理外，分析还用于业务分析。例如，Web 服务器日志描述了网站的访问者，这可以产生客户人口统计信息或转化率和跳出率统计信息。 Web 日志分析技术范围从捕获页面受欢迎程度趋势的简单统计信息到描述跨多个用户会话的访问模式的复杂时间序列方法。这些见解为营销活动、内容托管和资源配置提供信息。

多种统计技术已用于日志数据的分析和报告。诸如 k-means 和层次聚类之类的聚类算法对相似事件进行分组。马尔可夫链已用于时间顺序至关重要的模式挖掘。

许多分析和警报技术都需要专家知识形式的提示。例如，k-means 聚类算法要求用户指定聚类数 (k) 或提供用作种子聚类中心的示例事件。其他技术需要用于合并或划分聚类的启发式方法。大多数技术依赖于事件的数学表示，并且分析结果以类似的术语呈现。然后可能有必要将这些数学表示映射回原始域，尽管在不了解日志语义的情况下这可能很困难。

对日志事件进行分类通常具有挑战性。例如，要对系统性能进行分类，您可以分析 CPU 利用率和内存消耗。假设您有一个高 CPU 利用率和低内存消耗的性能分析，以及一个低 CPU 利用率和高内存消耗的单独事件分析；当到达包含低 CPU 利用率和低内存消耗的事件时，不清楚它应该属于这两个分析中的哪一个（或两者）。如果有足够多的此类事件，最好的选择可能是包含第三个分析。对于如何处理跨越多个分析的事件或如何首先创建此类分析，没有普遍适用的规则。

尽管分析对于对相似事件进行分组和提供系统行为的高级视图有效，但分析并不能直接转化为可操作的见解。解释分析并使用它来制定业务决策、修改系统甚至修改分析的任务通常由人来完成。

日志记录基础设施

日志记录基础设施对于支持此处描述的各种应用程序至关重要。它至少需要两个功能：日志生成和日志存储。

大多数通用日志都是非结构化文本。开发人员使用printf和字符串连接来生成消息，因为这些原语易于理解且无处不在。然而，这种日志记录有缺点。首先，将变量序列化为文本非常昂贵（几乎占打印消息总成本的 80%）。其次，分析需要解析文本消息，这可能既复杂又昂贵。

在存储方面，诸如 syslog 之类的基础设施聚合来自网络源的消息。 Splunk 索引来自 syslog 和其他来源的非结构化文本日志，并且它对数据执行实时和历史分析。 Chukwa 使用 Hadoop 存档数据，以利用分布式计算基础设施。¹⁵

选择正确的日志存储解决方案涉及以下权衡

* 每 TB 成本（前期和维护）

* 总容量

* 持久性保证

* 写入访问特性（例如，带宽和延迟）

* 读取访问特性（例如，随机访问与顺序扫描）

* 安全考虑因素（例如，访问控制和法规遵从性）

* 与现有基础设施集成

对于日志保留，没有一刀切的策略。这使得选择和配置日志解决方案成为一项挑战。对于商业智能有用的日志通常被认为比调试日志更重要，因此会保留更长时间。相比之下，大多数调试日志会尽可能长时间地存储，但没有任何保留保证，这意味着它们可能会在资源压力下被删除。

当与警报和报告功能结合使用时，日志存储解决方案会更有用。此类基础设施可用于调试、安全和其他系统管理任务。各种日志存储解决方案有助于警报和报告，但它们留下了许多与警报限制、报告加速和预测功能相关的未解决挑战。

结论

本文中的应用和示例展示了系统管理在多大程度上已变得以日志为中心。无论是用于调试问题还是配置资源，日志都包含大量信息，可以精确定位解决方案，或至少暗示解决方案。

尽管日志分析技术最近取得了很大进展，但仍存在一些挑战。首先，随着系统变得越来越由许多通常是分布式的组件组成，使用单个日志文件来监控来自系统不同部分的事件变得困难。在某些情况下，必须对来自完全不同系统的日志进行交叉关联以进行分析。例如，支持组织可能会将电话呼叫日志与 Web 访问日志相关联，以跟踪产品的在线文档在多大程度上解决了常见问题，以及在支持呼叫期间有多少客户同时搜索在线文档。交叉分析异构日志通常并非易事，尤其是在时间戳未同步或并非所有日志都存在时间戳，以及组件之间的语义不一致时。

其次，日志记录过程本身需要额外的管理。控制日志记录的详细程度非常重要，尤其是在出现峰值或潜在的对抗行为时，以便管理开销并促进分析。日志记录机制也不应成为传播恶意活动的渠道。如何在最大限度地提高信息内容的同时最大限度地减少仪表开销仍然是一个挑战。

第三个挑战是，尽管各种分析和统计建模技术可以挖掘大量的日志数据，但它们并不总是提供可操作的见解。例如，统计技术可能会揭示工作负载中的异常或系统 CPU 利用率过高，但无法解释该怎么做。信息的解释是主观的，信息是否可操作取决于许多因素。研究在效率、准确性和可操作性之间进行权衡的技术非常重要。

有几个有希望的研究方向。由于在可预见的未来，人类很可能仍然是解释日志和根据日志采取行动的过程的一部分，因此可视化技术的进步应该证明是有价值的。

程序分析方法，包括静态和动态方法，有望提高我们自动表征导致特定日志消息序列的交互和情况的能力。最近的工作旨在修改现有的检测方法，使日志更易于进行各种分析，或提供更全面的信息。尽管这种修改并非总是可行，但关于如何生成更有用的日志的见解通常伴随着关于如何分析现有日志的见解。验证日志消息有用性的机制将提高日志质量，使日志分析更加高效。

随着越来越多的企业变得越来越依赖其计算基础设施——更不用说计算基础设施或其提供的服务本身就是业务的企业——这些系统之间关系的重要性也随之增加。我们已经看到越来越多的工具试图推断系统如何影响用户：延迟如何影响购买决策；点击模式在多大程度上描述了用户满意度；以及资源调度决策如何改变对此类资源的需求。相反，最近的工作表明，用户活动可能对系统调试有用。进一步探索用户行为（工作负载）和系统行为之间的关系可能有助于理解何时、何地以及出于何种目的使用日志。

这些研究方向，以及更好的日志记录标准和最佳实践，将有助于改善日志分析领域的现状。

参考文献

1. BlueGene/L Team. 2002. An overview of the BlueGene/L Supercomputer. IEEE Supercomputing and IBM Research Report (November); http://adam.oliner.net/files/RC22570.pdf.

2. Cantrill, B.M., Shapiro, M.W., Leventhal, A.H. 2004. Dynamic instrumentation of production systems. Usenix 2004 Annual Technical Conference, Boston, MA (June); http://www.usenix.org/event/usenix04/tech/general/full_papers/cantrill/cantrill.pdf.

3. Erlingsson, Ú., Peinado, M., Peter, S., Budiu, M. 2011. Fay: extensible distributed tracing from kernels to clusters. In Proceedings of the 23rd Symposium on Operating Systems Principles, Cascais, Portugal (October); http://research.google.com/pubs/archive/37199.pdf.

4. Fonseca, R., Porter, G., Katz R., Shenker, S., Stoica, I. 2007. X-Trace: a pervasive network-tracing framework. Usenix Symposium on Networked Systems Design and Implementation, Cambridge, MA (April).

5. Ganapathi, A., Chen, Y., Fox, A., Katz, R. H., Patterson, D. A. 2010. Statistics-driven workload modeling for the cloud. Workshop on Self-managing Database Systems at ICDE: 87-92.

6. Ganapathi, A., Kuno, H. A., Dayal, U., Wiener, J. L., Fox, A., Jordan, M. I., Patterson, D. A. 2009. Predicting multiple metrics for queries: better decisions enabled by machine learning. International Conference on Data Engineering: 592-603.

7. Oliner, A.J., Aiken, A. 2011. Online detection of multi-component interactions in production systems. International Conference on Dependable Systems and Networks, Hong Kong; http://adam.oliner.net/files/oliner_dsn_2011.pdf.

8. Oliner, A.J., Kulkarni, A.V., Aiken, A. 2010. Using correlated surprise to infer shared influence. In Proceedings of the International Conference on Dependable Systems and Networks, Chicago, IL: 191-200.

9. Sigelman, B., Barroso, L., Burrows, M., Stephenson, P., Plakal, M., Beaver, D., Jaspan, S., Shanbhag, C. 2010. Dapper, a large-scale distributed systems tracing infrastructure. Google Technical Report; http://research.google.com/archive/papers/dapper-2010-1.pdf.

10. Thrun, S., Montemerlo, S., et al. 2006. Stanley: the robot that won the DARPA Grand Challenge. Journal of Field Robotics 23(9): 661-692.

11. Xu, M. et al. 2003. A "flight data recorder" for enabling full-system multiprocessor deterministic replay. In Proceedings of the 30th Annual International Symposium on Computer Architecture, San Diego, CA (June).

12. Xu, W., Huang, L., Fox, A., Patterson, D., Jordan, M. 2009. Detecting large-scale system problems by mining console logs. 22nd Symposium on Operating Systems Principles, Big Sky, MT (October).

13. Yuan, D., Zheng, J., Park, S., Zhou, Y., Savage, S. 2011. Improving software diagnosability via log enhancement. In Proceedings of Architectural Support for Programming Languages and Operating Systems, Newport Beach, CA (March); http://opera.ucsd.edu/paper/asplos11-logenhancer.pdf.

14. Nguyen, X., Huang, L., Joseph, A. 2008. Support vector machines, data reduction, and approximate kernel matrices. European Conference on Machine Learning and Knowledge Discovery in Databases: 137-153.

15. Rabkin, A., Randy, K. 2010. Chukwa: a system for reliable large-scale log collection. USENIX Conference on Large Installation System Administration: 1-15.

16. Gautam, A., Stoica, I. 2009. ODR: output-deterministic replay for multicore debugging. Symposium on Operating System Principles: 193-206.

喜欢还是讨厌？请告诉我们

[email protected]

Adam Oliner 是加州大学伯克利分校电气工程和计算机科学系的博士后学者，与 Ion Stoica 和 AMP（算法、机器和人）实验室合作。他最近在斯坦福大学完成了计算机科学博士学位，导师是 Alex Aiken，他是 DOE HPCS 研究员和斯坦福大学荣誉研究生研究员。Adam 获得了麻省理工学院电气工程和计算机科学硕士学位，并在那里完成了计算机科学和数学的本科学位。他的研究重点是理解复杂系统。

Archana Ganapathi 是 Splunk 的一名研究工程师，专注于大规模数据分析。她获得了加州大学伯克利分校计算机科学博士学位，并且是 RAD（可靠自适应分布式系统）实验室的成员。她还在伯克利完成了学士和硕士学位，并获得了国家科学基金会研究生研究奖学金。Archana 在她的研究生涯中花费了大量时间分析生产数据集以建模系统行为。

Wei Xu 是 Google 的一名软件工程师，他在 Google 的调试日志记录和监控基础设施方面工作。他于 2010 年获得了加州大学伯克利分校计算机科学博士学位。他的论文是关于在大规模系统调试中应用机器学习方法。他曾在宾夕法尼亚大学和清华大学攻读本科学位。他的研究兴趣在于集群管理和调试。

最初发表于 Queue vol. 9, no. 12—
在数字图书馆中评论这篇文章

更多相关文章

Mark Burgess - 可测试的系统管理
系统管理的方法在过去 20 年中几乎没有变化。虽然核心 IT 技术在许多方面都得到了改进，但对于许多（如果不是大多数）组织而言，系统管理仍然基于生产线构建物流（又名配置）和被动事件处理。随着我们进入信息时代，人类将需要减少像他们使用的机器一样工作，并拥抱基于知识的方法。这意味着利用简单的（免手动）自动化，使我们能够自由地发现模式并做出决策。

Christina Lear - 系统管理软技能
系统管理既可能充满压力，也可能带来回报。压力通常来自外部因素，例如 SA（系统管理员）与其同事之间的冲突、资源匮乏、高干扰环境、相互冲突的优先级以及 SA 对其无法控制的故障负责。SA 及其经理可以做些什么来减轻压力？有一些众所周知的人际关系和时间管理技巧可以提供帮助，但在危机时期或仅仅是出于习惯，这些技巧可能会被遗忘。

Thomas A. Limoncelli - 系统管理员对软件供应商的呼吁 - 10 项须知和禁忌
我的一个朋友是汽车修理工：那种汽车爱好者，他们喜欢在周六晚上重建发动机。他向我解释说，某些品牌的汽车在设计时就考虑到了让机械师的工作更轻松。然而，另一些汽车的设计却好像该公司与阿司匹林行业达成了协议，以确保有大量的机械师头痛。他说那些汽车公司讨厌机械师。我完全理解，因为作为一名系统管理员，我可以分辨出软件供应商何时讨厌我。这体现在他们的产品中。

Eben M. Haber, Eser Kandogan, Paul Maglio - 系统管理中的协作
乔治遇到麻烦了。一个看似简单的部署花费了整个上午，而且似乎遥遥无期。他的经理不断进来查看他的进度，因为客户急于完成部署。他本应该去参加一位即将离职的同事的告别午餐，这增加了他的压力。他请求了各种帮助，包括同事、应用程序架构师、技术支持，甚至还有一位系统开发人员。他使用电子邮件、即时消息、面对面联系、他的电话，甚至他办公室同事的电话与所有人进行沟通。而且乔治绝非新手。