[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-25。"],[],[],null,["# Monitor databases with Cloud Monitoring\n=======================================\n\nThis page describes how to use Cloud Monitoring metrics for Firestore with MongoDB compatibility\nto monitor your database.\n\nCloud Monitoring metrics for Firestore with MongoDB compatibility\n-----------------------------------------------------------------\n\nThe following sections give an overview of the metrics available for\nFirestore with MongoDB compatibility.\n\n### Monitored Resources\n\nA monitored resource in Cloud Monitoring represents a logical or physical\nentity, such as a virtual machine, a database, or an application. Monitored\nresources contain a unique set of metrics that can be explored, reported through\na dashboard, or used to create alerts. Each resource also has a set of resource\nlabels, which are key-value pairs that hold additional information about the\nresource. Resource labels are available for all metrics associated with the\nresource.\n\nUsing the\n[Cloud Monitoring API](https://cloud.google.com/monitoring/api/resources),\nFirestore with MongoDB compatibility performance is monitored with the following resource:\n\n### Metrics\n\nFor a complete list of metrics for Firestore, see\n[Firestore metrics](https://cloud.google.com/monitoring/api/metrics_gcp_d_h#gcp-firestore).\nThe following section describes some of the available metrics.\n\n### Service runtime metrics\n\nThe [`serviceruntime`](https://cloud.google.com/monitoring/api/metrics_gcp_p_z#gcp-serviceruntime)\nmetrics provide a high-level overview of a project's traffic. These metrics are\navailable for most Google Cloud APIs. The\n[`consumed_api`](https://cloud.google.com/monitoring/api/resources#tag_consumed_api)\nmonitored resource type contains these common metrics. These metrics are sampled\nevery 30 minutes resulting in data being smoothed out.\n\nAn important resource label for the `serviceruntime` metrics is `method`. This\nlabel represents the underlying RPC method called. The SDK method that you call\nmay not necessarily be named the same as the underlying RPC method. The reason\nis that the SDK provides high-level API abstraction. However, when trying to\nunderstand how your application interacts with Firestore, it is\nimportant to understand the metrics based on the name of the RPC method.\n\nIf you need to know what the underlying RPC method is for a given SDK method,\nsee the [API documentation](https://cloud.google.com/firestore/docs/reference/rpc/google.firestore.v1).\n\n#### api/request_latencies\n\nThe `api/request_latencies` metric provides latency distributions across all\ncompleted requests.\n\nFirestore records metrics from the **Firestore Service**\ncomponent. Latency metrics include the time that Firestore receives\nthe request to the time that Firestore finishes sending the response,\nincluding interactions with the storage layer. Due to this, round-trip latency\n(rtt) between the client and the Firestore service is not included in\nthese metrics.\n\n### Document operation metrics\n\nFirestore provides read, write, and delete counts. The write\nmetric provides a breakdown between the 'CREATE' and 'UPDATE' operation. These\nmetrics are aligned with CRUD operations.\n\nThe following metrics can be used to understand whether your database is read\nheavy or write heavy, and the rate of new documents versus deleted documents.\n\n- `document/delete_ops_count`: The number of successful document deletes.\n- `document/read_ops_count`: The number of successful document reads from queries or lookups.\n- `document/write_ops_count`: The number of successful document writes.\n\n| **Note:** The `document/delete_ops_count` metric doesn't include documents deleted because of TTL policies. For information about metrics that capture deletes due to TTL policies, see [TTL Metrics](#ttl_metrics).\n\n### Billing metrics\n\nUse these metrics to understand billing usage. These metrics don't\ninclude billing from administrator operations (indexing, import, export, and\nbulk delete).\n\n- `api/billable_read_units`: The number of billable read units.\n Usage can be broken down by service name and API method.\n\n- `api/billable_write_units`: The number of billable write units.\n Usage can be broken down by service name and API method.\n\n- `document/billable_managed_delete_write_units`: The number of billable\n write units from managed delete services like [TTL](/firestore/mongodb-compatibility/docs/ttl).\n\n### Index metrics\n\nIndex write rates can be contrasted with the `document/write_ops_count` metric\nto understand index fanout.\n\n- `index/write_count`: Count of index writes.\n\n### TTL Metrics\n\nThe TTL metrics for Firestore with MongoDB compatibility metrics are used to\nmonitor the effect of the [TTL policy](/firestore/mongodb-compatibility/docs/ttl) enforced.\n\n- `document/ttl_deletion_count`: Total count of documents deleted by TTL services.\n- `document/ttl_expiration_to_deletion_delays`: Time elapsed between when a document with a TTL expired, and when it was actually deleted.\n\nView predefined dashboards and create custom dashboards\n-------------------------------------------------------\n\nFirestore with MongoDB compatibility supports predefined dashboards that use Cloud Monitoring metrics.\nYou can also create custom dashboards.\n\n### View database usage metrics\n\nOpen the usage dashboards in the Google Cloud console to view\ndocument reads, writes, and deletes over time.\n\n#### Access control\n\nThe usage dashboards require the `monitoring.timeSeries.list` Identity and Access Management (IAM) permission.\nThe Project Owner, Editor, and Viewer roles grant this permission. You can also grant this permission\nthrough a [Cloud Monitoring role](https://cloud.google.com/monitoring/access-control#monitoring_2)\nor a [custom role](https://cloud.google.com/iam/docs/creating-custom-roles).\n\n#### Database usage dashboard\n\nTo view usage metrics for a Firestore with MongoDB compatibility database, do the following.\n\n1. In the Google Cloud console, go to the **Databases** page.\n\n [Go to Databases](https://console.cloud.google.com/firestore/databases)\n2. Select the required database from the list of databases.\n\n3. In the navigation menu, click **Usage**.\n\n#### Usage dashboard and billing reports\n\nThe Firestore usage dashboards in the console\nprovide an estimate of usage. They can help you identify spikes in usage.\nHowever, the dashboard is not an exact view of billed operations. Billed usage\nis likely higher. To monitor billing, see [billing metrics](#billing_metrics).\n\nIn all cases of discrepancy, the billing report takes\nprecedence over the usage dashboard.\n\nImport and export operations cause discrepancies between the usage dashboard\nand billed usage. Reads and writes performed by these\noperations don't show up in the usage dashboard.\n\n### View database performance metrics\n\nThe **Monitoring** page in the Firestore section of the\nGoogle Cloud console includes predefined monitoring dashboards such as\n**Request Latencies (P50 and P99)** , **Response Codes** , and **Query stats (P50)** .\nYou can also create up to one custom dashboard. To access the **Monitoring**\npage for a database, follow these steps:\n\n1. In the Google Cloud console, open the Firestore **Databases**\n page.\n\n\n [Go to Databases](https://console.cloud.google.com/firestore/databases)\n\n \u003cbr /\u003e\n\n2. Select a database from the list.\n\n3. In the navigation menu, click **Monitoring** to open a dashboard.\n\n### Create custom Cloud Monitoring dashboards\n\nIn Cloud Monitoring, custom dashboards allow you to display information that\nis relevant to you in an organized way. For example, you might create a\ndashboard to display the performance metrics and alerting policies for your\nproject in your production environment.\n\nFor more information about setting up a custom dashboard, see\n[Manage custom dashboard](https://cloud.google.com/monitoring/charts/dashboards)\nand [Add dashboard widgets](https://cloud.google.com/monitoring/charts).\n\n### Create an alerting policy\n\nIn Cloud Monitoring, you can create [alerts](https://cloud.google.com/monitoring/alerts) to notify\nyou when a change in a metric condition occurs. You can use these alerts to be\nnotified of potential problems before they impact your users.\n\nFor more information about creating alerts, see\n[Create metric-threshold alerting policies](https://cloud.google.com/monitoring/alerts/using-alerting-ui).\n\nConsider the following example where we create a latency alert policy. The\nalerting policy checks p99 latency over a 5 minute rolling window. If the p99\nlatency stays higher than 250ms for 5 minutes, the alert is triggered. \n\n### Console\n\n1. In the Google Cloud console, go to the **Monitoring** page then select\n *notifications*\n **Alerting**.\n\n [Go to Monitoring](https://console.cloud.google.com/monitoring/alerting)\n2. Select **Create policy**.\n\n3. Select the **Request Latencies** metric from the **Consumed API**\n resource.\n\n4. Add a service filter for `firestore.googleapis.com` for\n Firestore Native databases.\n\n5. Click **Next** to configure the trigger.\n\n6. Select the **Condition Types** as **Threshold**.\n\n A threshold condition is set to a threshold value of 250ms. An alert is\n triggered when the p99 latency value stays the same for the entire\n period of the rolling window (5 min).\n7. Set the **Threshold value** as **250**.\n\n8. Click **Next** to configure notifications.\n\n9. Set the alert policy name and click **Next**.\n\n10. Review the alert configurations and click **Create Policy**.\n\n### MQL\n\nYou can implement the same latency alert policy using a Monitoring Query\nLanguage (MQL) query. For more examples of using MQL, see\n[Sample MQL queries](https://cloud.google.com/monitoring/mql/examples). \n\n fetch consumed_api\n | metric 'serviceruntime.googleapis.com/api/request_latencies'\n | filter (resource.service == 'firestore.googleapis.com')\n | group_by 5m,\n [value_request_latencies_percentile:\n percentile(value.request_latencies, 99)]\n | every 5m\n | condition val() \u003e 0.25 's'"]]
