- Product Overview
- Purchase Guide
- Quick Start
- Operation Guide
- Fault Action Library
- Compute
- JVM Process CPU at Full Load
- Cross-AZ Experiment in CVM
- CVM DNS Unavailability Experiment
- CVM Domain Name Parsing Tampering Experiment
- CVM System Time Skew
- CVM Disk IO Hang Fault Experiment
- CVM Memory OOM and Disk IO Load
- Experiments on CVM Intra-host Network Disorder
- CVM Kernel Faults
- Experiments on CVM Intra-host Network Latency
- High Utilization of CVM Resources (CPU, Memory, and Disk)
- Experiments on CVM Intra-host Network Corruption
- Experiments on CVM Intra-host Network Duplication
- Experiments on CVM Intra-host Network Occupation
- CVM Network Interruption
- CVM Ping Unreachable
- Cloud API Ban in CVM
- Database
- Primary-secondary Switch in TencentDB for PostgreSQL
- MySQL Instance Overall Unavailable
- Primary-secondary Switch in MySQL
- Setting Maximum Number of Connections in MySQL
- Primary Node Fault Experiment on TencentDB for MySQL
- TencentDB for MySQL Read-only Instance Group Unavailable
- Primary-secondary Switch in TDSQL for MySQM
- Primary-secondary Switch in MariaDB
- Primary-secondary Switch in TDSQL-C
- Practice of TencentDB for Redis Proxy Node Faults
- TencentDB for Redis Primary Node Fault
- Primary-secondary Nodes in TencentDB for Redis Instance Unavailable
- Simulating Primary-secondary Switch in Redis
- Simulating MongoDB Storage Node Fault
- Simulating Self-Built MySQL Crash Through Network Blocking
- Restarting TencentDB for MySQL
- Primary-secondary Switch in SQL Server
- Network
- Container
- Simulating Container Resource Network Faults
- Experiment on Container Resource Pod Operation Faults
- Experiment on Container Resource Node Faults
- Experiment on Container Resource Application Process Faults
- Standard Cluster and Serverless Cluster Super Node Faults
- Serverless Pod Fault Experiment Case
- Cluster Node Resource (CPU, Memory, Disk) Stress Test Faults
- Serverless Pod Virtual Node Shutdown Faults
- Simulating Serverless Cluster Pod Network Faults
- High Cluster Pod Resource (CPU, Memory, and Disk) Utilization Rate
- Cluster Pod TencentCloud API Ban
- Big Data
- Cloud Load Balancer
- Message Queue
- Direct Connect
- Custom Actions
- Cloud Streaming Services (CSS)
- Compute
- Permission Management Guide
- API Documentation
- FAQs
- Related Protocol
- Contact Us
- Product Overview
- Purchase Guide
- Quick Start
- Operation Guide
- Fault Action Library
- Compute
- JVM Process CPU at Full Load
- Cross-AZ Experiment in CVM
- CVM DNS Unavailability Experiment
- CVM Domain Name Parsing Tampering Experiment
- CVM System Time Skew
- CVM Disk IO Hang Fault Experiment
- CVM Memory OOM and Disk IO Load
- Experiments on CVM Intra-host Network Disorder
- CVM Kernel Faults
- Experiments on CVM Intra-host Network Latency
- High Utilization of CVM Resources (CPU, Memory, and Disk)
- Experiments on CVM Intra-host Network Corruption
- Experiments on CVM Intra-host Network Duplication
- Experiments on CVM Intra-host Network Occupation
- CVM Network Interruption
- CVM Ping Unreachable
- Cloud API Ban in CVM
- Database
- Primary-secondary Switch in TencentDB for PostgreSQL
- MySQL Instance Overall Unavailable
- Primary-secondary Switch in MySQL
- Setting Maximum Number of Connections in MySQL
- Primary Node Fault Experiment on TencentDB for MySQL
- TencentDB for MySQL Read-only Instance Group Unavailable
- Primary-secondary Switch in TDSQL for MySQM
- Primary-secondary Switch in MariaDB
- Primary-secondary Switch in TDSQL-C
- Practice of TencentDB for Redis Proxy Node Faults
- TencentDB for Redis Primary Node Fault
- Primary-secondary Nodes in TencentDB for Redis Instance Unavailable
- Simulating Primary-secondary Switch in Redis
- Simulating MongoDB Storage Node Fault
- Simulating Self-Built MySQL Crash Through Network Blocking
- Restarting TencentDB for MySQL
- Primary-secondary Switch in SQL Server
- Network
- Container
- Simulating Container Resource Network Faults
- Experiment on Container Resource Pod Operation Faults
- Experiment on Container Resource Node Faults
- Experiment on Container Resource Application Process Faults
- Standard Cluster and Serverless Cluster Super Node Faults
- Serverless Pod Fault Experiment Case
- Cluster Node Resource (CPU, Memory, Disk) Stress Test Faults
- Serverless Pod Virtual Node Shutdown Faults
- Simulating Serverless Cluster Pod Network Faults
- High Cluster Pod Resource (CPU, Memory, and Disk) Utilization Rate
- Cluster Pod TencentCloud API Ban
- Big Data
- Cloud Load Balancer
- Message Queue
- Direct Connect
- Custom Actions
- Cloud Streaming Services (CSS)
- Compute
- Permission Management Guide
- API Documentation
- FAQs
- Related Protocol
- Contact Us
To better support a wide range of fault actions on hosts and containers, fault injection will be performed on target resources through fault agents. Users can independently manage fault probes through Chaotic Fault Generator > Agent Management.
Directions
Select the Type of Agents
Currently, CFG supports self-management of agents for two object types: Cloud Virtual Machine（CVM） and Tencent Kubernetes Engine (TKE).
Install Agents
Cloud Virtual Machine (CVM)
1. Select the region where you want to add a new agent, and then click Add Agent.
Note:
Currently, installing agents is not supported on the following operating system versions: Ubuntu 20.04, Ubuntu 22.04, Ubuntu Server 24.04 LTS 64-bit, Debian 11.1, Debian 11.4, Debian 12.0, Windows (all versions), OpenCloudOS (all versions), AlmaLinux (all versions), and Fedora (all versions).
2. Check the machine instances that require agent installation, and click Next to proceed with machine detection.
3. After the detection is passed, if the machine status indicates installable or upgradable, you can then click Start Installation/Upgrade to install the agent on the target machine.
4. After starting the installation, wait patiently for the agent installation to complete. Once the installation is successful, click Close to proceed with fault injection on the machine resources.
Tencent Kubernetes Engine (TKE)
1. Click the Tencent Kubernetes Engine (TKE) tab to display the fault agents available in the current region.
2. Select the region where you want to add a new agent, and then click Add Agent.
3. Check the clusters that require agent installation and click Next. CFG will detect whether the specified clusters meet the conditions for agent installation.
4. If the test result indicates installable, pending upgrade, the conditions for agent installation are met. You can then click Start Installation/Upgrade to install the agent on the eligible clusters. If the conditions for the agent are not met, see the Remarks for the description of the check results and proceed with the necessary fixes.
5. Once the installation is successful, you can begin simulating Node and Pod faults within the cluster. For detailed instructions, see Standard Cluster Node and Pod Network Failure Simulation.
Uninstall Agents
Batch Uninstall
1. Go to the Agent Management section under the corresponding resource type, check the resources that need to be uninstalled, and click Batch Uninstall to initiate the agent uninstallation operation.
2. When the agent status changes to Not Installed, it indicates that the agent has been successfully uninstalled.
Uninstall Individually
1. You can locate the installed agents in the list and click Uninstall to initiate the agent uninstallation operation.
2. If the agent status does not update promptly during the installation/uninstallation process, you can click the refresh icon at the top to manually refresh the status.
Delete Agents
If you need to delete agent records from CFG, you must first uninstall the agents from the installed resources. Once the agent status changes to Not Installed, you can proceed to delete the agent record by selecting the delete option in the record's operation items.
Yes
No
Was this page helpful?