14

让我先说一下，我对这个话题非常无知，以至于我什至不知道这个问题是否有客观的答案。如果它最终是“不是”，我将删除或投票关闭该帖子。

场景如下：我刚刚编写了一个小 Web 服务。它适用于我的机器。它适用于我的团队负责人的机器。据我所知，它在除生产服务器之外的每台机器上都有效。生产服务器在失败时吐出的异常源自第三方 JAR 文件，并且信息不足。我在网上搜索了几个小时，但没有找到任何有用的东西。

那么跟踪仅在生产机器上发生的问题的程序是什么？为此，是否有标准方法，或者可能是工具类别/系列？

引发这个问题的错误已经得到修复，但这更多是由于好运而不是可靠的调试方法。我问这个问题以供将来参考。

编辑：
到目前为止，这个问题的答案似乎可以用一个词来概括：logging。日志记录的一个问题是它需要预先考虑。如果现有系统中出现日志记录不佳的情况，或者客户担心敏感数据并且不希望系统中有大量日志记录系统，该怎么办？

一些相关问题：
在生产系统中测试帐户和产品 在
生产代码/服务器上运行测试

4

7 回答 7

10

除了非常宝贵的日志记录之外，还有我自己和我的同事多年来使用的一些其他技术……回到我们无法访问的客户端计算机上的 16 位窗口。（我和自己约会了吗？）当然，并非一切都可以/将起作用。

  • 分析您看到的任何和所有行为。
  • 复制，如果可能的话，复制它。
  • 桌面检查，检查您怀疑的代码。
  • 与团队成员和对代码知之甚少或不熟悉的人一起避而不谈。你向某人解释的越多，你发现某事的机会就越大。
  • 不要沮丧。休息5-10分钟。快速穿过建筑物/街道/随便什么。暂时不要考虑问题。
  • 倾听你的直觉。
于 2010-06-10T15:54:54.873 回答
7

这是最困难的调试场景之一。答案将取决于生产系统的细节。它是一个您可以完全控制的系统吗？或者它是否安装在客户端的机器上，您需要通过无数电话才能访问日志文件或修改配置参数？

我相信大多数人都会同意，最有效的调试方法是使用日志记录。您需要主动采取行动并添加尽可能多的日志记录信息。但是，您必须能够按需启用和禁用日志记录。生产系统中的大量调试日志可能会降低性能。出于同样的原因，您需要能够仅启用日志记录的特定部分。创建日志打印输出的逻辑组，并仅启用您认为它将为您提供最相关信息的组。

于 2010-06-10T14:47:28.480 回答
2

我将从小的、易于检查的生产和测试之间的差异开始。通过实际测试消除明显的东西，如权限、防火墙、不同版本等。有一次我偷工减料说哦，那不可能，是的。

然后我根据可能性和成本优先考虑更昂贵的测试。要有创意。想想可能导致您看到的行为的非常奇怪的事情。

于 2010-06-10T15:56:21.560 回答
1

通常来说，“调试”[即附加到进程并检查执行] 是不可行的 - 原因有很多，其中最重要的是数据敏感性[例如，开发人员很少有资格\有权检查我们操作的数据]

因此，这通常归结为从辅助资源和工件推断执行。然后归结为...

  • 记录，
  • 记录，
  • 记录，

现在编写的大部分软件都属于 Java 或 .Net 阵营，因此请分别使用 log4j 和 log4net。

还拥有以 Ops 为中心的防暴配置指南和验证过程会有所帮助。请记住，负责硬件和环境的人员很少了解他们托管的应用程序的配置要求。

于 2010-06-10T14:54:15.640 回答
0

我使用了可配置的日志系统（例如 Log4J）来查看生产运行中发生的情况，这假设开发人员已将有用的调试信息放入日志中。

但请注意，日志记录可能会暴露一些敏感的私人数据，应尽可能对其进行编码和/或跳过。

于 2010-06-10T14:49:53.420 回答
0

除了记录之外，其他技术还包括保存请求数据，然后您可以稍后将这些数据输入到您自己的“相同”系统中。这可以像将收到的每个 HTTP 请求保存到文件中以供以后分析一样简单。现在您可能正在记录大部分此类信息（尤其是 GET 的 URL），您只需将标头和请求正文也添加到混合中。

向错误消息添加更多细节也很方便。例如，当您从例程中获得异常时，您可以将该调用中使用的参数添加到异常错误中。或者，至少，全局状态信息（谁登录，他们在什么高级模块，他们正在调用什么高级函数等）。

于 2010-06-10T14:54:33.830 回答
0

一些建议：

  • 做好准备，错误可能是由多种原因引起的，因此尽量不要只寻找一个原因。
  • 使用未处理的错误处理程序，它将跟踪错误并汇总类似的缺陷（graylog，ELMAH）。
  • 考虑使用小型转储文件进行事后调试。
  • 为快速而肮脏的方法设定固定的时间框架，然后采用系统的方法。
  • 与您的一位同事一起尝试代码审查缺陷模块。新鲜的观点可能会有所帮助。
  • 使用您的版本控制系统（GIT、SVN）分而治之。
  • 小心修复，因为大约 4% 的修复最终会引入新的错误。
  • 不要让快速修复生产中的错误的压力使您忽略标准质量控制程序（例如代码审查）。
  • 修复后确保您已经编写了自动化测试，以防错误会在一段时间后再次出现。
于 2013-06-27T10:05:36.167 回答