监控和日志记录 - Amazon AppSync
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

监控和日志记录

监控Amazon AppSync GraphQL API 并帮助调试与请求相关的问题,你可以开启日志记录到亚马逊 CloudWatch 日志。

设置和配置

要在 GraphQL API 上开启自动日志记录,请使用Amazon AppSync 控制台。

  1. 登录到AmazonAppSync 控制台.

  2. 在存储库的API页面上,选择 GraphQL API 的名称。

  3. 在 API 的主页的导航窗格中,选择设置.

  4. Logging (日志记录) 下,执行以下操作:

    1. 启用 。启用日志.

    2. (可选)要详细的请求级日志记录,请选中下的复选框。包括详细内容.

    3. (可选)下字段解析程序日志级别中,选择首选的字段级别日志记录级别(错误,或者全部)。

    4. 创建或使用现有角色,选择新角色创建新的Amazon Identity and Access Management(IAM) 允许Amazon AppSync 将日志写入 CloudWatch。或者,选择现有角色在您的中选择现有 IAM 角色的 Amazon 资源名称 (ARN)Amazonaccount.

  5. 选择 Save(保存)。

手动配置 IAM 角色

如果您选择使用现有的 IAM 角色,则该角色必须授予该角色。Amazon AppSync 将日志写入 CloudWatch 所需的权限。要手动配置此功能,必须提供服务角色 ARN 以便Amazon AppSync 可以在编写日志时担任该角色。

IAM 控制台中,使用名称创建新策略AWSAppSyncPushToCloudWatchLogsPolicy具有以下定义:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] }

接下来,使用名称创建新的角色Amazon AppSyncpushtoCloudWatch LogsRole,然后将新创建的策略附加到该角色。将此角色的信任关系编辑为以下内容:

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "appsync.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }

复制角色 ARN 并在为Amazon AppSync GraphQL API。

CloudWatch 指标

您可以使用 CloudWatch 指标,用于监控并提供有关特定事件的提醒,这些事件可能导致 HTTP 状态代码或延迟。将发出以下指标。

4XXError

由于客户端配置不正确,导致请求无效而导致的错误。通常,这些错误在 GraphQL 之外的任意位置处理. 例如,当请求包含不正确的 JSON 负载或不正确的查询、服务受到限制或授权设置出现配置错误时,可能会发生这些错误。

单位计数. 使用 Sum 统计数据以得出这些错误的总出现次数。

5XXError

期间遇到的错误正在运行GraphQL 查询。例如,当调用查询以查询空或不正确的架构时,可能会发生这种错误。当 Amazon Cognito 用户池 ID 或Amazon区域无效。或者,如果这种情况也可能发生Amazon AppSync 在处理请求过程中遇到问题。

单位计数. 使用 Sum 统计数据以得出这些错误的总出现次数。

Latency

从 Amazon AppSync 从客户端收到请求到其将响应返回给客户端所经过的时间。这不包括响应进入终端设备所遇到的网络延迟。

单位毫秒. 使用平均值统计数据可评估预期延迟。

Requests

您账户中所有 API 处理的请求(查询 + 突变)的数量,按地区划分。

单位计数. 在特定地区处理的所有请求的数量。

TokensConsumed

令牌被分配给Requests基于资源量(处理时间和使用的内存)Request使用。通常,每个Request消耗一个令牌。但是,Request消耗大量资源的人会根据需要分配额外的令牌。

单位计数. 分配给特定区域中处理的请求的令牌数量。

实时订阅

所有指标都在一个维度中发出:GraphQLAPIId. 这意味着所有指标都与 GraphQL API ID 相结合。以下指标与纯 WebSockets 上的 GraphQL 订阅相关:

ConnectSuccess

成功的数量 WebSocket 连接到AmazonAppSync。可以在没有订阅的情况下进行连接。

单位计数. 使用 Sum 统计数据可得出成功连接的总出现次数。

ConnectClientError

的数量 WebSocket 被拒绝的连接Amazon AppSync 由于客户端错误。这可能意味着服务受到限制或授权设置出现配置错误。

单位计数. 使用 Sum 统计数据以得出客户端连接错误的总出现次数。

ConnectServerError

处理连接时源自 Amazon AppSync 的错误数。当出现意外的服务器端问题时,通常会发生这种错误。

单位计数. 使用 Sum 统计数据以得出服务器端连接错误的总出现次数。

DisconnectSuccess

成功的数量 WebSocket 断开AmazonAppSync。

单位计数. 使用 Sum 统计数据可得出成功断开连接的总出现次数。

DisconnectClientError

源自的客户端错误数量Amazon AppSync 断开连接 WebSocket 连接。

单位计数. 使用 Sum 统计数据可得出断开连接错误的总出现次数。

DisconnectServerError

源自的服务器错误数量Amazon AppSync 断开连接 WebSocket 连接。

单位计数. 使用 Sum 统计数据可得出断开连接错误的总出现次数。

SubscribeSuccess

已成功注册到的订阅数。Amazon使用 WebSocket 实现 AppSync。可以在没有订阅的情况下建立连接,但无法在没有连接的情况下进行订阅。

单位计数. 使用 Sum 统计数据以得出成功订阅的总发生次数。

SubscribeClientError

由于客户端错误而被 Amazon AppSync 拒绝的订阅数。当 JSON 负载不正确、服务受到限制或授权设置出现配置错误时,可能会发生这种错误。

单位计数. 使用 Sum 统计数据以得出客户端订阅错误的总出现次数。

SubscribeServerError

处理订阅时源自 Amazon AppSync 的错误数。当出现意外的服务器端问题时,通常会发生这种错误。

单位计数. 使用 Sum 统计数据以得出服务器端订阅错误的总出现次数。

UnsubscribeSuccess

已成功处理的取消订阅请求的数量。

单位计数. 使用 Sum 统计数据以得出成功取消订阅请求的总出现次数。

UnsubscribeClientError

被拒绝的取消订阅请求的数量。Amazon AppSync 由于客户端错误。

单位计数. 使用 Sum 统计数据以得出客户端取消订阅请求错误的总出现次数。

UnsubscribeServerError

源自的错误数量Amazon AppSync 同时处理取消订阅请求。当出现意外的服务器端问题时,通常会发生这种错误。

单位计数. 使用 Sum 统计数据以得出服务器端取消订阅请求错误的总出现次数。

PublishDataMessageSuccess

已成功发布的订阅事件消息的数量。

单位计数. 使用 Sum 统计数据以得出成功发布的订阅事件消息的总数。

PublishDataMessageClientError

由于客户端错误而无法发布的订阅事件消息的数量。

Unit计数. 使用 Sum 统计数据以得出客户端发布订阅事件错误的总出现次数。

PublishDataMessageServerError

发布订阅事件消息时源自 Amazon AppSync 的错误数。当出现意外的服务器端问题时,通常会发生这种错误。

单位计数. 使用 Sum 统计数据以得出服务器端发布订阅事件错误的总出现次数。

PublishDataMessageSize

已发布的订阅事件消息的大小。

单位字节.

ActiveConnections

并行的数量 WebSocket 从客户端到的连接Amazon AppSync 在 1 分钟内。

单位计数. 使用 Sum 统计数据以得出建立的连接总数。

ActiveSubscriptions

1 分钟内来自客户端的并发订阅数。

单位计数. 使用 Sum 统计数据以得出有效订阅的总数。

ConnectionDuration

连接保持打开状态的时间量。

单位毫秒. 使用 Average 统计数据可评估连接持续时间。

InvalidationSuccess

由于变异而成功使(取消订阅)失效(取消订阅)的订阅数量$extensions.invalidateSubscriptions().

单位计数. 使用 Sum 统计数据以检索已成功取消订阅的订阅总数。

CloudWatch Logs

您可以对任何新的或现有的 GraphQL API 配置两种类型的日志记录:请求级别和字段级别。

请求级别日志

当请求级别日志记录时 (包括详细内容) 配置后,系统会记录以下信息:

  • 所使用的代币数量

  • 请求和响应 HTTP 标头

  • 请求中运行的 GraphQL 查询

  • 整体操作摘要

  • 已注册的新的和现有的 GraphQL 订阅

字段级别日志

配置字段级日志记录时,系统会记录以下信息:

  • 生成的请求映射以及每个字段的源和参数。

  • 每个字段的转换后的响应映射,其中包括作为解析该字段的结果的数据

  • 每个字段的跟踪信息

如果您启用日志记录,Amazon AppSync 管理 CloudWatch 日志。该过程包括创建日志组和日志流,以及向日志流报告这些日志。

当您开启 GraphQL API 的日志记录并发起请求时,Amazon AppSync 创建日志组和日志组下的日志流。日志组以 /aws/appsync/apis/{graphql_api_id} 格式命名。在每个日志组内,日志会进一步分成多个日志流。当报告已记录的数据时,这些日志按上次事件时间排序。

每个日志事件都用该请求的 x-amzn-RequestId 进行标记。这可以帮助你过滤中的日志事件 CloudWatch 以获取有关该请求的所有记录信息。您可以获取 RequestId 从每个 GraphQL 的响应标头Amazon AppSync 请求.

字段级别日志记录配置为使用以下日志级别:

  • -未捕获任何字段级别的日志。

  • 错误-记录以下信息仅限对于出现错误的字段:
    • 服务器响应中的错误部分

    • 字段级别错误

    • 所生成的请求/响应函数,已针对错误字段获得解析

  • 全部-记录以下信息所有查询中的字段:
    • 字段级别跟踪信息

    • 所生成的请求/响应函数,已针对每个字段获得解析

监控的优势

您可以使用日志记录和指标来识别、优化 GraphQL 查询和排除其问题。例如,这些将帮助您使用针对查询中的每个字段记录的跟踪信息调试延迟问题。为了对此进行演示,假设您正在使用一个或多个嵌套在 GraphQL 查询中的解析程序。中的示例现场操作 CloudWatch 日志可能类似于以下内容:

{ "path": [ "singlePost", "authors", 0, "name" ], "parentType": "Post", "returnType": "String!", "fieldName": "name", "startOffset": 416563350, "duration": 11247 }

这可能对应于 GraphQL 架构,类似于以下内容:

type Post { id: ID! name: String! authors: [Author] } type Author { id: ID! name: String! } type Query { singlePost(id:ID!): Post }

在上述日志结果中,路径显示从运行名为的查询所返回的数据中的单个项目。singlePost(). 在此示例中,它表示名称位于第一个索引 (0) 处的字段。这些区域有:startOffset给出 GraphQL 查询操作开始时的偏移量。这些区域有:持续时间是解析该字段的总时间。这些值可用来排除下面这类问题:为何来自特定数据源的数据的运行速度可能低于预期,或者特定字段是否降低了整个查询的速度等。例如,您可能选择增加 Amazon DynamoDB 表的预配置吞吐量,或者从查询中删除导致整体操作效果不佳的某个字段。

截至 2019 年 5 月 8 日,Amazon AppSync 生成日志事件为完全结构化的 JSON。这可以帮助你使用日志分析服务,例如 CloudWatch 日志 Insights 和亚马逊 OpenSearch 了解 GraphQL 请求的性能和架构字段的使用特征的服务。例如,您可以轻松识别具有较大延迟的解析程序,这可能是导致性能问题的根本原因。您还可以识别架构中最常用和最不常用的字段,并评估弃用 GraphQL 字段的影响。

冲突检测和同步日志记录

如果Amazon AppSync API 已登录 CloudWatch 配置了日志字段解析程序日志级别设置为全部,那么Amazon AppSync 向日志组发送冲突检测和解决方案信息。这提供了细致的洞察力,了解Amazon AppSync API 对冲突做出了回应。为此,为此,日志中提供以下信息:

conflictType

详细说明是否由于版本不匹配或由于客户提供的状况而发生冲突。

conflictHandlerConfigured

说明请求时在解析程序上配置了冲突处理程序。

message

提供有关如何检测和解决冲突的信息。

syncAttempt

服务器在最终拒绝请求之前尝试同步数据的次数。

data

如果配置的冲突处理程序是Automerge,填充此字段以显示什么决策Automerge每个字段都采取了。提供的操作可以是:

  • 被拒绝-当您时Automerge拒绝传入字段值,而是使用服务器中的值。

  • 添加-当您时Automerge由于服务器中没有预先存在的值,因此添加传入字段。

  • 附加的-当您时Automerge将传入值追加到存在于服务器中的列表的值。

  • 合并-当您时Automerge将传入值合并到服务器中存在的集的值。

使用令牌计数来优化您的请求

消耗少于或等于 1,500 KB 秒内存和 vCPU 时间的请求将分配一个令牌。资源消耗大于 1,500 KB 秒的请求将获得额外的令牌。例如,如果请求耗时 3,350 KB 秒,Amazon AppSync 为请求分配三个令牌(向上舍入到下一个整数值)。默认情况下,Amazon AppSync 每秒最多为 2,000 个请求令牌分配给您账户中的 API,每Amazon区域。如果您的 API 每秒平均使用两个令牌,则每秒限制为 1,000 个请求。如果您每秒需要的令牌超过分配的金额,则可以提交请求以提高请求令牌速率的默认配额。有关更多信息,请参阅 。AmazonAppSync 终端节点和配额中的Amazon一般参考指南请求增加配额中的Service Quotas 用户指南.

较高的每个请求令牌数可能表明有机会优化请求并提高 API 的性能。可以增加每个请求令牌数量的因素包括:

  • GraphQL 架构的规模和复杂性。

  • 请求和响应映射模板的复杂性。

  • 每个请求的解析器调用次数。

  • 从解析器返回的数据量。

  • 下游数据源的延迟。

  • 需要连续数据源调用(而不是并行或批量调用)的架构和查询设计。

  • 日志配置,特别是字段级和详细的日志内容。

注意

此外Amazon AppSync 指标和日志,客户端可以通过响应标头访问请求中使用的令牌数量x-amzn-appsync-TokensConsumed.

日志类型引用

RequestSummary

  • requestId:请求的唯一标识符。

  • graphQLAPIId:发出请求的 GraphQL API 的 ID。

  • :statusCode HTTP 状态代码响应。

  • :延迟 请求的端到端延迟,以纳秒为单位,整数值。

{ "logType": "RequestSummary", "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1", "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4", "statusCode": 200, "latency": 242000000 }

ExecutionSummary

  • requestId:请求的唯一标识符。

  • graphQLAPIId:发出请求的 GraphQL API 的 ID。

  • startTime:处理请求的 GraphQL 的开始时间戳,采用 RFC 3339 格式。

  • :endTime uration 处理请求的 GraphQL 的结束时间戳,采用 RFC 3339 格式。

  • :Duration 经过的总 GraphQL 处理时间,以纳秒为单位,整数值。

  • 版本:ExecutionSummary 的架构版本。

  • parsing:
    • startOffset:解析的开始偏移,以纳秒为单位,与调用相对,整数值。

    • :Duration 解析所花费的时间,以纳秒为单位,整数值。

  • validation:
    • startOffset:验证的开始偏移,以纳秒为单位,与调用相对,整数值。

    • :Duration 执行验证所花费的时间,以纳秒为单位,整数值。

{ "duration": 217406145, "logType": "ExecutionSummary", "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1", "startTime": "2019-01-01T06:06:18.956Z", "endTime": "2019-01-01T06:06:19.174Z", "parsing": { "startOffset": 49033, "duration": 34784 }, "version": 1, "validation": { "startOffset": 129048, "duration": 69126 }, "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4" }

跟踪

  • requestId:请求的唯一标识符。

  • graphQLAPIId:发出请求的 GraphQL API 的 ID。

  • startOffset:字段解析的开始偏移,以纳秒为单位,与调用相对,整数值。

  • :Duration 解析字段所花费的时间,以纳秒为单位,整数值。

  • fieldName: 所解析字段的名称。

  • parentType:所解析字段的父类型。

  • returnType:所解析字段的返回类型。

  • 路径:路径分段列表,从响应的根开始,以所解析字段结束。

  • resolverArn:用于字段解析的解析器的 ARN。可能不会出现在嵌套字段中。

{ "duration": 216820346, "logType": "Tracing", "path": [ "putItem" ], "fieldName": "putItem", "startOffset": 178156, "resolverArn": "arn:aws:appsync:us-east-1:111111111111:apis/pmo28inf75eepg63qxq4ekoeg4/types/Mutation/fields/putItem", "requestId": "dbe87af3-c114-4b32-ae79-8af11f3f96f1", "parentType": "Mutation", "returnType": "Item", "graphQLAPIId": "pmo28inf75eepg63qxq4ekoeg4" }

使用分析日志 CloudWatch 日志见解

以下是您可以运行的查询示例,以获取有关 GraphQL 操作的性能和运行状况的可行的见解。这些示例可作为示例查询提供在 CloudWatch 日志 Insights 控制台。在CloudWatch 控制台,选择日志见解中,选择Amazon AppSync GraphQL API 的日志组,然后选择Amazon AppSync查询示例查询.

以下查询返回具有最大令牌消耗的前 10 个 GraphQL 请求:

filter @message like "Tokens Consumed" | parse @message "* Tokens Consumed: *" as requestId, tokens | sort tokens desc | display requestId, tokens | limit 10

以下查询返回具有最大延迟的前 10 个解析程序:

fields resolverArn, duration | filter logType = "Tracing" | limit 10 | sort duration desc

以下查询返回最常调用的解析程序:

fields ispresent(resolverArn) as isRes | stats count() as invocationCount by resolverArn | filter isRes and logType = "Tracing" | limit 10 | sort invocationCount desc

以下查询返回映射模板中具有最多错误的解析程序:

fields ispresent(resolverArn) as isRes | stats count() as errorCount by resolverArn, logType | filter isRes and (logType = "RequestMapping" or logType = "ResponseMapping") and fieldInError | limit 10 | sort errorCount desc

以下查询返回解析程序延迟统计数据:

fields ispresent(resolverArn) as isRes | stats min(duration), max(duration), avg(duration) as avg_dur by resolverArn | filter isRes and logType = "Tracing" | limit 10 | sort avg_dur desc

以下查询返回字段延迟统计数据:

stats min(duration), max(duration), avg(duration) as avg_dur by concat(parentType, '/', fieldName) as fieldKey | filter logType = "Tracing" | limit 10 | sort avg_dur desc

的结果 CloudWatch Logs Insights 查询可以导出到 CloudWatch 控制面板。

使用分析日志 OpenSearch 服务

你可以搜索、分析和可视化Amazon AppSync 使用 Amazon 进行日志 OpenSearch 确定性能瓶颈和运营问题的根本原因的服务。您可以识别具有最大延迟和最多错误的解析程序。此外,您还可以使用 OpenSearch 用于创建具有强大可视化效果的仪表板。 OpenSearch Destboard 是中提供的开源数据可视化和挖掘工具。 OpenSearch 服务 。使用 OpenSearch 控制面板,您可以持续监控 GraphQL 操作的性能和运行状况。例如,您可以创建控制面板以可视化 GraphQL 请求的 P90 延迟,并深入了解每个解析程序的 P90 延迟。

使用时间 OpenSearch 服务,使用“cwl*”作为搜索的筛选器模式 OpenSearch 索引。 OpenSearch 服务为流式传输的日志编制索引 CloudWatch 前缀为的日志“cwl-”. 为了区分Amazon AppSync 来自其他 API 日志 CloudWatch 发送到的日志 OpenSearch 服务,我们建议添加额外的过滤器表达式graphQLAPIID.keyword=YourGraphQLAPIID到你的搜索中。

日志格式迁移

记录事件Amazon AppSync 在 2019 年 5 月 8 日或之后生成的生成的格式为完全结构化的 JSON。要在 2019 年 5 月 8 日之前分析 GraphQL 请求,您可以使用GitHub 示例. 如果需要在 2019 年 5 月 8 日之前使用日志格式,请使用以下设置创建支持服务单:将 Type (类型) 设置为 Account Management (账户管理),然后将 Category (类别) 设置为 General Account Question (一般账户问题)

您还可以使用指标筛选器在 CloudWatch 将日志数据转换为数字 CloudWatch 指标,以便对它们生成图表或设置警报。