The average CPU utilization across all nodes in the cluster. Includes change stream activity if achange stream is enabled for a table in the instance.

In app profile charts, <system> indicates system background activities such as replication andcompaction. System background activities are not client-driven.

The recommended maximum values provide headroom for brief spikes in usage.

CPU utilization for the busiest node in the cluster. This metric continues to beprovided for continuity, but in most cases you should use the more accurate metricHigh-granularity CPU utilization of hottest node.

A fine-grained measurement of CPU utilization for the busiest node in the cluster.

The hottest node is not necessarily the same node over time and can change rapidly, especiallyduring large batch jobs or table scans.

If the hottest node is frequently above the recommended value, even when your average CPU utilization is reasonable, you might be accessing a small part of your data much more frequently than the rest of your data.

• Use theKey Visualizer tool to identify hotspots in your table that might be causing spikes in CPU utilization.
• Check yourschema design to make sure it supports an even distribution of reads and writes across each table.

The average CPU utilization caused by change stream activity across all nodes in the cluster.

CPU utilization by app profile, method, and table.

If you observe higher than expected CPU usage for a cluster, use this metric to determine if the CPU usage of a particular app profile, API method, or table is driving the CPU load.

The amount of data stored in the cluster. Change stream usage is not included for this metric.

This value affects yourcosts. Also, as described below, you might need to add nodes to each cluster as the amount of data increases.

The percentage of the cluster's storage capacity that is being used. The capacity is based on thenumber of nodes in your cluster. Change stream usage is not included for this metric.

In general, do not use more than 70% of the hard limit on total storage, so you have room to add more data. If you do not plan to add significant amounts of data to your instance, you can use up to 100% of the hard limit.

If you are using more than the recommended percentage of the storage limit, add nodes to the cluster. You can also delete existing data, butdeleted data takes upmore space, not less, until a compaction occurs.

For details about how this value is calculated, seeStorage utilization per node.

The amount of storage consumed by change stream records for tables in the instance. This storagedoes not count toward the total storage utilization. You are charged for change stream storage,but it is not included in the calculation of storage utilization (% max).

The percentage your cluster is using of the maximum possible bandwidth for HDD reads.Available only for HDD clusters.

If this value is frequently at 100%, you might experience increased latency. Add nodes to the cluster to reduce the disk load percentage.

The average CPU utilization across all nodes in the cluster. Includes change stream activity if achange stream is enabled for a table in the instance.

In app profile charts, <system> indicates system background activities such as replication andcompaction. System background activities are not client-driven.

CPU utilization for the busiest node in the cluster. This metric continues to beprovided for continuity, but in most cases you should use the more accurate metricHigh-granularity CPU utilization of hottest node.

A fine-grained measurement of CPU utilization for the busiest node in the cluster.

The hottest node is not necessarily the same node over time and can change rapidly, especiallyduring large batch jobs or table scans.

Exceeding the recommended maximum for the busiest node can cause latency and other issues for thecluster.

The average CPU utilization across all nodes in the cluster. Includes change stream activity if achange stream is enabled for a table in the instance.

In app profile charts, <system> indicates system background activities such as replication andcompaction. System background activities are not client-driven.

The amount of data stored in the cluster. Change stream usage is not included for this metric.

This metric reflects the fact that Bigtable compresses your data when it is stored.

The percentage of the cluster's storage capacity that is being used by the table. The capacity is based on the number of nodes in the cluster.

For details about how this value is calculated, seeStorage utilization per node.

The average CPU utilization across all nodes in the cluster. Includes change stream activity if achange stream is enabled for a table in the instance.

In app profile charts, <system> indicates system background activities such as replication andcompaction. System background activities are not client-driven.

The time for a read request to return a response.

Measurement of read latency begins when Bigtable receives the request and ends when the last byte of data is sent to the client. For requests for large amounts of data, read latency can be affected by the client's ability to consume the response.

The time for a write request to return a response.

The number of rows read per second.

This metric provides a more useful view of Bigtable's overall throughput than thenumber of read requests, because a single request can read a large number of rows.

The number of rows written per second.

This metric provides a more useful view of Bigtable's overall throughput than thenumber of write requests, because a single request can write a large number of rows.

The number of requests that were automatically rerouted from one cluster to another due to a failover scenario, such as a brief outage or delay. Automatic rerouting can occur if an app profile uses multi-cluster routing.

This chart does not include manually rerouted requests.

The average CPU utilization across all nodes in the cluster. Includes change stream activity if achange stream is enabled for a table in the instance.

In app profile charts, <system> indicates system background activities such as replication andcompaction. System background activities are not client-driven.

A fine-grained measurement of CPU utilization for the busiest node in the cluster.

The hottest node is not necessarily the same node over time and can change rapidly, especiallyduring large batch jobs or table scans.

Exceeding the recommended maximum for the busiest node can cause latency and other issues for thecluster.

The time for a read request to return a response.

Measurement of read latency begins when Bigtable receives the request and ends when the last byte of data is sent to the client. For requests for large amounts of data, read latency can be affected by the client's ability to consume the response.

The time for a SQL read request to return a response.

Measurement of SQL read latency begins when Bigtable receives the request and ends when the last byte of data is sent to the client. For requests for large amounts of data, SQL read latency can be affected by the client's ability to consume the response.

The time for a write request to return a response.

The total end-to-end latency across all RPC attempts associated with a Bigtable operation. Measures the operation's round trip from the client to Bigtable and back to the client and includes all retries.

The total end-to-end latency across all RPC attempts associated with a Bigtable operation.

Measures the operation's round trip from the client to Bigtable and back to the client and includes all retries. ForExecuteQuery requests, the operation latencies include the application processing time for each returned message.

The total end-to-end latency across all RPC attempts associated with a Bigtable operation. Measures the operation's round trip from the client to Bigtable and back to the client and includes all retries.

The latencies of a client read RPC attempt. Under normal circumstances, this value is identical tooperation_latencies. If the client receives transient errors, however, thenoperation_latencies is the sum of allattempt_latencies and the exponential delays.

The latencies of a client SQL read RPC attempt. Under normal circumstances, this value is identical tooperation_latencies. If the client receives transient errors, however, thenoperation_latencies is the sum of allattempt_latencies and the exponential delays.

The latencies of a client write RPC attempt. Under normal circumstances, this value is identical tooperation_latencies. If the client receives transient errors, however, thenoperation_latencies is the sum of allattempt_latencies and the exponential delays.

The rate of errors caused by the content of a request, as opposed to errors on the Bigtable server side. The user error rate includes the followingstatus codes:

• INVALID_ARGUMENT
• NOT_FOUND
• PERMISSION_DENIED
• RESOURCE_EXHAUSTED
• OUT_OF_RANGE

User errors are typically caused by a configuration issue, such as a request that specifies the wrong cluster, table, or app profile.

• UNKNOWN
• ABORTED
• UNIMPLEMENTED
• INTERNAL
• UNAVAILABLE

The number of requests that were automatically rerouted from one cluster to another due to a failover scenario, such as a brief outage or delay. Automatic rerouting can occur if an app profile uses multi-cluster routing.

This chart does not include manually rerouted requests.

The number of SQL requests that were automatically rerouted from one cluster to another due to a failover scenario, such as a brief outage or delay. Automatic rerouting can occur if an app profile uses multi-cluster routing.

This chart does not include manually rerouted requests.

The amount of data stored in the cluster. Change stream usage is not included for this metric.

This metric reflects the fact that Bigtable compresses your data when it is stored.

The percentage of the cluster's storage capacity that is being used. The capacity is based on thenumber of nodes in your cluster. Change stream usage is not included for this metric.

For details about how this value is calculated, seeStorage utilization per node.

The number of rows read per second.

This metric provides a more useful view of Bigtable's overall throughput than thenumber of read requests, because a single request can read a large number of rows.

The number of rows written per second.

This metric provides a more useful view of Bigtable's overall throughput than thenumber of write requests, because a single request can write a large number of rows.