可观察性意味着我们可以询问有关系统的问题并获得答案，或者至少有明确定义的途径来获得这些答案。在本地运行时听起来很简单，但是当您有一个复杂的生产环境并且有人问您：有人使用该块吗？

你怎么知道？

您可能很幸运，并在该代码中登录了登录，仍然很幸运的是，日志在正确的级别并正确管道，以便您可以检查。问题是，如果您添加了太多日志或太多可观察性数据，您可能会产生的疾病比治疗更糟：过度遗传或过度观察。

既可以降低您的绩效并显着影响银行帐户，所以理想情况下，我们不想要太多日志（I discuss over-logging here），我们不希望太多可观察到。

现有的开发人员可观察性工具积极起作用。要回答问题，如果有人使用代码，我可以将计数器放在生产线上并等待结果。我可以给它一个星期的超时，并在一周内找出答案。这不是一个可怕的情况，但也不是理想的，我没有那么多耐心。

跟踪和opentelemetry

大多数开发人员在日常工作中不使用跟踪是一种悲伤的状态。对于那些不知道的人来说，这就像云的呼叫堆栈。它使我们可以通过服务器和过程看到堆栈。不，不是方法调用。在入口点级别上有更多内容，但这通常包含诸如所做的数据库查询和类似深入见解的细节。

与OpenTelemetry有很多历史，我不想进入，如果您是一个可观察到的怪胎，那么您已经知道了，如果不知道，那很无聊。重要的是，Opentelemetry正在接管追踪世界。这是一个运行时代理，这意味着您只需将其添加到服务器中，并且几乎可以无缝地获取跟踪信息。这是魔术。

它也没有标准服务器，这使其非常令人困惑。这意味着多个供应商可以使用单个代理商并显示其收集到各种人口统计信息的信息：

• 专注于性能的供应商可以显示系统中各个部分的时机。

• 专注于故障排除的供应商可以检测潜在的错误和问题。

• 专注于安全的供应商可以检测潜在的风险访问。

背景开发人员可观察性

我将在这里造成一个术语，因为没有一个：背景开发人员可观察性。如果您需要的数据已经在这里，并且系统已经在后台为您收集了该怎么办？

那就是迪格马在做什么。用Digma的话来说，它叫做Continuous Feedback。从本质上讲，他们会收集OpenTelemetry数据，分析并将其显示为对开发人员有用的信息。如果Lightrun就像调试器一样

很酷的事情是，您可能已经在不知道的情况下使用了OpentElemetry。 DevOps可能已经安装了该代理，并且数据已经存在！

回到我的问题，有人使用此API吗？

如果您使用Digma，您可以立即看到。 OpentElemetry已经在后台收集了信息，而DevOps团队已经支付了收集的价格。我们也可以从中受益。

足够的博览会

我知道，我继续前进，让我们去找那个岩石的肉和土豆。请注意，这是一个演示，当在当地运行时，好处是有限的。这些工具的真正价值在于理解生产，即使在本地运行以及运行测试时，它们仍然可以提供很多见解。

digma具有用于Intellij/Idea的简单整合的设置向导。您需要让Docker Desktop运行以进行设置才能成功。请注意，您不需要使用Docker运行您的应用程序，这仅适用于Digma服务器进程收集执行详细信息。

安装后，我们可以运行我们的应用程序，就我而言，我只是从latest book进行了JPA单元测试，并且产生了已经很酷的标准痕迹，我们可以看到它们列出了：

当我们单击其中一个跟踪时，我们会得到标准跟踪视图，这并不是什么新鲜事物，但是很高兴直接在IDE中看到此信息，并且很容易访问。我可以想象这将为找出CI执行问题所具有的巨大价值：

但是，真正的值和Digma成为开发人员可观察性工具而不是可观察性工具的位置，在此处的工具窗口：

直接从可观察性数据和更深入的分析中与代码有很强的联系，这在我特定的过于简单的Hello World中没有显示出来。此工具窗突出了有问题的迹线，错误并有助于理解real-world issues。

这在凌晨2点有帮助？

灾难发生是因为我们看上去。我想说的是我定期打开可观察性仪表板，但我没有。然后，当失败时，我需要一段时间才能将轴承置于其中。适用数据的局部性很重要，它可以帮助我们注意到问题时注意到问题。检测回归之前，在他们转向失败并了解我们刚刚合并的代码的影响之前。

预防始于意识，作为开发人员，我们将情境意识交给了Devops团队。

当故障实际发生时，数据的局部性和可访问性会带来很大的不同。由于我们使用每天集成在IDE中的工具，因此将同时降低到修复程序。不，背景开发人员可观察性工具可能不包括我们解决问题所需的信息。但是，如果确实如此，那么信息就已经存在了，我们无需其他。太棒了。

最后一句话

在所有有关可观察性和开放遥测的讨论中，您会认为每个人都在使用它们。不幸的是，现实远非如此。是的，在Devops人群中有些饱和和熟悉。对于开发人员而言，情况并非如此。

这是环境失明的一种形式。由数据和事实如此驱动的我们的团队如何以二手且经常过时的数据进行？

我应该花时间进一步优化这种方法，还是浪费努力，因为很少有人使用它？

我们可以在本地进行基准测试，但是现实世界的使用和影响是我们所有人都需要改进的事物。