了解 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_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 小时,请与支持团队联系

后续步骤