15308555518/ website
1
0
Fork 0
mirror of https://github.com/kubesphere/website.git synced 2025-12-28 22:52:44 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #487 from rayzhou2017/master 

Update cluster wide alerting and notification
This commit is contained in:
KubeSphere CI Bot 2020-11-08 20:40:45 +08:00 committed by GitHub
parent 9af0818795 f0d600929a
commit c8d17817db
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 31 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/alerting-message.md
View File

@ -17,19 +17,21 @@ You have created a node-level alert policy and received alert notifications of i
### Task 1: View Alert Message
1. Log in the console with one account granted the role `platform-admin`.
2. Click **Platform** in the top left corner and select **Clusters Management**.
1. Log in the console with one account granted the role `platform-admin`.
![alerting_message_node_level_guide](/images/docs/alerting/alerting_message_node_level_guide.png)
2. Click **Platform** in the top left corner and select **Clusters Management**.
![alerting_message_node_level_guide](/images/docs/alerting/alerting_message_node_level_guide.png)
3. Select a cluster from the list and enter it (If you do not enable the [multi-cluster feature](../../../multicluster-management/), you will directly go to the **Overview** page).
4. Navigate to **Alerting Messages** under **Monitoring & Alerting**, and you can see alert messages in the list. In the example of [Alert Policy (Node Level)](../alerting-policy/), you set one node as the monitoring target, and its memory utilization rate is higher than the threshold of `50%`, so you can see an alert message of it.
![alerting_message_node_level_list](/images/docs/alerting/alerting_message_node_level_list.png)
![alerting_message_node_level_list](/images/docs/alerting/alerting_message_node_level_list.png)
5. Click the alert message to enter the detail page. In **Alerting Detail**, you can see the graph of memory utilization rate of the node over time, which has been continuously higher than the threshold of `50%` set in the alert rule, so the alert was triggered.
![alerting_message_node_level_detail](/images/docs/alerting/alerting_message_node_level_detail.png)
![alerting_message_node_level_detail](/images/docs/alerting/alerting_message_node_level_detail.png)
### Task 2: View Alert Policy
@ -41,9 +43,9 @@ Switch to **Alerting Policy** to view the alert policy corresponding to this ale
1. Switch to **Recent Notification**. It can be seen that 3 notifications have been received, because the notification rule was set with a repetition period of `Alert once every 5 minutes` and retransmission of `Resend up to 3 times`.
![alerting_message_node_level_notification](/images/docs/alerting/alerting_message_node_level_notification.png)
![alerting_message_node_level_notification](/images/docs/alerting/alerting_message_node_level_notification.png)
2. Log in your email to see alert notification mails sent by the KubeSphere mail server. You have received a total of 3 emails.
2. Log in your email to see alert notification mails sent by the KubeSphere mail server. You have received a total of 3 emails.
### Task 4: Add Comment

34
content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/alerting-policy.md
View File

@ -20,19 +20,22 @@ KubeSphere provides alert policies for nodes and workloads. This guide demonstra
### Task 1: Create an Alert Policy
1. Log in the console with one account granted the role `platform-admin`.
2. Click **Platform** in the top left corner and select **Clusters Management**.
1. Log in the console with one account granted the role `platform-admin`.
![alerting_policy_node_level_guide](/images/docs/alerting/alerting_policy_node_level_guide.png)
2. Click **Platform** in the top left corner and select **Clusters Management**.
![alerting_policy_node_level_guide](/images/docs/alerting/alerting_policy_node_level_guide.png)
3. Select a cluster from the list and enter it (If you do not enable the [multi-cluster feature](../../../multicluster-management/), you will directly go to the **Overview** page).
4. Navigate to **Alerting Policies** under **Monitoring & Alerting**, and click **Create**.
![alerting_policy_node_level_create](/images/docs/alerting/alerting_policy_node_level_create.png)
![alerting_policy_node_level_create](/images/docs/alerting/alerting_policy_node_level_create.png)
### Task 2: Provide Basic Information
In the dialog that appears, fill in the basic information as follows. Click **Next** after you finish.
- **Name**: a concise and clear name as its unique identifier, such as `alert-demo`.
- **Alias**: to help you distinguish alert policies better. Chinese is supported.
- **Description**: a brief introduction to the alert policy.
@ -41,7 +44,8 @@ In the dialog that appears, fill in the basic information as follows. Click **Ne
### Task 3: Select Monitoring Targets
Select several nodes in the node list as the monitoring targets. Here a node is selected for the convenience of demonstration. Click **Next** when you finish.
Select several nodes in the node list or use Node Selector to choose a group of nodes as the monitoring targets. Here a node is selected for the convenience of demonstration. Click **Next** when you finish.
![alerting_policy_node_level_monitoring_target](/images/docs/alerting/alerting_policy_node_level_monitoring_target.png)
{{< notice note >}}
@ -54,7 +58,7 @@ You can sort nodes in the node list from the drop-down menu through the followin
1. Click **Add Rule** to begin to create an alerting rule. The rule defines parameters such as metric type, check period, consecutive times, metric threshold and alert level to provide rich configurations. The check period (the second field under **Rule**) means the time interval between 2 consecutive checks of the metric. For example, `2 minutes/period` means the metric is checked every two minutes. The consecutive times (the third field under **Rule**) means the number of consecutive times that the metric meets the threshold when checked. An alert is only triggered when the actual time is equal to or is greater than the number of consecutive times set in the alert policy.
![alerting_policy_node_level_alerting_rule](/images/docs/alerting/alerting_policy_node_level_alerting_rule.png)
![alerting_policy_node_level_alerting_rule](/images/docs/alerting/alerting_policy_node_level_alerting_rule.png)
2. In this example, set those parameters to `memory utilization rate`, `1 minute/period`, `2 consecutive times`, `>` and `50%`, and `Major Alert` in turn. It means KubeSphere checks the memory utilization rate every minute, and a major alert is triggered if it is larger than 50% for 2 consecutive times.
@ -62,21 +66,23 @@ You can sort nodes in the node list from the drop-down menu through the followin
{{< notice note >}}
- You can create node-level alert policies for the following metrics:
- CPU: `cpu utilization rate`, `cpu load average 1 minute`, `cpu load average 5 minutes`, `cpu load average 15 minutes`
- Memory: `memory utilization rate`, `memory available`
- Disk: `inode utilization rate`, `disk space available`, `local disk space utilization rate`, `disk write throughput`, `disk read throughput`, `disk read iops`, `disk write iops`
- Network: `network data transmitting rate`, `network data receiving rate`
- Pod: `pod abnormal ratio`, `pod utilization rate`
You can create node-level alert policies for the following metrics:
- CPU: `cpu utilization rate`, `cpu load average 1 minute`, `cpu load average 5 minutes`, `cpu load average 15 minutes`
- Memory: `memory utilization rate`, `memory available`
- Disk: `inode utilization rate`, `disk space available`, `local disk space utilization rate`, `disk write throughput`, `disk read throughput`, `disk read iops`, `disk write iops`
- Network: `network data transmitting rate`, `network data receiving rate`
- Pod: `pod abnormal ratio`, `pod utilization rate`
{{</ notice >}}
### Task 5: Set Notification Rule
1. **Effective Notification Time Range** is used to set sending time of notification emails, such as `09:00 ~ 19:00`. **Notification Channel** currently only supports **Email**. You can add email addresses of members to be notified to **Notification List**.
1. **Customize Repetition Rules** defines sending period and retransmission times of notification emails. If alerts have not been resolved, the notification will be sent repeatedly after a certain period of time. Different repetition rules can also be set for different levels of alerts. Since the alert level set in the previous step is `Major Alert`, select `Alert once every 5 miniutes` (sending period) in the second field for **Major Alert** and `Resend up to 3 times` in the third field (retransmission times). Refer to the following image to set notification rules:
![alerting_policy_node_level_notification_rule](/images/docs/alerting/alerting_policy_node_level_notification_rule.png)
2. **Customize Repetition Rules** defines sending period and retransmission times of notification emails. If alerts have not been resolved, the notification will be sent repeatedly after a certain period of time. Different repetition rules can also be set for different levels of alerts. Since the alert level set in the previous step is `Major Alert`, select `Alert once every 5 miniutes` (sending period) in the second field for **Major Alert** and `Resend up to 3 times` in the third field (retransmission times). Refer to the following image to set notification rules:
![alerting_policy_node_level_notification_rule](/images/docs/alerting/alerting_policy_node_level_notification_rule.png)
3. Click **Create**, and you can see that the alert policy is successfully created.

2
content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/alertmanager.md
View File

@ -21,7 +21,7 @@ Starting from v3.0, KubeSphere adds popular alert rules in the open source commu
## Use Alertmanager to manage K8s events alerts
Alertmanager can be used to manage alerts sent from sources other than Prometheus. In KubeSphere v3.0 and above, user can use it to manage alerts triggered by K8s events. For more details, please refer to [kube-events](https://github.com/kubesphere/kube-events)
Alertmanager can be used to manage alerts sent from sources other than Prometheus. In KubeSphere v3.0 and above, user can use it to manage alerts triggered by K8s events. For more details, please refer to [kube-events](https://github.com/kubesphere/kube-events).
## Use Alertmanager to manage KubeSphere auditing alerts

2
content/en/docs/cluster-administration/cluster-wide-alerting-and-notification/notification-manager.md
View File

@ -7,7 +7,7 @@ linkTitle: "Notification Manager"
weight: 2020
---
[Notification Manager](https://github.com/kubesphere/notification-manager) manages notifications in KubeSphere. It receives alerts or notifications from different senders and then send notifications to different users.
[Notification Manager](https://github.com/kubesphere/notification-manager) manages notifications in KubeSphere. It receives alerts or notifications from different senders and then sends notifications to different users.
Supported senders includes: