GraphOS中的字段使用情况

您可以分析 由您的图发送的字段度量，该度量可以 GraphOS 从任何 版本 的 洞察 页面在 GraphOS Studio 中查看：

此页面展示 操作 和字段度量。它分为两个主要部分：

• 可折叠的左侧侧栏，其中可以搜索、过滤和排序 操作 和字段
  • 您可以访问不同类型的 字段 的洞察，这取决于您的 计划
• 右侧的主要洞察视图
  • 此视图默认显示 整体操作度量，或选中左侧侧栏中的一个字段后，将显示该字段的详细信息和使用度量。

本指南侧重于 字段 度量和信息。欲了解更多关于此页面上的其他度量信息，包括 GraphOS中的操作度量，请参阅 解析器级别跟踪。

字段使用度量可用性

在 洞察 页面上的可折叠左侧侧栏允许您筛选您想查看使用度量的 字段 类型：

所有组织都可以查看 对象字段 的使用度量，但只有具有 企业计划 的组织可以查看 输入字段 和 枚举值 的使用度量。

对象字段

所有组织都可以访问标准对象字段的使用度量。例如，给定这样一个 User 类型：

type User {
  id: ID!
  name: String!
  email: String!
  age: Int
}

所有计划都可以查看 User.id, User.name 等。

输入字段和枚举值

仅企业计划的组织可以查看输入对象字段和枚举值的 字段 使用 metrics。

例如，给定一个 UserInput 输入类型或 InventoryStatus 枚举值，例如这些：

input UserInput {
  name: String!
  email: String!
  password: String!
  address: AddressInput
}

enum InventoryStatus {
  IN_STOCK
  OUT_OF_STOCK
  DISCONTINUED
}

仅企业组织可以查看 UserInput.name, UserInput.email 等，或 InventoryStatus.IN_STOCK, InventoryStatus.OUT_OF_STOCK 等。

要访问输入和枚举 字段 metrics，您必须使用 GraphOS Router 来 报告 metrics 并在您的 router 中配置 扩展引用报告。

字段详细信息

当您点击一个 字段 名称时，您将在主 insights 视图中打开该字段的详细信息。这包括该字段首次和最后接收流量的时间，任何应用的 标签，以及提供该 字段 的 subgraphs。

下面，您可以在您的 subgraph schema 中查看 字段 定义。

接下来，您可以看到哪些客户端和 操作 对该字段的使用做出了贡献。在 Clients & Operations 表的每一行都显示了一个请求该字段的客户端，该客户端使用的字段数量，以及客户端发出的总请求数。选择一个客户端将显示请求并执行该字段的操作的更多详细信息。

以下客户端和操作，您可以查看相应字段的请求率、延迟分布和错误指标的可视化。

字段请求和执行

“客户端和操作”表格的每一行都会显示每个字段以下指标组合的一部分，具体取决于您向GraphOS报告的数据：

要使以下列在洞察页面上显示，您的GraphQL服务器必须向GraphOS报告相应的指标。如果只有部分GraphQL服务器报告此数据，洞察页将呈现您的图场字段使用的完整画面。

以下是一个请求和执行的示例字段：

如您所见，它们可能存在显著差异。以下将描述许多可能导致这种情况的原因。

列表中的对象

假设客户端执行以下查询一次：

1
query GetBooks {
2
  books {
3
    title
4
  }
5
}

如果Query.books返回一个包含十个Book对象的列表，那么Book.title将解析十次。因此，此查询仅对Book.title字段做出了一个请求，但对执行做出了十次贡献。

字段的多个引用

假设客户端执行以下查询一次：

1
query GetTwoBooks {
2
  firstBook: book(id: "123") {
3
    title
4
  }
5
  secondBook: book(id: "345") {
6
    title
7
  }
8
}

此操作包含对字段Query.book和Book.title的两次引用。因此，这些字段的解析器各自执行两次（假设Query.book不返回null）。然而，这些多次引用都是单个操作的一部分。

因此，这个查询只贡献了一个请求，但为Query.book和Book.title字段，每个字段都执行了两次。

返回接口的字段

设我们的GraphQL服务器's模式定义以下接口和对象类型：

1
interface Media {
2
  title: String!
3
}
4

5
type Book implements Media {
6
  title: String!
7
  author: String!
8
}
9

10
type Query {
11
  favoriteMedia: Media!
12
}

现在让我们假设一个客户端执行以下查询：

1
query GetFavoriteMedia {
2
  favoriteMedia {
3
    title
4
  }
5
}

如果Query.favoriteMedia在这里返回一个Book对象，则Book.title只被调用一次。但是，原始的查询没有引用Book.title。而是引用Media.title，因为Query.favoriteMedia的返回类型是Media。

因此，这个查询为Book.title贡献了零请求和一次执行。它亦贡献了一个请求用于Media.title。请注意，接口字段始终为零执行。

未解析的请求字段

假设客户端执行以下查询一次：

1
query GetLoggedInUser {
2
  loggedInUser {
3
    name
4
  }
5
}

现在，假设Query.loggedInUser返回null，因为没有用户登录。在这种情况下，因为父级返回null，User.name的解析器从未执行。因此，这个查询为User.name贡献了一个请求和零执行。

以下任何一个原因都可能导致请求的字段没有解析：

• 该字段嵌套在一个返回null的字段下面，如上所示。
• 该字段嵌套在一个返回列表的字段下面，但该列表为空。
• 该字段属于一个不适用于特定对象的片段。
• 由于@skip或@include指令，解析器被跳过。

@key和@requires字段在联合图中的使用

假设我们的联合图包含以下这两个子图模式：

type Product @key(fields: "id") {
  id: ID!
  name: String!
}

extend type Product @key(fields: "id") {
  id: ID! @external
}

type Review {
  id: ID!
  score: Int!
  product: Product!
}

type Query {
  reviews: [Review!]!
}

现在让我们假设一个客户端执行以下查询：

1
query GetAllReviews {
2
  reviews {
3
    score
4
    product {
5
      name
6
    }
7
  }
8
}

此 查询's 执行从 Reviews 子图 开始，但它需要从 Products 产品's 子图中获取每个 产品 的名称。

为了帮助解析这些引用，Reviews subgraph 必须返回每个 产品's id 字段，即使该字段不包括在原始 查询 中。

因此，此 查询 为 Product.id 提供了零个请求和一次执行。