了解 Datastore 模式 Firestore 中的性能监控

Cloud Monitoring 会从 Google Cloud 产品中收集指标、事件和元数据。借助 Cloud Monitoring,您还可以设置自定义信息中心和使用情况提醒。

本文档将引导您使用指标、了解自定义指标信息中心以及设置提醒。

受监控的资源

Cloud Monitoring 中的受监控的资源表示逻辑或实体,例如虚拟机、数据库或应用。受监控的资源包含一组独特的指标,可供探索、通过信息中心生成报告或用于创建提醒。每个资源还具有一组资源标签,这些标签是键值对,用于存储资源的其他信息。资源标签适用于与资源关联的所有指标。

您可以使用 Cloud Monitoring API 通过以下资源监控 Datastore 模式 Firestore 的性能:

资源 说明 支持的数据库模式
firestore.googleapis.com/Database(推荐) 受监控的资源类型,用于提供 projectlocation* 和 database_id 的细分数据。对于未使用特定名称创建的数据库,database_id 标签将为 (default) 这两种模式都支持的所有指标,但 Datastore 模式下的 Firestore 不支持以下指标:
  • document/delete_ops_count
  • document/read_ops_count
  • document/write_ops_count
datastore_request Datastore 项目的受监控资源类型,不提供数据库的细分数据。

指标

Firestore 提供两种不同的模式:Firestore 原生模式和 Datastore 模式下的 Firestore。如需了解这两种模式之间的功能对比,请参阅选择数据库模式

如需查看 Datastore 模式 Firestore 的指标完整列表,请参阅 Datastore 模式 Firestore 指标

服务运行时指标

serviceruntime 指标可让您大致了解项目的流量。大多数 Google Cloud API 都提供这些指标。consumed_api 受监控的资源类型包含这些常见指标。系统会每 30 分钟对这些指标进行一次抽样,以平滑数据。

serviceruntime 指标的一项重要资源标签是 method。此标签代表调用的底层 RPC 方法。您调用的 SDK 方法的名称不一定与底层 RPC 方法的名称相同。原因在于该 SDK 提供了高级 API 抽象。不过,在尝试了解应用如何与 Firestore 交互时,请务必根据 RPC 方法的名称了解相关指标。

如果您需要了解给定 SDK 方法的底层 RPC 方法是什么,请参阅 API 文档

api/request_count

此指标会按协议(请求协议,例如 http、gRPC 等)、响应代码(HTTP 响应代码)、response_code_class(响应代码类,例如 2xx、4xx 等)和 grpc_status_code数字 gRPC 响应代码)提供已完成请求的数量。使用此指标可观察总体 API 请求并计算错误率。

返回 2xx 代码的 api/request_count 指标。
图 1。api/request_count 指标(点击可放大)。

在图 1 中,您可以看到返回 2xx 代码的请求(按服务和方法分组)。2xx 代码是 HTTP 状态代码,表示请求成功。

返回 2xx 代码的 api/request_count 指标。
图 2:返回 2xx 代码的 api/request_count 指标(点击可放大)。

在图 2 中,您可以看到按 response_code 分组的提交。在此示例中,我们只看到 HTTP 200 响应,这意味着数据库运行状况良好。

使用以下服务运行时指标监控数据库。

datastore_request 资源类型中的 api/request_count

api/request_count 指标也适用于 datastore_request 资源类型,并提供 api_methodresponse_code 细分。请改用此指标,以利用更精细的抽样周期,这有助于捕获峰值。

datastore_request 资源下的 api/request_count 指标
图 3. datastore_request 资源下的 api/request_count 指标(点击可放大)。
api/request_latencies

api/request_latencies 指标提供所有已完成请求的延迟时间分布。

Firestore 会记录 Firestore 服务组件中的指标。延迟时间指标包括 Firestore 收到请求到 Firestore 完成发送响应的时间,包括与存储层的互动。因此,这些指标不包含客户端和 Firestore 服务之间的往返延迟时间 (rtt)。

api/request_latencies,用于计算延迟时间分布
图 4. 用于计算延迟时间分布的 api/request_latencies。
api/request_sizes 和 api/response_sizes

api/request_sizesapi/response_sizes 指标分别可深入了解有效载荷大小(以字节为单位)。这些信息有助于了解发送大量数据或查询过于宽泛且返回大型载荷的写入工作负载。

api/request_sizes 和 api/response_sizes 指标
图 5. api/request_sizes 和 api/response_sizes 指标(点击可放大)。

在图 5 中,您可以看到 RunQuery 方法的响应大小热图。我们可以看到,大小稳定,中位数为 50 字节,总体介于 10 字节到 100 字节之间。请注意,载荷大小始终以未压缩的字节为单位(不包括传输控制开销)。

实体操作指标

这些指标提供读取(查找和查询)和对 Firestore 数据库写入的载荷大小(以字节为单位)的分布情况。这些值表示载荷的总大小。例如,查询返回的任何结果。这些指标与 api/request_sizesapi/response_sizes 指标类似,主要区别在于实体操作指标提供更精细的抽样,但细分程度较低。

例如,实体操作指标使用 datastore_request 监控资源,因此不会按服务或方法进行细分。

  • entity/read_sizes:读取实体大小的分布情况(按类型分组)。
  • entity/write_sizes:已写入实体的大小分布情况,按操作分组。

索引指标

您可以将索引写入速率与 document/write_ops_count 指标进行对比,以了解 索引扇出比率

  • index/write_count:索引写入次数。
索引写入速率与文档写入速率的对比
图 7. 索引写入速率与文档写入速率对比(点击可放大)。

在图 7 中,您可以了解如何将索引写入速率与文档写入速率进行对比。在此示例中,对于每次文档写入,大约有 6 次索引写入,这是一个相对较小的索引扇出率。

TTL 指标

TTL 指标适用于 Firestore 原生数据库和 Datastore 模式 Firestore 数据库。使用这些指标可监控强制执行的 TTL 政策的影响。

  • entity/ttl_deletion_count:TTL 服务删除的实体总数。
  • entity/ttl_expiration_to_deletion_delays:具有 TTL 的实体到期与实际删除之间的间隔时间。

    如果您发现 TTL 删除延迟时间超过 24 小时,请与支持团队联系

后续步骤