Settings

In your playbook, you can set specific settings to define its execution requirements. These settings allow you to:

• Specify CPU and memory requirements.

• Set execution rate or schedule.

• Define a general timeout and concurrency.

• Manage output handling.

These settings help customize the playbook performance to your project’s needs, making testing processes more efficient and scalable.

Name, Description and Mitigation Settings

In your playbook, you can define a name, description, and mitigation strategy to enhance playbook identification. Here’s how each component contributes to a clear and actionable setup:

- Name: assign a descriptive name to identify the playbook quickly.

- Description: provide details about the playbook's purpose, such as supported languages and tool functionalities.

- Mitigation: specify a remediation step if the playbook fails, it provides clear guidance for necessary actions upon failure.

settings:
    name: Find Secrets using Semgrep
    description: A free open-source static code analysis tool with stable support for C#, Go, Java, JavaScript, JSON, Python, PHP, Ruby, and Scala. It has experimental support for nineteen other languages, as well as a language agnostic mode.
    mitigation: Remove secrets from your code if the playbook fails
install:
    assertReturnCode: 0
    semgrep:
    - [ python3 -m pip install semgrep ]
semgrep:
    assertStdout: False
    secrets:
    - [ semgrep --config "p/secrets" -q ]

Associating this metadata with each playbook run provides valuable context and supports informed follow-up actions, especially if mitigation measures are necessary.

Configuring CPU and Memory for Playbooks

Define the required CPU and memory for each playbook to ensure optimal performance. Use the settings to specify these parameters:

settings:
  cpu: 16384
  memory: 122880

These are the possible combinations of CPU and memory configurations and the compatible operating systems. Select the values that best suit your playbook's requirements.

CPU value	Memory value	Operating systems supported
256 (.25 vCPU)	512 1024 2048	Linux
512 (.5 vCPU)	1024 2048 3072 4096	Linux
1024 (1 vCPU)	2048 3072 4096 5120 6144 7168 8192	Linux, Windows
2048 (2 vCPU)	4096 5120 6144 7168 8192 9216 10240 11264 12288 13312 14336 15360 16384	Linux, Windows
4096 (4 vCPU)	8192 9216 10240 11264 12288 13312 14336 15360 16384 17408 18432 19456 20480 21504 22528 23552 24576 25600 26624 27648 28672 29696 30720	Linux, Windows
8192 (8 vCPU)	16384 20480 24576 28672 32768 36864 40960 45056 49152 53248 57344 61440	Linux
16384 (16vCPU)	32768 40960 49152 57344 65536 73728 81920 90112 98304 106496 114688 122880	Linux

Scheduling Playbooks with Cron and Rate settings

To schedule playbook execution based on specific times or intervals, configure Cron or Rate settings. Each offers a different approach to scheduling:

- Cron Settings: use cron settings to schedule playbooks at precise times or recurring intervals, such as daily or weekly runs. For more detailed instructions, refer to the Cron Scheduling section in the Monitor documentation.

- Rate Settings: configure rate settings for simple, fixed-interval scheduling, such as every 5 minutes or hourly. See the rate setting section in the Monitor documentation for guidance.

These settings help automate playbook runs, ensuring timely and consistent execution based on your testing needs.

Notification settings for execution results

You can customize how you receive notifications based on the execution results of your playbook. Choose from three notification settings:

• log: receive notifications for every execution, regardless of the outcome.
• logOnFail: get notified only when the result is a failure.
• logOnPass: receive notifications only when the result is a success.

Notifications can be sent through various channels. Use the following formats to define your notification preferences:

• slack followed by the alias you defined for the Slack channel.
• email followed by the email you defined for email notifications.
• telegram followed by the alias you defined for the Telegram channel.
• discord followed by the alias you defined for the Discord channel.

You can define these aliases in your Settings when adding a notification.

You can specify different log types simultaneously to notify users through multiple channels:

settings:
    logOnFail: slack, email, telegram, discord

Timeout Settings

Set a maximum runtime for playbook executions to control resource usage. Specify the timeout duration in seconds:

settings:
    timeout: 60 # the default value is 3600 seconds

If the playbook reaches the defined timeout without completing, the instance will automatically shut down, terminating any ongoing processes. This setting helps prevent excessive resource use and ensures timely task completion.

Count Settings

The count parameter allows you to launch multiple instances of the same playbook concurrently through the Satori Cloud infrastructure. Each instance runs independently and generates its own report, which is especially useful for tests requiring high concurrency, such as load or DDoS testing. Here’s an example configuration for a DDoS test playbook:

settings:
  name: "Siege - Load testing web servers"
  description: "Knowing how much traffic your web server can handle when under stress is essential for planning
                future grow of your website or application. By using tool called siege, you can run a load test
                on your server and see how your system performs under different circumstances."
  mitigation: "Use an anti DDoS service such as CloudFlare to prevent network attacks"
  count: 100 # maximum amount of concurrent instances for a playbook
install:
  assertReturnCode: 0
  siege:
  - [ apt install -y siege ]
host:
  assertReturnCode: 0
  before_siege:
  - [ curl -s ${(URL}} -m 3 ]
  siege:
  - [ siege -c 100 -t 30s $(URL) ]
  results:
  - [ "set +f; cat siege.*" ]
  after_siege:
  - [ curl -s ${{URL}} -m 3 ]

Report Settings

Control whether and how reports are saved after playbook execution. You can prevent data storage on Satori servers or specify a format to receive a downloadable copy.

- Disable report storage: set report to false to avoid storing any report data on Satori servers, while still receiving an execution summary upon completion.

- Receive a report copy in PDF: set report to pdf to receive a PDF copy of the report.

If no report format is specified, you can still access the report online using the CLI or Web interface.

Example Configurations

• PDF report: sends a downloadable PDF version of your report.

  settings:
      report: pdf

• No report storage: ensures no report data is saved on Satori servers after execution. You will still get the overall status of your report and test after completion but the outputs will not be stored.

  settings:
      report: False

If you need any help, please reach out to us on Discord or via Email