IDE日志分析方法pt。 1个

介绍

我认为大多数软件工程师都了解日志的重要性。它们已成为软件开发的一部分。如果无法解决问题，我们尝试在日志中查找原因。对于一些简单的情况，当错误阻止应用程序打开窗口时，这可能就足够了。您可以在日志中找到问题，然后在Google上查找并应用解决方案。但是，如果要修复包含许多组件的大型产品中的错误，则分析日志将成为主要问题。通常，维护工程师（正在修复不开发新功能的错误）需要处理数百兆字节的日志。日志通常分为50-100 MB的单独文件并压缩。

有几种方法可以使这项工作更轻松。我将描述一些现有的解决方案，然后解释解决此问题的理论方法。这篇博客文章不会讨论任何具体的实现。

现有解决方案

文本编辑器

此解决方案实际上不是解决方案，它是大多数人在需要阅读文本文件时会采取的措施。一些文本编辑器可能具有有用的功能，例如颜色选择，书签，可以使工作更轻松。但是，文本编辑器仍然没有一个不错的解决方案。

圆锯

该工具可以使用log4j模式从日志中提取字段。听起来不错，但这些字段在文字中已经很明显了。显然，与简单的文本编辑器相比，改进是微不足道的。

LogStash

这个项目看起来还不错。但是这种方法非常具体。即使我从描述中从未使用过此工具，但我了解到他们使用ElasticSearch和简单的文本搜索来分析日志。日志必须上传到某处并建立索引。之后，该工具可能会显示最常用的单词，用户可以使用文本搜索等。听起来不错，似乎有所改进。不幸的是没有那么多。缺点如下：

需要一些时间才能开始使用日志。一个必须上传它们，将它们编入索引。工作完成后，必须从系统中删除这些日志。如果打算对日志进行分析和丢弃，则看起来有些过分。
很多组件涉及很多必需的配置。
全文搜索对日志不是很有用。通常，工程师正在寻找类似“使用参数678678678创建的连接2345”之类的东西。查找“使用参数创建”将返回所有连接。查找“连接2345”将返回所有此类语句，但是通常只有一个-创建此连接时。

其他基于云的解决方案

有很多基于云的解决方案可用。他们大多数有商业计划，有些有免费计划。它们提供通知，可视化和其他功能，但主要原理与LogStash相同。

日志分析说明

要了解为什么这些解决方案在分析复杂问题时效果不佳，我们需要尝试了解工作流程。这是文本编辑器的示例工作流程：

工程师收到了1 GB的日志，其中包含该bug发生在23:00的信息，请求ID为12345。
首先，他或她会尝试在这段时间内发现任何错误或异常。
如果失败，则工程师必须为该请求重建事件流。他或她开始寻找诸如“已创建连接”，“已删除连接”，“请求移至此阶段”之类的语句，以试图缩小问题的时间范围。
这通常是成功的（即使可能要花费很多时间），现在很明显，问题是在将连接111移到状态Q之后发生的。
经过多一点的挖掘之后，工程师发现这与连接222进入状态W一致。
最终，工程师高兴地看到，将连接222移动到新状态的线程还修改了另一个影响连接111的变量。最后是根本原因。

在此工作流程中，我们看到工程师大部分时间都在寻找带有某些参数的标准字符串。如果可以简化的话……

IDE方法

IDE方法包括几个部分。

正则表达式 。使用正则表达式，可以指定模板并在日志中搜索它。使用正则表达式查找标准字符串要简单得多。
正则表达式配置 。这里的想法是标准字符串如“创建的连接\ d {5} \ w {2}”，“连接\ d {5} \ w {2}移到阶段\ w {7}”，“连接\ d { 5} \ w {2}已删除”不会经常更改。编写正则表达式每次都很难找到它，因为这样的正则表达式可能真的很长很复杂。如果可以通过单击按钮来配置和使用它们，则会更加容易。
IDE 。我们需要某种IDE来将其结合在一起。要读取配置，请显示日志文件和存储的正则表达式，并显示文本和搜索结果。最好像这样：
颜色特征 。从经验中我知道，当您可以用颜色标记一些字符串以在日志中轻松查看日志时，日志分析要容易得多。大多数商业日志分析器工具都使用颜色选择。 IDE应该对此提供帮助。