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.