如何最佳地监控 GraphQL API

自 2015 年发布以来，GraphQL 已成为REST 的替代品。它为前端开发人员提供了他们渴望已久的灵活性。

向后端开发人员索要单一用途端点的日子已经一去不复返了。现在，查询可以定义所需的所有数据并一次性请求，至少在理论上可以大大减少延迟。

有了 REST，事情就变得简单多了 — 尤其是监控。后端团队可以查看每个端点的测量结果，并立即了解正在发生的事情。

有了 GraphQL，情况就不一样了。通常只有一个端点，因此测量每个端点并没有多大帮助。那么，新的地方在哪里可以连接到系统呢？

在本文中，我们研究监控 GraphQL！

GraphQL 架构

为了了解我们系统中有趣的点在哪里，让我们研究一下潜在的架构。

一个简单的GraphQL系统主要由三部分组成：

1. 定义所有数据类型的模式
2. GraphQL 引擎使用架构将查询的每个部分路由到解析器
3. 一个或多个解析器，它们是 GraphQL 引擎调用的函数

GraphQL 后端首先解析模式，这使服务器了解哪个解析器处理哪种类型。

当我们向 GraphQL 端点发送查询时，它会被引擎解析，并且对于查询中的每个请求类型，引擎都会调用我们的解析器来满足请求。

我们可以想象，这种方法只有在与简单查询一起使用时才能提供出色的性能。

有时查询的各个部分可以在我们的数据源（数据源指的是数据库或第三方 API 之类的东西）中互连。例如，我们正在加载用户帐户及其地址。它们在 GraphQL 模式中可能是两种类型，但在数据源中仅仅是一条记录。如果我们一次请求两者，我们就不会期望服务器向数据源发出两个请求。

为了解决这个问题，人们开始使用一种叫做data-loader 的模式。

数据加载器是我们 GraphQL API 中的另一层，位于解析器和数据源之间。

在简单的设置中，解析器将在更复杂的迭代中直接访问数据源，解析器将告诉数据加载器它们需要什么，然后该加载器将为它们访问数据源。

这为什么有帮助？

数据加载器可以等到所有解析器都被调用并合并对数据源的访问。

有人想加载用户账户和地址吗？现在这只是对数据源的一个请求！

这个想法是，解析器只知道它自己的要求，而数据加载器知道所有解析器想要什么，并且可以优化访问。

监控 GraphQL

如我们所见，根据我们的架构，我们可以在多个地方监控我们的 GraphQL API。

1. HTTP 端点

• 对于所有访问我们 API 的流量

1. GraphQL 查询

• 对于每个特定查询

1. GraphQL 解析器或数据加载器

• 每次访问数据源

1. 追踪

• 每次查询之后，对于解析器和数据加载器来说，它们都会影响

1.HTTP 端点

HTTP 端点是我们监控 REST API 的对象。在 GraphQL 世界中，通常只有一个端点，因此在此级别进行监控只能为我们提供有关 API 总体状态的信息。

这还不错。至少它给了我们一个起点。如果一切都正常，低延迟、低错误率、没有客户投诉、一切都很顺利，那么我们只需查看这些指标就可以节省时间和金钱。

如果有什么不对劲，我们需要深入挖掘。

2. GraphQL 查询

下一个显而易见的步骤是查看每个查询，这对于具有相当静态使用模式的 API 来说已经足够了。

如果我们仅对自己的客户使用 API，那么很明显查询不会经常更改，但如果我们的 API 可供具有不同要求的不同客户使用，事情就不再那么简单了。

突然间，我们可能会有数百个（略微）不同的查询，由于某种原因，它们都运行缓慢。

缓解此问题的一种方法是检查最常见的查询并尝试综合监控它们。这意味着我们定义一堆查询和变量组合，并从测试客户端运行它们，以检查推出新版本时它们需要多长时间。这样，我们可以降低通过更新造成重大性能下降的风险。持久查询可以帮上忙。它们是缓存最常用查询的一种方式。

如果事情超出了我们的理解范围，我们就需要采取进一步的措施。

3. 解析器和数据加载器

监控发生情况的最佳位置通常是轮胎与路面接触的地方。如果我们查看后端访问数据源的位置，我们就可以更好地掌握现实情况。

我们使用的数据源类型是否不适合访问模式？我们需要不同类型的数据库吗？

我们的数据源类型没问题，但我们应该改进对它们的请求吗？如果我们还没有使用数据加载器，是否需要它？

我们向外部 API 发送的请求是否太慢了？我们能否将数据复制到更靠近后端的位置？

当我们看到后端检索的数据是什么以及如何检索时，现在可以问所有这些问题。

这里我们还看到了数据加载器的另一个好处。解析器只允许我们监控一个解析器在做什么；数据加载器允许我们查看一个请求中所有解析器在做什么，并且还允许我们在发现解析器间问题后解决这些问题。

4. 跟踪整个堆栈

这是监控的最高原则。查询进入时，用跟踪 ID 标记查询，并在查询被解析到解析器、数据加载器甚至数据源时传递此 ID。这样，我们就可以在记录时间和错误时使用跟踪 ID，以便稍后整合它们，从而了解整体情况。

这里的想法如下：

虽然测量查询可能会为我们提供一些关于解析时间的数据，但实际的数据加载是在解析器和/或数据加载器中完成的，而不是在解析查询时完成的。

由于 GraphQL 的核心思想之一是将查询与实际数据加载分离，因此在加载数据时我们不再使用查询，但当有人发送查询时，看到后台发生的事情仍然很有趣。

结论

了解 GraphQL API 的后端是如何构建的，可以让我们对在何处监控这样的系统有更多的可行想法。

与 REST API 相比，事情确实变得有点麻烦，但 GraphQL API 中并没有什么神奇的事情发生，它只是我们可以为监控等不同目的而挂钩的代码。

如果我们在生产系统中获得了可见性，那么有关缓存和错误处理的问题也会变得更加清晰。

原文地址：https://www.moesif.com/blog/technical/monitoring/How-to-Best-Monitor-GraphQL-APIs/