Skip to main content
The enables the exporting of child metrics, which are additional time series with extra labels. The metrics and their potential child metrics are determined by the specific feature the cluster is using. The number of child metrics can significantly increase based on their associated labels, which increases cardinality. This page will help you understand the potential size of the Prometheus scrape payload for your workload when child metrics are enabled.

​
Enable child metrics

server.child_metrics.enabled is disabled by default. To enable it, use the statement:
New in v24.3.10: The (default: true) reports an aggregate time series for applicable child metrics. When set to false, it stops reporting the aggregate time series, preventing double counting when querying those metrics.

​
All clusters

An RPC (Remote Procedure Call) connection is a communication method used in distributed systems, like CockroachDB, to allow one program to request a service from a program located in another computer on a network without having to understand the network’s details. In the context of CockroachDB, RPC connections are used for inter-node communication. For instance, if Node 1 sends a request to Node 2, and Node 2 dials back (sends request back to Node 1), it ensures that communication is healthy in both directions. This is referred to as a “bidirectionally connected” and “heartbeating” RPC connection. When child metrics is enabled, for all clusters the rpc.connection.* metrics are exported per-peer with labels for remote_node_id, remote_addr, and class. The class label may have the following values: system, default, and raft. The cardinality increases with the number of nodes. An aggregated metric is also included. For example:
Following is a list of the metrics that have child metrics:

​
Secure clusters

When child metrics is enabled, for the security.certificate.expiration.client is exported per SQL user with a label for sql_user. The sql_user label may have the values of the cluster’s users who are logged into a node using client security certificates. The cardinality increases with the number of SQL users. An aggregated metric is also included, however since this is a sum of the child metric values which represent timestamps, it is not usable. For example:
Following is a list of the metrics that have child metrics:

​
Virtual clusters

When child metrics is enabled, for the kv.tenant_rate_limit.* metrics and other kv-related metrics are exported per virtual cluster with a label for tenant_id. The tenant_id label may have the values: system or the id of the virtual cluster. The cardinality increases with the number of virtual clusters. An aggregated metric is also included.
With virtual clusters, while the tenant_id label on kv metrics is only exported when child metrics is enabled, is exported whether child metrics is enabled or disabled.
For example:
Following is a list of the metrics that have child metrics:

​
Clusters with changefeeds

When child metrics is enabled and are created on the cluster, the changefeed.* metrics are exported per changefeed metric label with a label for scope. The scope label may have the values set using the metrics_label option. The cardinality increases with the number of changefeed metric labels. An aggregated metric is also included. For example, when you create two changefeeds with the metrics labels employees and office_dogs, the counter metric changefeed_error_retries exports child metrics with a scope for employees and office_dogs. In addition, the default scope will also be exported which includes changefeeds started without a metrics label.
Following is a list of the metrics that have child metrics:

​
Clusters with logical data replication jobs

When child metrics is enabled and are created on the cluster, the logical_replication_*_by_label metrics are exported per LDR metric label. The label may have the values set using the label option. The cardinality increases with the number of LDR metric labels. For example, when you create two LDR jobs with the metrics labels ldr_job1 and ldr_job2, the metrics logical_replication_*_by_label export child metrics with a label for ldr_job1 and ldr_job2.
Note that the logical_replication_* metrics without the _by_label suffix may be inaccurate with multiple LDR jobs.
Following is a list of the metrics that have child metrics:

​
Clusters with row-level TTL jobs

When child metrics is enabled and are created on the cluster with the , the jobs.row_level_ttl.* metrics are exported per TTL job with ttl_label_metrics enabled with a label for relation. The value of the relation label may have the format: {database}_{schema}_{table}_{primary key}. The cardinality increases with the number of TTL jobs with ttl_label_metrics enabled. An aggregated metric is also included. For example:
Following is a list of the metrics that have child metrics:

​
Metrics of type histogram

When child metrics is enabled with changefeeds or row-level TTL jobs, be aware that metrics of type HISTOGRAM will increase cardinality quickly. For example, when you create two changefeeds with the metrics labels employees and office_dogs, the histogram metric changefeed_flush_hist_nanos exports child metrics for each bucket for each metrics label. In addition, the default scope will also be exported which includes changefeeds started without a metrics label. Therefore, in this example, changefeed_flush_hist_nanos exports child metrics for each bucket for the scope values: default, employees and office_dogs: