简介
如今，我们听到可观察性、监控和应用性能管理（APM）这些术语被交替使用。但是，这些术语实际上意味着完全不同的事情。因此，让我们先来看看这些东西到底有什么不同的例子。
应用性能管理（APM）
首先，我将从一个Java EE应用程序开始，它是一种老式的。比方说，我们在这个Java EE应用中得到了一些组件，这些组件实际上为它提供了动力。所以，在这里要记住一些重要的事情，虽然我们可能会使用面向服务的架构，但并不完全是微服务。所以它们不是通过Rest APIs进行通信。你在这里有一些固有的优势。
例如，你可以利用Java EE框架的输出日志文件的优势。它可能会全部输出到同一个目录中，而且时间戳也是一致的，所以事情很顺利。此外，你可以利用像APM解决方案这样的东西，它有点像一个适合所有的尺寸，设置和忘记。因此，你安装它，它将获得丰富的分析和数据，以及关于应用程序内运行服务的指标。从本质上讲，我们所做的是使我们的系统可观察。这样，我们的运营团队就能够查看它，以确定问题，并弄清楚是否需要做什么。
对于当时的业务目标来说，这基本上已经足够好了，但当你开始转向更多的云原生方法时，这往往会很快崩溃，因为你有多个运行时间和多种架构层。
可观察性
假设我们有一个应用程序的例子。我们将从一个节点开始，作为前端。假设我们也有一个Java后端应用。最后让我们说，我们也有一个Python应用程序，正在做一些数据处理。那么，让我们看看这些东西是如何相互协作的。前端应用程序可能与Java应用程序和Python应用程序对话，进行一些数据处理。Java应用程序可能与数据库进行通信。然后，Python应用程序可能与Java应用程序进行对话，以进行一些简单的操作。所以这是我的快速草图，是基于微服务的应用程序的虚拟布局。你可以更进一步，甚至说这一切都在Kubernetes中运行。所以我们有这些基于容器的应用程序在集群中运行。
随即，我在这里看到的第一个问题是，有多个运行时间。所以，我们现在不得不考虑多个不同的代理或收集数据的方式。因此，我们可能不得不开始考虑引入多个APM工具，而不是只有一个APM工具。现在，我们将如何整合所有的数据呢？
此外，让我们考虑一下像日志这样的东西。每个运行时间可能都在不同的地方输出日志。我们必须弄清楚我们如何整合所有这些。也许我们使用一个日志流服务。不管怎么样，你可以看到复杂性开始增长。最后，当你在这个架构中添加更多的服务和微服务组件时，假设一个用户进来，他们试图实际访问这些服务中的一个，但他们遇到了错误。你需要通过多个服务来追踪这个请求。那么，除非你有正确的架构基础设施，比如请求的标题，也许是处理网络套接字的方法，否则事情就会开始变得混乱。你可以看到技术上的复杂性是如何增长的。
因此，Observability的出现，实际上是与标准APM工具的不同之处。它考虑的是更全面的云原生方法，能够做日志和监控等事情。
所以，我说任何一种Observability解决方案都有三个主要步骤:
- 收集 - 我们将从第一个步骤开始。我们把它叫做收集，因为我们需要收集数据。
- 监控 - 然后我们将进入监控，我们将谈论这个，因为这是你知道的监控的一部分。
- 分析 - 最后，我们将通过对你所拥有的实际数据做一些分析来结束。
在收集的步骤中，我们首先要说的是，我们实际上使我们的系统可观察。Kubernetes的一个伟大之处在于，你可以自动获得一些CPU内存数据。所以让我们说，我们得到了一些，我们从应用中得到了一些日志，都流向了同一个位置。假设我们甚至得到一些其他的东西，如高可用性数字或平均延迟，我们希望能够跟踪和监测的东西。
监测
因此，这使我进入下一步。一旦我们有了这些数据，我们就需要能够对其进行实际操作，至少要将其可视化。也许，如果我们实际上甚至还没有解决问题，我们要用这些数据做什么？好吧，我们可能会创建一些仪表盘，以便能够监测我们应用程序的健康状况。例如，我们创建多个仪表板，以便能够跟踪不同的服务或不同的业务目标，高可用性与延迟，诸如此类的事情。现在，我想谈的最后一件事是我们接下来要做什么。所以说，我们通过查看我们的监控仪表板发现了应用程序中的一些错误，我们需要深入研究并修复节点应用程序的问题。
好吧，最重要的是，Observability解决方案应该允许你这样做，它允许你实际上更进一步。就像现在的Kubernetes一样，你可以从Kubernetes层获得很多信息。这是我想快速暂停并谈论的东西。因此，过去的APM工具，他们真的有点专注于资源限制，CPU使用，内存使用等。如今，这已经被卸载到了Kubernetes层。
所以，你知道Observability把APM发展到了下一个阶段，把它提高了一步，并使我们的用户能够关注SLO和SLI，即服务水平目标和服务水平指标。这些将使你能够真正专注于对你的业务重要的事情。例如，确保延迟较低或应用程序的正常运行时间较高。所以，我认为这就是任何一种可观察性解决方案的关键三步。
总结
让我们再退一步。这些东西可能很难在你自己的开源项目和能力中建立起来，把所有不同的东西拉到一起。因此，当你在比较竞争对手并考虑建立你的企业可观察性能力时，你可能会关注企业可观察性解决方案。我想看几个主要的东西。
1.自动化
现在让我们从自动化开始。每一步我们都需要确保自动化的存在，使事情变得更容易。假设我们的开发团队推送了一个新版本的节点应用程序，从v1到v2，他们无意中引入了一个错误。他们现在不再进行构建API调用，而是对Python应用进行单独的API调用。所以在我们的监控仪表板上，我们的运营团队会说--哦，伙计们，出问题了，DB应用得到了很多请求，并确定了发生了什么。
2.上下文
这实际上也把我带到了我的第二点，也就是背景。我可以说，拥有这种背景总是很重要的。所以自动化在这里很重要，因为当升级到新版本时，一个节点你要确保自动安装正确的代理。而且仪器设备也到位了。所以你的开发团队不需要做这些。随着新服务的加入，你希望你的监控仪表板也能自动更新。在这个例子中，上下文是非常关键的，我们需要能够追溯到问题的源头的请求。
3.行动和分析
因此，一旦我们用我们所拥有的上下文追溯到该请求的源头，这里的第三步就是行动。我们现在究竟该怎么做？这把我带到了下一步，分析阶段，我们谈到的是传统APM工具向今天Observability工具实现方式的演变。因此，当你到了这一步，你可能会想看看节点应用程序中的SLI。也许会深入研究一下，对吗？所以你看进去，你会发现你需要看应用跟踪日志。
4.修复
现在，你看了跟踪日志，你发现了一些问题。你想出了修复方法，并把它告诉你的开发团队。这里的最后一步是修复，然后对未来可能出现的任何其他问题进行冲洗和重复。
结论
所以，最后，我认为当我们从大局出发时，企业可观察性在这里是非常关键的。因为它不仅仅是关于拥有个别的部分。还是像我说的那样，用纯粹的开源方法来建立可能是相当困难的。但你要考虑自动化，以确保事情设置得天衣无缝，减少你这边的开销。确保你有背景，能够看到服务是如何相互协作的。也许甚至可以生成像依赖关系图这样的东西来看到更广阔的视野，因为你可能并不总是有这样的灯牌来看到如此干净的架构。
最后，当你发现一个问题时，能够采取行动。所以要确保你的Observability解决方案有办法从多个来源和多个服务中自动提取数据，然后找出有效和必要的东西，以便你能够进行修复。
这就是目前的情况。我希望这篇文章对你有用。请随时提出任何意见、问题或建议。谢谢。
