了解 Firestore 中的性能监控

Cloud Monitoring 会从 Google Cloud 产品中收集指标、事件和元数据。您还可以通过 Cloud Monitoring 访问“使用情况”信息中心安全规则使用情况中报告的数据,以进行更详细的分析。借助 Cloud Monitoring,您还可以设置自定义信息中心和使用情况提醒。

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

受监控的资源

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

使用 Cloud Monitoring API,您可以通过以下资源监控 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
firestore_instance Firestore 项目的受监控资源类型,不提供数据库的细分数据。 适用于 Firestore 原生模式
datastore_request Datastore 项目的受监控资源类型,不提供数据库的细分数据。 适用于这两种模式。

指标

Firestore 提供两种不同的模式: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 响应,这意味着数据库运行状况良好。

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 会提供读取、写入和删除次数。写入指标会按“CREATE”和“UPDATE”操作进行细分。这些指标与 CRUD 操作保持一致。

您可以使用以下指标了解数据库是读取密集型还是写入密集型,以及新文档与已删除文档的比率。

  • document/delete_ops_count:成功删除文档的次数。
  • document/read_ops_count:通过查询或查找成功读取文档的次数。
  • document/write_ops_count:成功写入文档的次数。
创建文档读取次数与文档写入次数的比率
图 6. 创建读取文档与写入文档的比率(点击可放大)。

在图 6 中,您可以了解如何创建一个比率,以显示已读文档与已写文档的比率。在此示例中,读取的文档数量比写入的文档数量多约 6%。

文档操作指标

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

例如,文档操作指标使用 datastore_request 监控资源,因此没有服务或方法细分。

  • entity/read_sizes:读取文档大小的分布情况。
  • entity/write_sizes:书面文档大小的分布。

索引指标

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

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

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

使用 Firebase SDK 直接连接到数据库的客户端

两个指标可用于跟踪通过移动 SDK 和/或 Web SDK 直接连接到 Firestore 数据库的客户端的活动。这些指标包括与实时快照监听器相关的功能,该功能会将数据库中的相关更改立即流式传输回客户端。

  • network/active_connections:相应时间点的活跃连接数。每个网站或移动客户端都有一个连接。
  • network/snapshot_listeners:所有已连接客户端中当前注册的快照监听器数量。每个客户端可能有多个连接。

您可以在 Firebase 控制台中的 Firestore 数据库的 Usage 标签页中查看这些指标。

用于跟踪与 Firestore 连接的客户端活动的指标
图 8. 用于跟踪连接到 Firestore 的客户端活动的指标。

TTL 指标

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

  • document/ttl_deletion_count:TTL 服务删除的文档总数。
TTL 服务删除的文档总数
图 9. TTL 服务删除的文档总数(点击可放大)。

在图 9 中,您可以查看一段时间内每分钟删除文档的速率。

  • document/ttl_expiration_to_deletion_delays:具有 TTL 的文档到期与实际删除之间的间隔时间。
Firestore 删除具有 TTL 政策的文档所用的时间(以秒为单位)
图 10. Firestore 删除具有 TTL 政策的文档所用时间(以秒为单位)(点击可放大)。

在图 10 中,您可以看到此指标提供了 Firestore 删除具有 TTL 政策的文档所用时间(以秒为单位)的分布情况。在第 99 百分位,删除 TTL 已过期的文档需要不到 0.5 秒的时间。这意味着系统正常运行。Firestore 通常会在 24 小时内删除过期文档,但不能保证一定会。如果超过 24 小时仍未看到展示次数,请与支持团队联系

后续步骤