通过日志文件发现潜在问题答案

【问题标题】：Find potential problems through log files通过日志文件发现潜在问题
【发布时间】：2016-07-28 19:41:43
【问题描述】：

如果源代码出现问题，通常程序员会手动查看日志并尝试找出源代码中的问题。

但是是否有可能使这个过程自动化？我们能否自动化该过程，从而在源代码中提供导致故障的潜在行。

所以，例如：

如果日志文件有问题。那么这个自动化工具应该说出现这个问题是由于源码ABC

中的第30,31,32,35,38行

谢谢！！

【问题讨论】：

伙计，如果你的日志没有显示程序失败的地方，那么你做的不对。如果有诸如自动来源之类的东西找到这些行，它会自动更正自己。
我正在谈论构建一个工具，该工具将有助于建议可能存在错误的行。顺便说一句，很明显你需要一组正确的工作日志来制作这样的工具。

标签： testing logging language-agnostic fault

【解决方案1】：

这取决于您使用的语言。

在 Java（可能还有其他 JVM 语言）中，这个特性是内置的：每个抛出的异常都有一个对堆栈跟踪的引用，包括所涉及的每个方法的类、方法和行号。您需要做的只是类似

exception.printStackTrace();

在 C 和 C++ 中，您可以在抛出异常或写入日志消息时使用 __FUNCTION__ 或 __LINE__ 等预处理器宏，例如：

throw "Error in " + __FUNCTION__ + ", line " + std::to_string(__LINE__);

宏将被当前函数和当前行替换。

如果您正在寻找一种适用于任何语言和任何类型日志记录的方法，那么没有好的解决方案。您可以在所有源文件上运行类似grep 的工具，该工具将尝试查找匹配项。但是，这仅在日志消息在源代码中以字符串文字出现在消息写入位置时才有效。这不太可能，因为消息可能包含在其他地方定义的变量值或常量。

【讨论】：

【解决方案2】：

假设我们不是在谈论（单元）测试，因为这就是他们所做的 - 告诉你问题到底出在哪里。

那么这个自动化工具应该说这个问题是由于源代码ABC中的第30,31,32,35,38行引起的

在我的团队中，我们进行了类似的讨论，我们得到了一份最有可能出现的问题文档（PlayBook）。在每次失败时阅读日志后，我们注意到在大多数情况下都有一个需求模式。因此，10 个案例中有 8 个问题遵循其中一种模式。因此可以跟踪最新的更改（在 Git 的帮助下）。如果您的更改很小且很频繁 - 这种方法效果很好。

【讨论】：