Last updated:

View Multi-cluster Monitoring Data

This section describes how to view monitoring data across multiple clusters.

Prerequisites

You should have the platform-admin role on the KubeSphere platform. For more information, see Users and Platform Roles.
The host cluster and member clusters that need monitoring must have the Whizard Observability Center enabled.
Note
If the member cluster does not have the Whizard Observability Center enabled, the Whizard Observability Center will not be able to retrieve data from the member cluster.

Note
If the member cluster does not have the Whizard Observability Center enabled, the Whizard Observability Center will not be able to retrieve data from the member cluster.

Steps

Click in the upper-right corner of the page and click Whizard Observability Center.

The Overview page of the Whizard Observability Center displays monitoring information for all clusters.

Area	Description
Number of Created Resources	Displays the number of all monitored clusters, nodes, projects, pods, deployments, StatefulSets, DaemonSets, Jobs, CronJobs, persistent volume claims, services, and Ingresses.
Resource Usage	Displays the CPU, memory, and disk usage of all nodes in all monitored clusters, as well as the percentage of the number of created pods to the maximum number of pods that can be created. By default, each node can create up to 110 pods. For CPU and memory, hover over to view the reserved and limit resources allocated to containers and projects.
Global Alerts	Displays the number of alerts generated by global alerting rule groups and the latest alert messages. Alerts displayed here do not include those generated by alerting rule groups of clusters and projects. Global alerting rule groups are managed by platform administrators in the Whizard Observability Center. Alert severity include Info, Warning, Error, and Critical. Alert status includes: Pending: The monitoring metrics meet the preset conditions but do not meet the preset duration. Firing: The monitoring metrics meet the preset conditions and the preset duration.
Pods	Displays the number of various types of pods in all monitored clusters. Pod status includes: Running: The pod has been assigned to a node, all containers in the pod have been created, and at least one container is running, starting, or restarting. Pending: The pod has been accepted by the system, but at least one container has not been created or is not running. This state may indicate that the pod is waiting for scheduling or for the container image to be downloaded. Completed: All containers in the pod have terminated successfully (with an exit code of 0) and will not be restarted. Failed: All containers in the pod have terminated, and at least one container has terminated with a non-zero exit code. Unknown: The system is unable to get the status of the pod. This state usually occurs when the system fails to communicate with the host where the pod is located. Pod QoS (Quality of Service) types include: Guaranteed: Each container in the pod has memory limits, memory requests, CPU limits, and CPU requests, and the memory limit is equal to the memory request, and the CPU limit is equal to the CPU request. Burstable: At least one container in the pod does not meet the requirements of the Guaranteed type. BestEffort: Containers in the pod do not configured with any memory limits, memory requests, CPU limits, or CPU requests. The QoS type of the pod determines the running priority of the pod. When resources in the system is insufficient to run all pods, the system gives priority to running pods of QoS type Guaranteed first, followed by pods of QoS type Burstable, and finally, pods of QoS type BestEffort.

Area

Description

Number of Created Resources

Displays the number of all monitored clusters, nodes, projects, pods, deployments, StatefulSets, DaemonSets, Jobs, CronJobs, persistent volume claims, services, and Ingresses.

Resource Usage

Displays the CPU, memory, and disk usage of all nodes in all monitored clusters, as well as the percentage of the number of created pods to the maximum number of pods that can be created. By default, each node can create up to 110 pods.

For CPU and memory, hover over to view the reserved and limit resources allocated to containers and projects.

Global Alerts

Displays the number of alerts generated by global alerting rule groups and the latest alert messages. Alerts displayed here do not include those generated by alerting rule groups of clusters and projects. Global alerting rule groups are managed by platform administrators in the Whizard Observability Center.

Alert severity include Info, Warning, Error, and Critical.

Alert status includes:

Pending: The monitoring metrics meet the preset conditions but do not meet the preset duration.
Firing: The monitoring metrics meet the preset conditions and the preset duration.

Pods

Displays the number of various types of pods in all monitored clusters.

Pod status includes:

Running: The pod has been assigned to a node, all containers in the pod have been created, and at least one container is running, starting, or restarting.
Pending: The pod has been accepted by the system, but at least one container has not been created or is not running. This state may indicate that the pod is waiting for scheduling or for the container image to be downloaded.
Completed: All containers in the pod have terminated successfully (with an exit code of 0) and will not be restarted.
Failed: All containers in the pod have terminated, and at least one container has terminated with a non-zero exit code.
Unknown: The system is unable to get the status of the pod. This state usually occurs when the system fails to communicate with the host where the pod is located.

Pod QoS (Quality of Service) types include:

Guaranteed: Each container in the pod has memory limits, memory requests, CPU limits, and CPU requests, and the memory limit is equal to the memory request, and the CPU limit is equal to the CPU request.
Burstable: At least one container in the pod does not meet the requirements of the Guaranteed type.
BestEffort: Containers in the pod do not configured with any memory limits, memory requests, CPU limits, or CPU requests.

The QoS type of the pod determines the running priority of the pod. When resources in the system is insufficient to run all pods, the system gives priority to running pods of QoS type Guaranteed first, followed by pods of QoS type Burstable, and finally, pods of QoS type BestEffort.

In the upper-right corner of the page, click Select Cluster and select the cluster you want to monitor. The overview page will display monitoring information for the selected cluster.
Click Collapse Cluster List/Expand Cluster List to hide or show the cluster list on the right.
- Click the cluster name in the cluster list to enter the overview page of that cluster.
- Click and to view cluster information in list or thumbnail.

Feedback

Was this page Helpful?

Receive the latest news, articles and updates from KubeSphere

Thanks for the feedback. If you have a specific question about how to use KubeSphere, ask it on Slack. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.

Previous : Enable Whizard Observability Center Next : View Resource Usage Rankings

What’s on this Page