- Function Overview
- Product Bulletin
- Service Overview
- Billing
- Getting Started
-
User Guide
- Clusters
- Workloads
- Network
- Storage
- O&M
- Namespaces
- ConfigMaps and Secrets
- Auto Scaling
- Add-ons
- Helm Chart
- Permissions
- Settings
- Best Practices
-
API Reference
- Before You Start
- API Overview
- Calling APIs
-
APIs
- Autopilot Cluster Management
- Add-on Management for Autopilot Clusters
-
Autopilot Cluster Upgrade
- Upgrading a Cluster
- Obtaining Cluster Upgrade Task Details
- Retrying a Cluster Upgrade Task
- Obtaining a List of Cluster Upgrade Task Details
- Performing a Pre-upgrade Check for a Cluster
- Obtaining Details About a Pre-upgrade Check Task of a Cluster
- Obtaining a List of Pre-upgrade Check Tasks of a Cluster
- Performing a Post-upgrade Check for a Cluster
- Backing Up a Cluster
- Obtaining a List of Cluster Backup Task Details
- Obtaining the Cluster Upgrade Information
- Obtaining a Cluster Upgrade Path
- Obtaining the Configuration of Cluster Upgrade Feature Gates
- Enabling the Cluster Upgrade Process Booting Task
- Obtaining a List of Upgrade Workflows
- Obtaining Details About a Specified Cluster Upgrade Booting Task
- Updating the Status of a Specified Cluster Upgrade Booting Task
- Quota Management for Autopilot Clusters
- Tag Management for Autopilot Clusters
-
Chart Management for Autopilot Clusters
- Uploading a Chart
- Obtaining a Chart List
- Obtaining a Release List
- Creating a Release
- Updating a Chart
- Deleting a Chart
- Updating a Release
- Obtaining a Chart
- Deleting a Release
- Obtaining a Release
- Downloading a Chart
- Obtaining Chart Values
- Obtaining Historical Records of a Release
- Obtaining the Quota of a User Chart
- Kubernetes APIs
- Permissions and Supported Actions
- Appendix
-
FAQs
- Billing
- Workloads
- Network Management
-
Storage
- Can PVs of the EVS Type in a CCE Autopilot Cluster Be Restored After They Are Deleted or Expire?
- What Can I Do If a Storage Volume Fails to Be Created?
- Can CCE Autopilot PVCs Detect Underlying Storage Faults?
- How Can I Delete the Underlying Storage If It Remains After a Dynamically Created PVC is Deleted?
- Permissions
- General Reference
Copied.
Collecting Kubernetes Events
The Cloud Native Log Collection add-on works with LTS to collect and store Kubernetes events and works with AOM to generate alarms.
Billing
LTS does not charge you for creating log groups and offers a free quota for log collection every month. You pay only for log volume that exceeds the quota. For details, see Price Calculator.
Reporting Kubernetes Events to LTS
The Cloud Native Log Collection add-on has not been installed in a cluster.
You can select Kubernetes events when installing the Cloud Native Log Collection add-on. A default log collection policy will be created, and all events collected will be reported to LTS. For details about how to install the add-on, see Collecting Logs.
The Cloud Native Log Collection add-on has been installed in a cluster.
- Log in to the CCE console and click the cluster name to access the cluster console. In the navigation pane on the left, choose Logging.
-
Click View Log Collection Policies in the upper right corner.
All log collection policies reported to LTS are displayed.
- Click Create Log Policy and configure parameters as required.
Policy Template: If Kubernetes events is not selected during add-on installation or the log collection policy is deleted, you can use this option to create a default log collection policy.
- On the Logging page, select the log stream configured in the log collection policy to view the events reported to LTS.
Reporting Kubernetes Events to AOM
After the Cloud Native Log Collection add-on is installed, all Warning events and some Normal events will be reported to AOM by default. The reported events can be used to configure alarms.
Custom Event Reporting
If the reported events cannot meet requirements, you can modify the settings for the events.
- Run the following command on the cluster to edit the event collection settings:
kubectl edit logconfig -n kube-system default-event-aom
- Modify the event collection settings as required.
apiVersion: logging.openvessel.io/v1 kind: LogConfig metadata: annotations: helm.sh/resource-policy: keep name: default-event-aom namespace: kube-system spec: inputDetail: # Settings on CCE from which events are collected type: event # Type of logs to be collected from CCE. Do not change the value. event: normalEvents: # Used to configure Normal events enable: true # Whether to enable Normal event collection includeNames: # Name of the Normal event to be collected. If this parameter is not specified, all Normal events will be collected. - NotTriggerScaleUp excludeNames: # Name of the Normal event that is not collected. If this parameter is not specified, all Normal events will be collected. - ScaleDown warningEvents: # Used to configure Warning events enable: true # Whether to enable Warning event collection includeNames: # Name of the Warning event to be collected. If this parameter is not specified, all Warning events will be collected. - NotTriggerScaleUp excludeNames: # Name of the Warning event that is not collected. If this parameter is not specified, all Warning events will be collected. - ScaleDown outputDetail: type: AOM # Type of the system that receives the events. Do not change the value. AOM: events: - name: DeleteNodeWithNoServer # Event name. This parameter is mandatory. resourceType: Namespace # Type of the resource that operations are performed on. severity: Major # Event severity after an event is reported to AOM, which can be Critical, Major, Minor, or Info. The default value is Major.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot