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.