--- schema_version: "1" id: 00bfb681c7c7ac2391c51372010b82f04b88a84cef7e43d3a3bd8edfe705fdff title: Configure Alerts for Anypoint Platform PCE collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/private-cloud/3.2/config-alerts.md canonical_url: https://docs.mulesoft.com/private-cloud/3.2/config-alerts source_site: docs.mulesoft.com content_type: documentation content_hash: e2d9700617d33cf16d7c53ca4775a8f6d299dc56a2d55f1c9ff915bbbc5887f8 description: MuleSoft Documentation Site release: "3.2" latest: false --- --- product: Anypoint Platform Private Cloud Edition version: 3.2 --- # Configure Alerts for Anypoint Platform PCE > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Platform Private Cloud Edition (Anypoint Platform PCE) provides built-in alerts that are triggered when a condition specified in any alert definition is detected. Measurements are stored in [Prometheus](https://prometheus.io/docs/introduction/overview/) and read by [Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/). Alertmanager sends emails when an alert is triggered. ## Alert Definitions Default alerts are listed in the following table:

Table 1. Alert Definitions
Component	Alert	Description
CPU	High CPU usage	Triggers a warning when > 75% used; triggers a critical error when > 90% used
Memory	High memory usage	Triggers a warning when > 80% used; triggers a critical error when > 90% used
Systemd	Overall systemd health	Triggers an error when systemd detects a failed service
Systemd	Individual systemd unit health	Triggers an error when a systemd unit is not loaded or active
Filesystem	High disk space usage	Triggers a warning when > 80% used; triggers a critical error when > 90% used
Filesystem	High inode usage	Triggers a warning when > 90% used; triggers a critical error when > 95% used
System	Uptime	Triggers a warning when the uptime for a node is less than five minutes
System	Kernel parameters	Triggers an error if a parameter is not set. See value matrix for details.
Etcd	Etcd instance health	Triggers an error when an etcd leader is down longer than five minutes
Etcd	Etcd latency check	Triggers a warning when follower <→ leader latency exceeds 500 ms; triggers an error when it exceeds one second over a period of one minute
Docker	Docker daemon health	Triggers an error when the Docker daemon is down
Kubernetes	Kubernetes node readiness	Triggers an error when the node is not ready

## Configure Alert Definitions You define new alerts using a gravity resource called `alert`, as shown in the following example: ```copy kind: alert version: v2 metadata: name: cpu-alert spec: # the alert name alert_name: CPUAlert # the rule group the alert belongs to group_name: test-group # the alert expression formula: | node:cluster_cpu_utilization:ratio * 100 > 80 # the alert labels labels: severity: info # the alert annotations annotations: description: | Cluster CPU usage exceeds 80%. ``` See the [Alerting Rules](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) documentation for more details about Prometheus alerts. - To create an alert, run: gravity resource create alert.yaml - To view existing alerts, run: gravity resource get alerts - To remove an alert, run: gravity resource rm alert cpu-alert ## Configure Alerts Delivery To configure Alertmanager to send email alerts, create the following gravity resources: 1. Using the following spec, create a file named `smtp-config.yaml` inside gravity, and replace the placeholder values with those of your SMTP configuration: ```copy kind: smtp version: v2 metadata: name: smtp spec: host: port: username: password: --- kind: alerttarget version: v2 metadata: name: email-alerts spec: # email address of the alerts recipient email: ``` 2. Run `gravity resource create smtp-config.yaml`. You should see the following output: Created cluster SMTP configuration Created monitoring alert target "email-alerts" 3. Add a default router to the Alertmanager configuration inside gravity: kubectl get secret -n monitoring alertmanager-monitoring-kube-prometheus-alertmanager -o json | jq --arg foo "$(kubectl get secret -n monitoring alertmanager-monitoring-kube-prometheus-alertmanager -o json | jq -r '.data\["alertmanager.yaml"\]' | base64 -d | yq r - --tojson | jq -r '.route.routes\[1\] |= . + {"match":{"alertname": "Watchdog", "receiver": "default", "continue": true}}' | jq -r '.route.routes\[0\].match += {"continue":true}' | yq r - -P | base64 | tr -d '\\n')" '.data\["alertmanager.yaml"\]=$foo' | kubectl apply -f - 4. Configure the FROM email address by replacing the value: kubectl get secret -n monitoring alertmanager-monitoring-kube-prometheus-alertmanager -o json | jq --arg foo "$(kubectl get secret -n monitoring alertmanager-monitoring-kube-prometheus-alertmanager -o json | jq -r '.data\["alertmanager.yaml"\]' | base64 -d | yq w - 'global.smtp\_from' | base64 | tr -d '\\n')" '.data\["alertmanager.yaml"\]=$foo' | kubectl apply -f - 5. Restart Alertmanager pods: kubectl delete pod -n monitoring -l app=alertmanager 6. Test Alertmanager by running the following command inside gravity: curl -H 'Content-Type: application/json' -d '\[{"labels":{"alertname":"test-alert","state":"firing"}}\]' http://monitoring-kube-prometheus-alertmanager.monitoring.svc.cluster.local:9093/api/v1/alerts ## Troubleshooting Alerts Common troubleshooting tasks include the following: - Verify that your SMTP server can send and receive emails using the addresses you defined as the `FROM` and `TO` addresses when you configured alerts delivery. - Verify that your cluster nodes can communicate with your SMTP server. For example, use `telnet` to connect to your SMTP server from one of your cluster nodes: telnet my.smtp.server.com 587 Trying XXX.XXX.XXX.XXX... Connected to my.smtp.server.com. Escape character is '^\]'. 220 my.smtp.server.com ESMTP ^\[^\] telnet> quit Connection closed. ## See Also - [Ops Center](https://docs.mulesoft.com/private-cloud/3.2/managing-via-the-ops-center)