Exporter Configuration

The Crunchy Postgres for Kubernetes Monitoring stack relies on the Crunchy Postgres Exporter sidecar to collect real-time metrics about a PostgreSQL database. In this guide, we cover how to configure the Exporter to use a custom password, tls encryption, and custom queries to fit your needs.

Setting a custom ccp_monitoring password

The postgres_exporter process will use the ccp_monitoring username and password to gather metrics from Postgres. Considering these credentials are only used within a cluster, they can normally be generated by Crunchy Postgres for Kubernetes without user intervention. There are some cases, like standby monitoring, where a user might need to manually configure the ccp_monitoring password.

To update the ccp_monitoring password for a PostgresCluster, you will need to edit the $CLUSTER_NAME-monitoring secret. The following command will open up an editor with the contents of the monitoring secret:

kubectl edit secret $CLUSTER_NAME-monitoring
Copy

The editor will look something like this:

apiVersion: v1
kind: Secret
metadata:
  name: $CLUSTER_NAME-monitoring
  labels:
    postgres-operator.crunchydata.com/cluster: $CLUSTER_NAME
    postgres-operator.crunchydata.com/role: monitoring
data:
  password: cGFzc3dvcmQ=
  verifier: $sha
Copy

To set a password you can remove the entire data section (including both the password and verifier fields) and replace it with the stringData field:

stringData:
  password: $NEW_PASSWORD
Copy

Note: The stringData field is a Kubernetes feature that allows you to provide a plain-text field to a secret that is then encoded like the data field. This field is describe in the Kubernetes documentation.

By saving this change, the secret will be updated and the change will make its way into the pod. The new secret files will be updated in the file system and the postgres_exporter process will be restarted, which may take a minute or two. Once the process has restarted, the postgres_exporter will query the database using the updated password.

Configuring TLS Encryption for the Exporter

Crunchy Postgres for Kubernetes allows you to configure the exporter sidecar to use TLS encryption. If you provide a custom TLS Secret via the exporter spec:

monitoring:
  pgmonitor:
    exporter:
      customTLSSecret:
        name: hippo.tls
Copy

Like other custom TLS Secrets that can be configured with Crunchy Postgres for Kubernetes, the Secret will need to be created in the same Namespace as your PostgresCluster. It should also contain the TLS key (tls.key) and TLS certificate (tls.crt) needed to enable encryption.

data:
  tls.crt: $VALUE
  tls.key: $VALUE
Copy

After you configure TLS for the exporter, you will need to update your Prometheus deployment to use TLS, and your connection to the exporter will be encrypted. Check out the Prometheus documentation for more information on configuring TLS for Prometheus.

Custom Queries for the Exporter

Out of the box, the exporter is set up with default queries that will provide you with valuable information about your PostgresClusters. However, sometimes, you want to provide your own custom queries to retrieve metrics not in the defaults. Luckily, Crunchy Postgres for Kubernetes has you covered.

The first thing you will need to figure out when implementing your own custom queries is whether you want to completely swap out the default queries or add your queries to the defaults that Crunchy Data provides.

Using Your Own Custom Set

If you wish to completely swap out the Crunchy-provided default queries with your own set, you will need to start by putting all of the queries that you wish to run in a YAML file named queries.yml. You can use the query files found in the pgMonitor repo as guidance for the proper format. This file should then be placed in a ConfigMap. For example, we could run the following command:

kubectl create configmap my-custom-queries --from-file=path/to/file/queries.yml -n postgres-operator
Copy

This will create a ConfigMap named my-custom-queries in the postgres-operator namespace, and it will hold the queries.yml file found at the relative path of path/to/file.

Once the ConfigMap is created, you simply need to tell Crunchy Postgres for Kubernetes the name of the ConfigMap by editing your PostgresCluster Spec:

monitoring:
  pgmonitor:
    exporter:
      configuration:
        - configMap:
            name: my-custom-queries
Copy

Once the spec is applied, the exporter will be restarted and your new metrics will be available. If you later make a change to the custom queries in the ConfigMap, the exporter process will again be restarted and the new queries used once a difference is detected in the ConfigMap.

Append Your Custom Queries to the Defaults

Starting with Postgres Operator 5.5, you can easily append custom queries to the Crunchy Data defaults! To do this, the setup has the same three easy steps that we just went through:

1. Put your desired queries in a YAML file named queries.yml.
2. Create a ConfigMap that holds the queries.yml file.
3. Tell Crunchy Postgres for Kubernetes the name of your ConfigMap using the monitoring.pgmonitor.exporter.configuration spec.

The additional step that tells Crunchy Postgres for Kubernetes to append the queries rather than swapping them out is to turn on the AppendCustomQueries feature gate.

Crunchy Postgres for Kubernetes feature gates are enabled by setting the PGO_FEATURE_GATES environment variable on the Crunchy Postgres for Kubernetes Deployment. To enable the appending of the custom queries, you would want to set:

PGO_FEATURE_GATES="AppendCustomQueries=true"
Copy

Please note that it is possible to enable more than one feature at a time as this variable accepts a comma delimited list. For example, to enable multiple features, you would set PGO_FEATURE_GATES like so:

PGO_FEATURE_GATES="FeatureName=true,FeatureName2=true,FeatureName3=true..."
Copy