利用动态图形

动态图形是应用程序的一个模型,它了解组件(例如,主机、操作系统、JVM、Cassandra 节点、MySQL 等)的所有物理和逻辑依赖关系。 该图还包含诸如跟踪、应用程序、服务、集群和表空间之类的逻辑组件。 组件及其依赖关系由我们的代理程序和传感器自动发现,这意味着图形将实时保持最新。

图形中的每个节点也会不断更新状态信息,例如度量值、配置数据以及基于语义知识和机器学习方法计算出的运行状况值。 此知识还会分析图形中的依赖关系以查找逻辑分组(例如,服务和应用程序),从而了解对该级别的影响并生成问题的重要程度。 整个图形是持久的,这意味着 Instana 应用程序可以在时间上来回切换,以便利用图形的整个知识库处理许多操作用例。

根据动态图,我们计算更改和问题对应用程序或服务的影响,如果影响严重,我们会将一组相关的问题和更改合并到事件中。 事件显示问题和更改如何随时间推移而变化,从而使 Instana 能够直接指向事件的根本原因。 然后会自动发现任何更改,并计算其对周围节点的影响。 变更可以是运行状况的恶化(我们称之为“问题”),配置变更、流程、容器或服务器的部署或出现/消失。

为了实现这一具体目标,我们看看如何对使用 Elasticsearch 集群的简单应用程序进行建模和理解,以使用 Web 界面搜索产品。 实际上,这可能只是一个 µService,但它显示了我们如何理解 Instana 中的集群和依赖关系。

动态应用程序

让我们为 Elasticsearch 集群开发一个动态图模型,以了解其工作方式以及这在分布式环境和流畅环境中很有用的原因。

我们从单个 Elasticsearch 节点开始,该节点在技术上是一个 Java 应用程序,因此图形如下所示:

ES 节点图形

这些节点会显示主机上自动发现的组件及其关系。 对于 Elasticsearch 节点,我们将发现一个 JVM、一个进程、一个 Docker 容器(如果节点在容器内运行),以及它正在运行的主机。 如果它在 Amazon AWS 之类的云环境中运行,我们也会发现它的可用性区域并将其添加到图形中。

每个节点都具有实时属性(例如 JVM_Version=1.7.21)和所有相关度量值,例如,主机的 I/O 和网络统计信息、JVM 的垃圾回收统计信息以及由 ES 节点建立索引的文档数。

节点之间的边缘描述它们的关系。 在此情况下,这些是“运行于”关系。 例如,ES 节点“运行”在 JVM 上。

对于 Elasticsearch 集群,我们将有多个正在构建集群的节点。

ES 集群图形

在这种情况下,我们将一个集群节点添加到表示整个集群的状态和运行状况的图形中。 它依赖于组成该集群的所有四个 Elasticsearch 节点。

Elasticsearch 的逻辑单元是索引 - 应用程序使用该索引访问 Elasticsearch 中的文档。 它以物理方式构造在分发到集群中的 ES 节点的分片中。

我们将索引添加到图中,以了解应用程序所使用的索引的统计信息和运行状况。

ES 索引图

此外,我们假定我们使用简单的 Spring Boot 应用程序访问 Elasticsearch 索引。

现在,图形包含 Spring Boot 应用程序。

Spring Boot 图形

当 Instana Java 传感器记录分布式跟踪时,Instana 将知道 Spring Boot 应用程序是否访问 Elasticsearch 索引。 我们将这些跟踪与图形中的逻辑组件相关联,并跟踪不同跟踪的统计信息和运行状况。

使用此图形,我们可以了解不同的 Elasticsearch 问题,并显示我们如何分析对整体服务运行状况的影响。

让我们假设我们有两个不同的问题:

  1. 一个主机上的 I/O 问题导致对索引/分片数据的读/写速度缓慢。
  2. 一个 Elasticsearch 节点中的线程池超负荷,因此请求会排队,因为在线程释放之前无法处理这些请求。

图形事件

事故描述

在此情况下,主机 (1) 开始出现 I/O 问题。 我们的运行状况智能会将主机的运行状况显示为黄色,然后向我们的问题跟踪程序发出问题。 几分钟后,ES (Elasticsearch) 节点 (2) 将受此影响,并且我们的运行状况智能会发现此节点上的吞吐量已降级到我们将此节点标记为黄色的级别 - 再次触发问题。 然后,我们的引擎会将这两个问题关联起来,并将它们添加到事件中,这不会被标记为有问题,因为在这种情况下,集群运行状况仍然良好,因此不会影响服务质量。

然后,在另一个 ES 节点 (3) 上,将填充用于处理查询的线程池并将请求合用。 由于性能受此影响严重,因此我们的引擎会将节点状态标记为红色。 这会影响 ES 集群 (4),随着吞吐量的下降,该集群变为黄色。 生成的两个问题将汇总到初始事件中。

由于集群会影响索引 (5) 的性能,因此我们将索引标记为黄色,并将问题添加到事件中。 现在,产品搜索事务的性能受到影响,我们的性能运行状况分析会将事务标记为黄色 (6),这也会影响应用程序的运行状况 (7)。

由于应用和交易都受到影响,我们的事件实际上将以黄色状态触发,表示产品搜索性能正在下降,用户受到影响。 突出显示了两个根本原因(I/O 问题和线程池问题)的路径。 如屏幕截图所示,Instana 将显示事件的演变,用户可以在问题发生时深入了解组件 - 包括当时的准确历史环境和度量值。

这显示了 Instana 的独特功能:

  • 使用图形组合物理信息、进程信息和跟踪信息以了解它们的依赖关系。
  • 用于了解单个组件的运行状况,以及集群、应用程序和跟踪的运行状况的智能。
  • 智能影响分析,以了解某个问题是否严重。
  • 显示问题的根本原因,并提供切实可行的信息和上下文。
  • 保留图形的历史记录,其属性、度量、更改和问题,并提供“timeshift”功能分析任何给定问题,并清晰地了解所有组件的状态和依赖关系。

在现代环境中寻找根本原因只会在未来几年变得更具挑战性。 上面的简单示例表明,如果不了解上下文、依赖关系和影响,查找根本原因并不是一项简单的任务。 现在,请考虑基于 µServices 的“流动”系统,这些系统可随时添加和移除服务,并频繁推出新版本 - Instana 可实时跟踪状态和运行状况,并了解这些更改或问题的任何影响。 这都是在没有任何手动配置的情况下实时完成的。

使用情况

将自动创建并更新 "动态图形"。 可以通过 服务配置进一步指定某些组件 (例如服务) 的定义。

可以使用强大的动态焦点功能完成图形遍历和作用域限定。