- 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
The stream push disabled scenario can verify scenarios where an online stream is blocked due to violations or other reasons. By observing the fault performance, you can verify whether downstream playback can be properly disconnected after the online stream is disabled. If you have configured Stream slate, you can also verify whether the CSS can switch to the slate after the stream is banned.
Experiment Preparation
Note:
1. Stream push disabled will realistically disable CSS stream push. Please carefully evaluate the impact when conducting experiments in a production environment.
2. Stream push disabled is equivalent to manually disabling the online stream on the CSS console.
Experiment Steps
Step 1: Create an experiment
1. Log in to Tencent Cloud Smart Advisor > Chaotic Fault Generator, and follow the steps in Quick Start Guide to create an experiment. In the action group configuration, select Audio and Video for Instance Type, and CSS (Stream Push Domain Name) for Instance Object. Click Add Instance to add the push domain name corresponding to the experiment stream.
2. After adding the domain name, click Experiment Actions and then Add Now to add the experiment action. Select the Stream push disabled fault action and configure the action parameters, where the StreamName field is the stream you will inject the fault into (supporting up to 20 different streams for concurrent operations).
3. After confirmation, click Next to enter the Global Configuration page, select Execution Method for the action, and configure Guardrail Policy and Monitoring Metrics .
Note:
Fault actions for CSS (stream push domain name) do not currently support configuring monitoring metrics.
4. Click Submit when it is completed, then click Experiment Details. The system will automatically pre-check the resources you added to determine if they meet the experiment execution conditions (Pre-check does not execute the experiment actions).
Stream push disabled will perform the following verification. Ensure the environment passes the pre-check before starting the experiment, or it may fail. After issues are fixed, you can click Double-Check to initiate the pre-check again.
Check whether the selected domain name is enabled and is a stream push domain name.
Confirm whether the specified stream is an online stream.
Step 2: Execute the experiment
Click Execute on the action to start executing the fault action.
Step 3: Observe results
1. After the stream push is banned, you will not see the disabled online streams on the CSS Console > Stream Management > Live Streaming page.
2. On the Disabled Streams page, you can see the disabled online streams.
3. The downstream playback will be interrupted immediately. If you have configured a stream slate, the CSS screen will immediately switch to the stream slate.
4. You can view the impact on Live Playback, User distribution, Top playbacks, and Origin Server via CSS > Business Monitoring > Operational Analysis. For details, see Operation Analysis.
Step 4: Fault recovery
In the CFG platform, click Recover Action to cancel the disablement. After successful execution, check if the items observed in Step 3 have been recovered.
Note:
You may need to restart stream push to recover the online stream.
Yes
No
Was this page helpful?