如何生产java堆栈信息_现代Java监视堆栈：如何对生产环境进行理想的****...
如何生产java堆栈信息
您如何构建理想的Java生产监视堆栈？ 工具生态系统的决策者指南
在过去的几年中，我们有机会与数百个（甚至数千个）工程团队进行了交谈。 在所有这些讨论和我们的工程团队自己的痛苦中，一些相似之处开始浮出水面，我们认为将这些新发现的知识编写成一个好主意。
一切都归结为这一点。 监视是完成正确工作的艰巨任务，其中很大一部分在于围绕它构建的工具和流程。 在这里，选择合适的工具非常重要，我们已经确定了大多数公司都无法做到的3种工具类别。
在本文中，我们将分享这些发现，并提出一个新的框架，供您选择计划生产监视堆栈时要关注的重点。 我们将谈论：
1.可观测性计划的重要性
首先，让我们谈谈我们要通过监视实现的目标。 让我们谈谈可观察性。
测试和预生产环境非常适合确保您的应用程序已准备好进行部署，但是它们绝不能涵盖用户将遇到的100％错误。 另一方面，您不能依靠用户来报告他们遇到的每个问题。 当他们报告时，您不能依靠他们的报告来重现错误。 这就是计划可观察性的重要性所在。
来自monkeyuser.com的漫画带很好地说明了这个概念。 在测试环境中，视野很清晰，正在掩盖您正在计划的障碍，但是在地下生产环境中，情况可能会变得很暗。 障碍是不同的，您看不到那么遥远。
甚至在今天，问题仍然令人惊讶。
“您如何知道新的部署将错误引入系统？”
…通常是这样回答的：
“好，我们部署代码，然后等待。 如果经过一两天而没有人开始尖叫某件事，那么我们知道我们已经无事了。”
好消息是它不必一定是这样。 输入可观察性。
2.那么您不断提到的这种可观察性是什么？
可观察性一词来自控制理论领域。 工程和计算数学的一个跨学科分支。 它是通过了解系统的外部输出可以很好地推断系统内部状态的一种度量。
适应了生产中操作复杂应用程序的情况，我们可以将其视为衡量应用程序在离开安全，热情的开发或测试环境并大规模抛出真实数据后对其幕后情况的了解程度的一种衡量标准。 那里确实发生了很多事情。 这是我们经常探讨的主题，并在一本电子书中进行了广泛介绍，您可以在此处阅读。
底线是我们只了解我们所监视的应用程序的外部输出。 我们需要为可观察性设计架构，并提前计划，以便就下一步需要解决的问题以及如何解决这些问题做出明智的决定，而又不会浪费时间进行故障排除错误。
在何时，何地，以及最重要的是为什么生产中的代码中断，就可以知道可观察性。 在他弄清楚如何操纵矩阵之后，基本上是Neo的开发人员很容易。 一切都在控制之下，并且您有调试器可以逐步执行代码。 在生产中，情况有所不同。
3.不计划可观察性的症状
当您没有必要的工具来帮助您了解生产中发生的情况时，这种缺乏远见的想法会导致您缺乏可观察性，从而导致您对应用程序正在发生的事情缺乏了解。
有点像《星球大战》中尤达（Yoda）关于通往黑暗面之路的名言。
不计划可观察性会使您被动，而不是主动。 您不能断言您的应用程序是如何工作的，而无需依靠手动的用户报告和其他手动过程（例如使用日志进行调试），这些过程可能需要几天或几周才能完成。
而且很烂。 实际上，这实际上是导致开发人员不满意的十大原因之一，我们最近在博客上介绍了这些原因 。
4.如何****根本原因检测
我们与Fox，Comcast，Intuit，Zynga等公司的工程团队进行了交谈，并仔细研究了他们在做什么以最大程度地提高其应用在生产中的可观察性。
他们发现，他们的工具和流程没有给予他们足够的可观察性。 他们常常迟到无法发现关键问题。 那里杂乱无章，将新的或严重的错误引入到暂存或生产中时，在成千上万个（即使不是上百万个）嘈杂事件中也无法检测到。
通常，多达75％或更多的时间是最终用户或客户在应用程序或服务不再可靠运行或不再可用时首先检测到问题。 他们淹没在一片混乱的海洋中，而这往往是他们所调查的错误的真正根本原因。
我们没有接受当前状态，而是尝试通过对应用程序失败的顶级来源进行反向工程来找到理想的监视堆栈。 为此，我们询问了工程团队哪些顶级资源适合他们。
事实证明，实际上对这个问题有一个明确的答案。
我们发现，当生产应用程序遇到任何类型的故障时，这些故障背后的根本原因可从3个可能的来源中得出：
1.在一个存储桶中，由于基础结构问题而导致了一整套应用程序故障问题。 开发人员团队已经看到，此存储区可解决大约25％的应用程序问题。
2.在另一个存储桶中，由于速度和性能而导致一系列应用程序故障。 而且，如果他们拿票并进行了检查，他们会发现大约25％的应用程序故障是由于此特定问题区域造成的。
3.最后，还有第三个功能区，即功能和可靠性领域，换句话说，是“错误”，是造成最大数量故障的原因，大约占故障总数的50％。 OverOps正是在第三个存储桶中，这是导致最大数量的应用程序故障的存储桶。
我们认为这个空间已经可以被破坏了，并且我们拥有一项可以从根本上改进当今标准方法的技术。 另外，需要注意的是，我们的技术还可以补充解决速度和性能问题的努力。 此处提供了该技术的个人介绍。
请不要认为我们的话是理所当然的。 检查您自己的票务系统，并尝试查看这种分布对您自己的应用程序的外观。 这是做出明智决定的下一步最佳投资方式的最佳方法。
5.流行监控堆栈的核心用例
为了结束对这种用于构建监视堆栈的方法的介绍，我们简要介绍一下刚才介绍的每个存储桶中的一些示例和用例。 尽管这些工具具有许多功能，但我们看到它们主要用于特定问题。
基础架构和可用性– 25％的生产错误
此类别包括监视服务器的基础结构和可用性的工具。 考虑诸如网络运行状况检查，响应时间和正常运行时间之类的事情。 CPU，磁盘空间和内存利用率之类的内容也适用于此。
速度和性能–生产错误的25％
应用程序性能监视（APM）工具适合此存储桶。 我们还出版了涵盖最流行电子书的深入电子书，例如AppDynamics，New Relic和Dynatrace，以及开放源代码的替代品。 您可以在这里查看。
APM的核心用例是确定性能瓶颈，确定执行所需时间比平时长的事务，并说明应归咎于其中的方法。
AppDynamics
功能性和可靠性–生产错误的50％
在这个存储桶中，我们拥有日志管理工具，这也是我们选择将重点放在OverOps上的主要位置 。
日志已经存在了很长时间，没有太多真正的改变和创新。 我们拥有日志管理工具，可帮助使它们可搜索，但它们的性能仅与最初打印给他们的信息一样好。 如果缺少某些内容，则需要添加其他日志记录语句，部署代码，并希望您要纠正的情况再次发生！ 这有点自相矛盾。
Splunk
在讨论中，Zynga的高级软件工程师RJ Lim告诉我们：“即使有日志，也很难调试某些问题，有时甚至根本无法调试。 我们需要一些可以帮助我们调试生产的东西。”
Fox开发与架构执行总监Dmitry Erman告诉我们：“与让开发人员搜索日志或将调试器附加到生产或预生产环境相反，OverOps为我们提供了每个错误的确切条件。 我们可以看到它发生的原因，以及它是否对我们至关重要。”
简而言之，这基本上就是OverOps提供的新功能，这就是它与众不同的原因。 通过自动向您显示登台和生产中所有错误背后的变量状态，它增强和补充了您现有的日志分析器和性能管理工具。 OverOps为您的团队提供了所需的完整源代码和可变状态，可将错误修复速度提高90％。
OverOps –查看完整的源代码，以及整个调用堆栈中每个异常以及已记录的错误或警告的变量状态
最后的想法
建立监控策略是正确完成工作的艰巨任务。 但是，我们相信这种方法可以使事情变得简单。 你有同样的感觉吗？ 您采取了哪些步骤为团队选择监视工具？ 让我们在下面的评论部分中知道！
如何生产java堆栈信息