Config Examples

Hello! Welcome to our carefully crafted config examples hub. Whether you're a seasoned pro or just getting started, these configurations are here to help you understand and simulate various scenarios.

For detailed reference, you may need to read Config Reference.

Initial Startup Delay Testing

Want to understand how your application behaves with a slow start? Simulate a delay during startup due to initializations or database connectivity issues.

• Useful for:
  • Confirming that orchestration platforms like Kubernetes handle startups gracefully.
  • Observing how service dependencies manage application start delays.
  • Ensuring logging and metrics systems capture slow startup events accurately.

Here's an example that introduces a delay of 5 to 10 seconds for application startup:

process:
  delay: 5s to 10s

Random Process Termination

Prepare for the unexpected. Simulate those sudden application terminations and observe the repercussions.

• Useful for:
  • Testing the robustness of automated recovery processes.
  • Monitoring alerts during unexpected process terminations.
  • Checking how stateful services like databases manage abrupt interruptions.

This example randomly terminates the application between 4 to 10 seconds with an exit code 20:

process:
  exit:
    after: 4s to 10s
    code: 20

Web Server Fault Simulation

Test your application's resilience during intermittent web server failures.

• Useful for:
  • Evaluating the efficiency of load balancer health checks and failovers.
  • Assessing your application's response to intermittent connectivity hiccups.

The example below simulates server behaviors on 0.0.0.0:80, handling various routes with a 70% failure chance:

webServers:
- interface: 0.0.0.0
  port: 80
  fault:
    percentage: 70
    interval: 1s

Route-Specific Failures

Simulate disruptions in specific API routes to understand system resilience.

• Useful for:
  • Gauging application's ability to manage errors and retry logic for crucial dependencies.
  • Evaluating client-side libraries or SDKs dealing with these API glitches.
  • Understanding how cascading failures across services affect system health.
  • Studying the ramifications of API failures on comprehensive business processes.

Here's a sample config, focusing on the /livez route and introducing variable disruptions:

webServers:
- interface: 0.0.0.0
  port: 80
  routes:
  - path: /livez
    content:
      whoami: true
      serverInfo: true
    fault:
      percentage: 40 to 60
      interval: 1s
      responseDelay: 1s

Livez and Readyz Probes

Ensure your application is alive, kicking, and ready for traffic!

• Useful for:
  • Fine-tuning orchestration platforms' probes for app liveliness and readiness.
  • Setting up efficient alerts tied to health and readiness metrics.
  • Ensuring a smooth rollback mechanism when probe checks falter.

Check out this configuration illustrating two routes, /livez and /readyz, with their specific behaviors:

webServers:
- interface: 0.0.0.0
  port: 80
  routes:
  - path: /livez
    content:
      whoami: true
      serverInfo: true
    fault:
      planRefs:
      - disaster
  - path: /readyz
    content:
      whoami: true
      serverInfo: true
    fault:
      planRefs:
      - disaster
      - unready

plans:
- name: disaster
  percentage: 30
  interval: 2s
- name: unready
  percentage: 40
  interval: 3s

Simulated Memory Leak

Watch out for those sneaky memory leaks that creep up over time!

• Useful for:
  • Ensuring your monitoring tools catch memory leaks before they wreak havoc.
  • Witnessing how pod behavior changes under tight memory circumstances.
  • Gauging the efficiency of autoscaling based on memory metrics.
  • Understanding the domino effect on services when memory runs thin.

Dive into this example that progressively intensifies memory consumption:

memoryLeak:
  size: 10Mi, 30Mi, 100Mi, 200Mi, 1G
  interval: 2s

Simulated CPU Spike

Brace yourself for sudden CPU surges and handle them with grace!

• Useful for:
  • Ensuring your cluster autoscales efficiently under CPU stress.
  • Observing system stability and performance under heavy CPU usage.
  • Verifying monitoring systems' ability to pinpoint CPU surges.
  • Studying the influence of CPU spikes on neighboring services.

Take a look at this configuration that orchestrates random, ongoing CPU loads:

cpuLoad:
  percentage: 70 to 90
  interval: 2s

Complex Multi-Module Failures

Why fail in one way when you can fail in many? Test your system's mettle against multifaceted failures.

• Useful for:
  • Running thorough stress tests to understand system behavior amidst compounded failures.
  • Ensuring alerts and incident responses are coherent during layered incidents.
  • Evaluating system robustness against cascading disruptions.

This sample combines various failure points, including memory leaks, CPU load, and specific web route behaviors:

process:
  delay: 2s to 5s
  exit:
    after: 1m to 5m
    code: 20

webServers:
- interface: 0.0.0.0
  port: 80
  routes:
  - path: /livez
    content:
      whoami: true
      serverInfo: true
    fault:
      planRefs:
      - disaster
  - path: /readyz
    content:
      whoami: true
      serverInfo: true
    fault:
      planRefs:
      - disaster
      - unready

memoryLeak:
  planRefs:
  - disaster

cpuLoad:
  planRefs:
  - disaster

plans:
- name: disaster
  percentage: 30 to 60
  size: 100Mi to 1Gi
  interval: 2s
- name: unready
  percentage: 40
  interval: 3s