The CockroachDB operator is in .
Configure Prometheus
Every node of a CockroachDB cluster exports granular timeseries metrics formatted for easy integration with Prometheus, a tool for storing, aggregating, and querying timeseries data. This section shows you how to orchestrate Prometheus as part of your Kubernetes cluster and pull these metrics into Prometheus for external monitoring. This guidance is based on CoreOS’s Prometheus Operator, which allows a Prometheus instance to be managed using built-in Kubernetes concepts.If you’re on Hosted GKE, before starting, make sure the email address associated with your Google Cloud account is part of the
cluster-admin RBAC group, as shown in .-
From your local workstation, edit the cockroachdb service to add the prometheus: cockroachdb label:
This ensures that only the cockroachdb (not the cockroach-public service) is being monitored by a Prometheus job.
-
Determine the latest version of CoreOS’s Prometheus Operator and run the following to download and apply the latest
bundle.yamldefinition file:
Be sure to specify the latest CoreOS Prometheus Operator version in the following command, in place of this example’s use of version
v0.82.0.-
Confirm that the
prometheus-operatorhas started: -
Download our Prometheus manifest:
-
Apply the Prometheus manifest. This creates the various objects necessary to run a Prometheus instance:
-
Access the Prometheus UI locally and verify that CockroachDB is feeding data into Prometheus:
-
Port-forward from your local machine to the pod running Prometheus:
- Go to http://localhost:9090 in your browser.
-
To verify that each CockroachDB node is connected to Prometheus, go to Status > Targets. The screen should look like this:

-
To verify that data is being collected, go to Graph, enter the
sys_uptimevariable in the field, click Execute, and then click the Graph tab. The screen should like this:
-
Port-forward from your local machine to the pod running Prometheus:
Prometheus auto-completes CockroachDB time series metrics for you, but if you want to see a full listing, with descriptions, port-forward as described in and then point your browser to http://localhost:8080/_status/vars.
Configure Alertmanager
Active monitoring helps you spot problems early, but it is also essential to send notifications when there are events that require investigation or intervention. This section shows you how to use Alertmanager and CockroachDB’s starter to do this.-
Download our alertmanager-config.yaml configuration file:
-
Edit the
alertmanager-config.yamlfile to specify the desired receivers for notifications. Initially, the file contains a placeholder web hook. -
Add this configuration to the Kubernetes cluster as a secret, renaming it to
alertmanager.yamland labeling it to make it easier to find:
The name of the secret,
alertmanager-cockroachdb, must match the name used in the alertmanager.yaml file. If they differ, the Alertmanager instance will start without configuration, and nothing will happen.-
Use our file to create the various objects necessary to run an Alertmanager instance, including a ClusterIP service so that Prometheus can forward alerts:
-
Verify that Alertmanager is running:
-
Port-forward from your local machine to the pod running Alertmanager:
-
Go to http://localhost:9093 in your browser. The screen should look like this:

-
Port-forward from your local machine to the pod running Alertmanager:
-
Ensure that the Alertmanagers are visible to Prometheus by opening http://localhost:9090/status. The screen should look like this:

-
Add CockroachDB’s starter :
-
Ensure that the rules are visible to Prometheus by opening http://localhost:9090/rules. The screen should look like this:

-
Verify that the
TestAlertManagerexample alert is firing by opening http://localhost:9090/alerts. The screen should look like this:
-
To remove the example alert:
-
Use the
kubectl editcommand to open the rules for editing: -
Remove the
dummy.rulesblock and save the file:
-
Use the
Monitor the operator
The automatically exposes Prometheus-style metrics that you can monitor to observe its operations. Metrics can be collected from the operator via HTTP requests (port 8080 by default) against the/metrics endpoint. The response will describe the current node metrics, for example:
Configure logging
You can use the operator to configure the CockroachDB logging system. This allows you to output logs to such as file or network logging destinations. The logging configuration is defined in a ConfigMap object, using a key namedlogs.yaml. For example:
DEV ) to disk for troubleshooting.
The ConfigMap name must match the cockroachdb.crdbCluster.loggingConfigMapName object in the values file used to :
cockroach-stderr.log file.
Example: Configuring a troubleshooting log file on pods
In this example, CockroachDB has already been deployed on a Kubernetes cluster. Override the to output logs to acockroach-dev.log file.
-
Create a ConfigMap named
logconfig. Note thatnamespaceis set to thecockroach-nsnamespace:For simplicity, also name the YAML filelogconfig.yaml.
The ConfigMap key is not related to the ConfigMap
name or YAML filename, and must be named logging.yaml.DEV logs that have severity to a cockroach-dev.log file on each pod.
-
Apply the ConfigMap to the cluster:
-
Add the
nameof the ConfigMap inloggingConfigMapNameto the values file: -
Apply the new settings to the cluster:
The changes will be rolled out to each pod.
-
See the log files available on a pod:
-
View a specific log file:

