Monitoring¶
Percona Monitoring and Management (PMM) provides an excellent solution of monitoring Percona Server for MongoDB.
Note
Only PMM 2.x versions are supported by the Operator.
PMM is a client/server application. PMM Client runs on each node with the database you wish to monitor: it collects needed metrics and sends gathered data to PMM Server. As a user, you connect to PMM Server to see database metrics on a number of dashboards.
That’s why PMM Server and PMM Client need to be installed separately.
Installing PMM Server¶
PMM Server runs as a Docker image, a virtual appliance, or on an AWS instance. Please refer to the official PMM documentation for the installation instructions.
Installing PMM Client¶
The following steps are needed for the PMM client installation in your Kubernetes-based environment:
-
The PMM client installation is initiated by updating the
pmm
section in the deploy/cr.yaml file.- set
pmm.enabled=true
- set the
pmm.serverHost
key to your PMM Server hostname. -
authorize PMM Client within PMM Server in one of two ways:
Acquire the API Key from your PMM Server and set
PMM_SERVER_API_KEY
in the deploy/secrets.yaml secrets file to this obtained API Key value.check that the
PMM_SERVER_USER
key in the deploy/secrets.yaml secrets file contains your PMM Server user name (admin
by default), and make sure thePMM_SERVER_PASSWORD
key in the deploy/secrets.yaml secrets file contains the password specified for the PMM Server during its installation.Password-based authorization method is deprecated since the Operator 1.13.0.
Note
You use
deploy/secrets.yaml
file to create Secrets Object. The file contains all values for each key/value pair in a convenient plain text format. But the resulting Secrets contain passwords stored as base64-encoded strings. If you want to update password field, you’ll need to encode the value into base64 format. To do this, you can runecho -n "password" | base64 --wrap=0
(or justecho -n "password" | base64
in case of Apple macOS) in your local shell to get valid values. For example, setting the PMM Server API Key tonew_key
in themy-cluster-name-secrets
object can be done with the following command:$ kubectl patch secret/my-cluster-name-secrets -p '{"data":{"PMM_SERVER_API_KEY": '$(echo -n new_key | base64 --wrap=0)'}}'
$ kubectl patch secret/my-cluster-name-secrets -p '{"data":{"PMM_SERVER_API_KEY": '$(echo -n new_key | base64)'}}'
Apply changes with the
kubectl apply -f deploy/secrets.yaml
command. -
Starting from the Operator version 1.12.0, MongoDB operation profiling is disabled by default, and you should enable it to make PMM Query Analytics work. You can pass options to MongoDB in several ways, for example in the
configuration
subsection of thedeploy/cr.yaml
:spec: ... replsets: - name: rs0 size: 3 configuration: | operationProfiling: slowOpThresholdMs: 200 mode: slowOp rateLimit: 100
-
you can also use
pmm.mongodParams
andpmm.mongosParams
keys to specify additional parameters for the pmm-admin add mongodb command formongod
andmongos
Pods respectively, if needed.Note
Please take into account that Operator automatically manages common MongoDB Service Monitoring parameters mentioned in the officiall
pmm-admin add mongodb
documentation, such like username, password, service-name, host, etc. Assigning values to these parameters is not recommended and can negatively affect the functionality of the PMM setup carried out by the Operator.When done, apply the edited
deploy/cr.yaml
file:$ kubectl apply -f deploy/cr.yaml
- set
-
Check that corresponding Pods are not in a cycle of stopping and restarting. This cycle occurs if there are errors on the previous steps:
$ kubectl get pods $ kubectl logs my-cluster-name-rs0-0 -c pmm-client