- 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
What is Tencent Smart Advisor - Chaotic Fault Generator (CFG)?
CFG is a product within the TSA family. It provides efficient, convenient, and secure fault simulation services, along with core features such as industry templates and monitoring guardrails. These features help you identify potential disaster recovery risks in your business, validate the effectiveness of high-availability plans, and ultimately improve the availability and resilience of your systems.
How to Use CFG?
Step 1: Create an experiment
Log in to the Tencent Smart Advisor > Chaos Engineering Console, go to the experiment management page, and click Create a New Experiment. You can either use a template from the experiment template library (which automatically fills in failure action orchestration and only requires you to specify instance objects) or create a blank experiment and freely configure fault actions. Additionally, you can pre-configure business monitoring metrics, security guardrails, and alarms.
Step 2: Execute the experiment
On the experiment details page, click Execute in the upper right corner to start the experiment process. Click the run button within the action group to execute fault injection and recovery actions one by one. During the experiment, you can observe the success or failure of each action, making the blast radius more intuitive and controllable. Additionally, you can monitor business steady-state metrics in real-time and Pause or Continue the experiment as needed.
Step 3: End the experiment
After all experiment actions have been executed, click End Experiment in the upper right corner of the experiment details page and fill in the Experiment Results. Then, click Download Experiment Report to generate an experiment report that comprehensively records all experiment details, making it easier to conduct fault analysis and review the experiment.
Step 4: Build a custom template library
For experiment tasks that need to be conducted frequently, you can save them as custom templates from the experiment list with a single click, making it easy to quickly reuse them in future experiments. In the Experience Library Management page, you can also deactivate or activate these templates as needed.
Note:
What Is the Template Library?
To help users quickly reuse proven experiment schemes, CFG provides experiment templates for various industries such as e-commerce, gaming, and multimedia. The content covers a range of typical use cases, such as cross-availability zone disaster recovery, hybrid cloud disaster recovery experiments, service stress experiments, and network fault experiments. When creating a new experiment, users can browse the industry template library in the first step under Experience Selection. By clicking Go to use, the experiment information and action orchestration scheme from the template will be automatically populated into the creation form. Users only need to select instance resources to quickly create an experiment, thereby improving efficiency.
What Object Types does CFG Support for Fault Injection?
CFG supports fault injection on object types such as Tencent Cloud CVM, TKE, MySQL, Redis, NAT, CLB, dedicated lines, and audio/video services to test system availability.
Does CFG Support Use in Private Cloud Environment?
Currently, it only supports public cloud environment and does not support private cloud.
Yes
No
Was this page helpful?