Fully Automated Software Logging

这项研究解决了计算机科学中的一个基本问题。今天的程序员花60%的时间在调试上；软件行业每年在故障诊断上花费1530亿美元。当故障导致软件宕机，特别是承载所有应用程序的系统软件（例如，操作系统）时，就不会产生有用的工作。本研究旨在加速系统软件的故障诊断过程，以减少软件的停机时间。******当软件系统在生产环境中出现故障时，日志数据通常是程序员用于事后诊断的唯一可用信息。程序员在软件程序中放置日志打印语句（例如，使用printf）。在运行时，这些语句将诊断信息输出到日志文件。使这些日志如此有价值的是它们的无处不在和商业接受。当客户报告故障时请求日志是一种行业标准实践，由于他们的数据通常只关注系统健康问题，因此通常认为日志远不如其他数据源敏感。此外，由于日志通常是人类可读的，因此客户可以检查它们以确定它们的可接受性。许多软件供应商甚至允许自动传输日志而无需审查。******因此，日志数据的质量对事后调试至关重要。实际上，如果日志没有提供信息，或者更糟糕的是，具有误导性，则事后调试最终可能是徒劳的。遗憾的是，人们很少关注原木的质量。虽然日志记录很普遍——决定在哪里登录程序是每个程序员的日常任务——但很少有关于日志记录的指导方针或已建立的最佳实践。更糟糕的是，程序员在软件发布的时间压力下经常忽略日志代码的质量。因此，经常出现这样的情况：当发生故障时，日志中不包含任何与故障相关的信息，这种情况通俗地称为“在黑暗中调试”。******本研究建议实现软件日志的完全自动化。它解决了在程序中放置日志语句的基本问题。本研究提出了一系列能够自动将日志语句放置在最佳程序位置的算法。它有三个特定的目标：(1)用于故障诊断的日志记录；(2)用于性能分析的日志记录；(3)用于安全审计的日志记录。关键的挑战是度量所放置的日志记录语句的信息量，以及在信息量与日志记录的性能成本之间进行权衡。其核心思想是使用信息论来度量软件的熵，并计算不同的日志放置策略如何减少该熵。

This research addresses a fundamental problem in computer science. Programmers today spend 60% of their time in debugging; software industry spends $153 billion on failure diagnosis annually. When failures bring software down, especially systems software (e.g., operating system) that hosts all applications, no useful work can be produced. This research aims to speed-up the postmortem failure diagnosis process on systems software to minimize software's downtime. ******When software systems fail in production environments, log data is often the only information available to programmers for postmortem diagnosis. Programmers place log printing statements in software programs (e.g., using printf). At runtime, these statements output diagnostic information to log file. What makes these logs so valuable is their ubiquity and commercial acceptance. It is an industry-standard practice to request logs when a customer reports a failure and, since their data typically focuses narrowly on issues of system health, logs are generally considered far less sensitive than other data sources. Moreover, since logs are typically human readable, they can be inspected by a customer to establish their acceptability. Many software vendors even allow logs to be transmitted automatically and without review. ******Consequently, the quality of the log data is of critical importance to postmortem debugging. Indeed, if the log is uninformative, or even worse, misleading, postmortem debugging can end up being a wild goose chase. Unfortunately, little attention has been paid to the quality of log. While logging is pervasive – it is every programmer's everyday task to decide where to log in the program -- there is very little guideline or established best practices on logging. Worse, programmers often ignore the quality of logging code when they are under time pressure of software release. As a result, it is frequently the case that when a failure occurs, the log does not contain any failure-related information, a situation referred colloquially as “debugging in the dark”.******This research proposes to fully automate software logging. It addresses the fundamental problem of where to place logging statements in the program. This research proposes a series of algorithms that are capable of automatically placing logging statements at optimal program locations. It has three specific objectives: (1) logging for failure diagnosis purpose, (2) logging for performance profiling, and (3) logging for security auditing. The key challenge is to measure how informative is logging statements being placed, and to trade-off informativeness with the performance cost of logging. The core idea is to use Information Theory to measure the entropy of the software, and calculate how different logging placement strategies can reduce this entropy.