承装承修承试材料在哪个网站做,电子商务网站建设与管理目录,二级域名建立网站,做网站显示上次登录时间代码介绍 我认为大多数软件工程师都了解日志的重要性。 它们已成为软件开发的一部分。 如果无法解决问题#xff0c;我们尝试在日志中查找原因。 对于一些简单的情况#xff0c;当错误阻止应用程序打开窗口时#xff0c;这可能就足够了。 您可以在日志中找到问题#xff0c;然后… 介绍 我认为大多数软件工程师都了解日志的重要性。 它们已成为软件开发的一部分。 如果无法解决问题我们尝试在日志中查找原因。 对于一些简单的情况当错误阻止应用程序打开窗口时这可能就足够了。 您可以在日志中找到问题然后在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应该对此提供帮助。 利弊 IDE方法的优点 无需云服务。 没有在某处加载千兆字节的日志没有云配置。 只需打开IDE记录日志打开日志文件夹并开始分析。 如果IDE是免费的则整个过程是完全免费的。 无论如何应该比日志服务便宜。 IDE方法的缺点 大多数云服务“实时”提供实时通知和日志分析。 这意味着一旦指定的异常发生就会通知用户。 IDE方法无法做到这一点。 由于在Java中使用大字符串会消耗大量内存因此对用户PC的要求会更高。 根据我的经验最低要求为8 GB。 最重要的是IDE方法适合分析日志中的复杂问题。 它不能提供云服务的实时功能但是对于分析和修复错误应该便宜得多并且更容易。 最后的想法 如果有人可以实施这种出色的方法那就太好了 我的意思是创建具有所有这些功能的IDE并使每个人的日志分析更加轻松 我从经验中知道这可能是一件乏味的工作比实际要难。 在下一篇文章第2部分中我将解释这种方法的困难/挑战并提供基于Eclipse框架的可行实现。 翻译自: https://www.javacodegeeks.com/2018/11/ide-approach-log-analysis-pt.html
