Blocks network traffic (incoming and outgoing).

Inject latency into egress network traffic.

Cause packet loss for outgoing network traffic (egress).

A Steadybit extension to discover container and attack them.

steadybit-extension-container

Steadybit

Verify that an increased latency in a Redis cache is handled by your application properly by having increased processing time but still being able to maintain the throughput.

Check that your application handles a Redis cache downtime gracefully and continues to deliver its intended functionality. The cache downtime may be an unavailable Redis instance or a complete cluster.

An unavailable Microsoft SQL Server database might be too severe for suitable fallbacks and requires your system to indicate unavailability appropriately.

An unavailable Oracle database might be too severe for suitable fallbacks and requires your system to indicate unavailability appropriately.

Your application should continue to function properly and indicate unavailability appropriately in case of increased connection latency to PostgreSQL. Additionally, this experiment can highlight requests that need optimization of timeouts to prevent dropped requests.

An unavailable PostgreSQL database might be too severe for suitable fallbacks and requires your system to indicate unavailability appropriately.

An unavailable database should be handled by your application gracefully and being indicated appropriately. Specifically, we want to ensure that at least one monitor in Datadog is alerting us to the outage. You can address a potential impact on your system by implementing e.g. a failover or caching mechanism.

Ensure that your pods become ready again when your containers exceed ephemeral storage.

If configured properly, Kubernetes is able to detect a non-responding pod and tries to fix it by simply restarting the unresponsive pod. Even so, the exact configuration requires careful consideration to avoid killing your pods too early or flooding your cluster’s traffic with liveness probes.

Quick startup times are favorable in Cloud environments to enable fast recovery and improve scaling.

Verify that an increased latency in your Kafka message delivery is handled by your application properly by having increased processing time but still being able to maintain the throughput.

An unavailable Kafka is not user-visible as it leads to graceful degradation and downstream retries as soon as the Kafka is back available again.

An unavailable Kafka broker or even entire cluster should be handled by your application gracefully and being indicated appropriately. Specifically, we want to ensure that at least one monitor in Datadog is alerting us to the outage.

Verify that an increased latency in your RabbitMQ message delivery is handled by your application properly by having increased processing time but still being able to maintain the throughput.

An unavailable RabbitMQ cluster should be handled by your application gracefully and being indicated appropriately. Specifically, we want to ensure that at least one monitor in Datadog is alerting us to the outage.

When a deployment has no pods ready, New Relic Workflow should notice that and mark the workflow as disrupted.

Container

Container

Container

Container

Discovery of Container Targets

Docker

Kubernetes

Block DNS

Block Traffic

Delay Traffic

Drop Outgoing Traffic

Fill Disk

Limit Bandwidth

Verify system unavailability status during Redis latency

Verify system unavailability status during Redis downtime

Verify system unavailability status when Microsoft SQL Server database can't be reached

Verify system unavailability status when Oracle database can't be reached