File: README.md Copy Chapter

eBPF-powered Kubernetes Monitoring and Performance Testing

*Anteon automatically generates Service Map of your K8s cluster without code instrumentation or sidecars. So you can easily find the bottlenecks in your system. Red lines indicate the high latency between services.*

[Live Demo](https://demo.getanteon.com/) • [Documentation](https://getanteon.com/docs) • [Discord](https://discord.com/invite/9KdnrSUZQg)

🐝 What is Anteon? Copy Chapter

Anteon (formerly Ddosify) is an open-source, eBPF-based Kubernetes Monitoring and Performance Testing platform.

🔎 Kubernetes Monitoring Copy Section

• Automatic Service Map Creation: Anteon automatically creates a service map of your cluster without code instrumentation or sidecars. So you can easily find the bottlenecks in your system.
• Performance Insights: It helps you spot issues like services taking too long to respond or slow SQL queries.
• Real-Time Metrics: The platform tracks and displays live data on your cluster instances CPU, memory, disk, and network usage.
• Ease of Use: You don't need to change any code, restart services, or add extra components (like sidecars) to get these insights, thanks to the eBPF based agent (Alaz).
• Alerts for Anomalies: If something unusual, like a sudden increase in CPU usage, happens in your Kubernetes (K8s) cluster, Anteon immediately sends alerts to your Slack.
• Seamless Integration with Performance Testing: Performance testing is natively integrated with Kubernetes monitoring for a unified experience.

🔨 Performance Testing Copy Section

• Multi-Location Based: Generate load/performance tests from over 25 countries worldwide.
• Easy Scenario Builder: Create test scenarios easily without writing any code.
• Seamless Integration with Kubernetes Monitoring: Performance testing is natively integrated with Kubernetes monitoring for a unified experience.
• Postman Integration: Import tests directly from Postman, making it convenient for those already using Postman for API development and testing.

📚 Documentation Copy Chapter

• 🐝 Anteon Stack
• 🚀 Getting Started
• 🔎 Kubernetes Monitoring
• 🔨 Performance Testing

✨ Ask Anteon Guru Copy Chapter

If you don’t want to get lost in the documentation, you can ask Anteon Guru directly. It's an Anteon-focused AI that uses information from the Anteon Website and Anteon GitHub Repository to answer your questions.

ℹ️ About This Repository Copy Chapter

This repository includes the source code for the Anteon Load Engine (Ddosify). You can access Docker Images for the Anteon Engine and Self Hosted on Docker Hub. Since Anteon is a Verified Publisher on Docker Hub, there isn't any pull limits.

• Ddosify documentation provides information on the installation, usage, and features of the Anteon Load Engine.
• The Self-Hosted folder contains installation instructions for the Self-Hosted version.
• Anteon eBPF agent (Alaz) has its own repository.

See the Anteon website for more information.

🛠️ Contributing Copy Chapter

See our Contribution Guide and please follow the Code of Conduct in all your interactions with the project.

Thanks goes to these wonderful people!

Made with contrib.rocks.

📨 Communication Copy Section

You can join our Discord Server for issues, feature requests, feedbacks or anything else.

⚠️ Disclaimer Copy Section

Anteon is created for testing the performance of web applications. Users must be the owner of the target system. Using it for harmful purposes is extremely forbidden. Anteon team & company is not responsible for its’ usages and consequences.

📜 License Copy Chapter

Licensed under the AGPLv3

File: ddosify_engine/completions/README.md Copy Chapter

Shell completions

Zsh Copy Chapter

completions/_ddosify provides a basic auto-completions. You can apply one of the steps to get an auto-completion successfully.

You can locate the file in any directory referenced by $fpath. You can use the following command to list directories in $fpath.

echo $fpath | tr ' ' '\n'

For example, if you are using oh-my-zsh you can add it as a plugin after locating file under plugin related directory appeared in $fpath. You can create a directory named ddosify under ~/.oh-my-zsh/plugins and copy _ddosify file to it.

mkdir -p ~/.oh-my-zsh/plugins/ddosify
cp completions/_ddosify ~/.oh-my-zsh/plugins/ddosify

Then, you can add ddosify to your plugins list in ~/.zshrc file.

# ~/.zshrc

plugins=(
  ...
  ddosify
)

If you don't have an appropriate directory, you can create one and add it to $fpath.

mkdir -p ${ZDOTDIR:-~}/.zsh_functions
echo 'fpath+=${ZDOTDIR:-~}/.zsh_functions' >> ${ZDOTDIR:-~}/.zshrc

Then, you can copy _ddosify file to the directory you created.

cp completions/_ddosify ${ZDOTDIR:-~}/.zsh_functions/_ddosify

File: ddosify_engine/README.md Copy Chapter

Ddosify: A high-performance load testing tool

Table of Contents

• Features

• Tutorials / Blog Posts

• Installation

  • Docker
  • Docker Extension
  • Homebrew Tap (macOS and Linux)
  • Linux
    • Redhat (Fedora, CentOS, RHEL, etc.)
    • Debian (Ubuntu, Linux Mint, etc.)
    • Alpine
  • FreeBSD
  • Windows Executable
  • Using the convenience script (macOS and Linux)
  • Go install from source (macOS, FreeBSD, Linux, Windows)

• Quick Start

• Advanced Usage

  • CLI Flags
  • Load Types
    • Linear
    • Incremental
    • Waved
  • Configuration

• Parameterization (Dynamic Variables)

  • Parameterization on URL
  • Parameterization on Headers
  • Parameterization on Payload (Body)
  • Parameterization on Basic Authentication
  • Parameterization on Config File
  • Environment Variables

• Assertion

  • Keywords
  • Functions
  • Operators
  • Assertion Examples

• Success Criteria (Pass / Fail)

• Difference Between Success Criteria and Step Assertions

  • Keywords
  • Functions
  • Examples

• Correlation

  • Capture with json_path
  • Capture with XPath on XML
  • Capture with XPath on HTML
  • Capture with Regular Expressions
  • Capture Header Value
  • Scenario-Scoped Variables
  • Overall Config and Injection

• Test Data Set

• Cookies

  • Initial / Custom Cookies
  • Cookie Capture
  • Cookie Assertion

• Common Issues

  • macOS Security Issue
  • OS Limit - Too Many Open Files

• Contributing

• Communication

• More

• Disclaimer

• License

• 📥 Installation

• 🚀 Quickstart Guide

• ⚙️ Configuration

• ✨ Examples

• ✅ Scenario-Based - Create your flow in a JSON file. Without a line of code!

• ✅ Different Load Types - Test your system's limits across different load types.

• ✅ Parameterization - Use dynamic variables just like on Postman.

• ✅ Correlation - Extract variables from earlier phases and pass them on to the following ones.

• ✅ Test Data - Import test data from CSV and use it in the scenario.

• ✅ Assertion - Verify that the response matches your expectations.

• ✅ Success Criteria - Set the success criteria for your test.

• ✅ Cookies - Pass cookies through steps and set initial cookies if you want.

• ✅ Widely Used Protocols - Currently supporting HTTP, HTTPS, HTTP/2. Other protocols are on the way.

Tutorials / Blog Posts Copy Chapter

• Testing the Performance of User Authentication Flow
• Load Testing a Fintech API with CSV Test Data Import

Installation Copy Chapter

ddosify is available via Docker, Docker Extension, Homebrew Tap, and downloadable as pre-compiled binaries from the releases page for macOS, Linux and Windows.

For shell auto completions, see Ddosify Completions.

Docker Copy Section

docker run -it --rm ddosify/ddosify

Docker Extension Copy Section

Run Ddosify on Docker Desktop with Ddosify Docker extension. More details here.

Homebrew Tap (macOS and Linux) Copy Section

brew install ddosify/tap/ddosify

Linux Copy Section

• For ARM architectures change ddosify_amd64 to ddosify_arm64 or ddosify_armv6.
• Superuser privilege is required.

Redhat (Fedora, CentOS, RHEL, etc.)

rpm -i https://github.com/ddosify/ddosify/releases/download/v1.0.6/ddosify_amd64.rpm

Debian (Ubuntu, Linux Mint, etc.)

wget https://github.com/ddosify/ddosify/releases/download/v1.0.6/ddosify_amd64.deb
dpkg -i ddosify_amd64.deb

Alpine

wget https://github.com/ddosify/ddosify/releases/download/v1.0.6/ddosify_amd64.apk
apk add --allow-untrusted ddosify_amd64.apk

FreeBSD Copy Section

pkg install ddosify

Windows Executable Copy Section

• Download zip file for your architecture from the releases page.
  • For example, download ddosify version vx.x.x with amd64 architecture: ddosify_x.x.x.zip_windows_amd64
• Unzip ddosify_x.x.x_windows_amd64.zip
• Open Powershell or CMD (Command Prompt) and change directory to unzipped folder: ddosify_x.x.x_windows_amd64
• Run ddosify:

.\ddosify.exe -t https://getanteon.com

Using the convenience script (macOS and Linux) Copy Section

• The script requires root or sudo privileges to move ddosify binary to /usr/local/bin.
• The script attempts to detect your operating system (macOS or Linux) and architecture (arm64, x86, amd64) to download the appropriate binary from the releases page.
• By default, the script installs the latest version of ddosify.
• If you have problems, check common issues.
• Required packages: curl and sudo

curl -sSfL https://raw.githubusercontent.com/getanteon/anteon/master/scripts/install.sh | sh

Go install from source (macOS, FreeBSD, Linux, Windows) Copy Section

Minimum supported Go version is 1.18

go install -v go.ddosify.com/ddosify@latest

Quick Start Copy Chapter

This section aims to show you how to use Ddosify easily without deep dive into its details.

1. Simple load test Copy Section

   ddosify -t https://getanteon.com

   The above command runs a load test with the default value that is 100 requests in 10 seconds.

2. Using some of the features Copy Section

   ddosify -t https://getanteon.com -n 1000 -d 20 -m PUT -T 7 -P http://proxy_server.com:80

   Ddosify sends a total of 1000 PUT requests to https://getanteon.com over proxy http://proxy_server.com:80 in 20 seconds with a timeout of 7 seconds per request.

3. Usage for CI/CD pipelines (JSON output) Copy Section

   ddosify -t https://getanteon.com -o stdout-json | jq .avg_duration

   Ddosify outputs the result in JSON format. Then jq (or any other command-line JSON processor) fetches the avg_duration. The rest depends on your CI/CD flow logic.

4. Scenario based load test Copy Section

   ddosify -config config_examples/config.json

   Ddosify first sends HTTP/2 POST request to https://getanteon.com/endpoint_1 using basic auth credentials test_user:12345 over proxy http://proxy_host.com:proxy_port and with a timeout of 3 seconds. Once the response is received, HTTPS GET request will be sent to https://getanteon.com/endpoint_2 along with the payload included in config_examples/payload.txt file with a timeout of 2 seconds. This flow will be repeated 20 times in 5 seconds and response will be written to stdout.

5. Load test with Dynamic Variables (Parameterization) Copy Section

   ddosify -t https://getanteon.com/{{_randomInt}} -d 10 -n 100 -h 'User-Agent: {{_randomUserAgent}}' -b '{"city": "{{_randomCity}}"}'

   Ddosify sends a total of 100 GET requests to https://getanteon.com/{{_randomInt}} in 10 seconds. {{_randomInt}} path generates random integers between 1 and 1000 in every request. Dynamic variables can be used in URL, headers, payload (body) and basic authentication. In this example, Ddosify generates a random user agent in the header and a random city in the body. The full list of the dynamic variables can be found in the docs.

6. Correlation (Captured Variables) Copy Section

   ddosify -config ddosify_config_correlation.json

   Ddosify allows you to specify variables at the global level and use them throughout the scenario, as well as extract variables from previous steps and inject them to the next steps in each iteration individually. You can inject those variables in requests url, headers and payload(body). The example config can be found in correlation-config-example.

7. Test Data Copy Section

   ddosify -config ddosify_data_csv.json

   Ddosify allows you to load test data from a file, tag specific columns for later use. You can inject those variables in requests url, headers and payload (body). The example config can be found in test-data-example.

Advanced Usage Copy Chapter

You can configure your load test by the CLI options or a config file. Config file supports more features than the CLI. For example, you can't create a scenario-based load test with CLI options.

CLI Flags Copy Section

ddosify [FLAG]

Load Types Copy Section

Linear

ddosify -t https://getanteon.com -l linear

Result:

Note: If the iteration count is too low for the given duration, the test might be finished earlier than you expect.

Incremental

ddosify -t https://getanteon.com -l incremental

Result:

Waved

ddosify -t https://getanteon.com -l waved

Result:

Configuration Copy Section

Configuration file lets you use all the capabilities of Ddosify.

The features you can use by config file:

• Scenario creation
• Environment variables
• Correlation
• Assertions
• Cookies
• Custom load type creation
• Payload from a file
• Multipart/form-data payload
• Extra connection configuration
• HTTP2 support

Usage:

ddosify -config <json_config_path>

There is an example config file at config_examples/config.json. This file contains all of the parameters you can use. Details of each parameter;

• iteration_count (optional)

  This is the equivalent of the -n flag. The difference is that if you have multiple steps in your scenario, this value represents the iteration count of the steps.

• load_type (optional)

  This is the equivalent of the -l flag.

• duration (optional)

  This is the equivalent of the -d flag.

• manual_load (optional)

  If you are looking for creating your own custom load type, you can use this feature. The example below says that Ddosify will run the scenario 5 times, 10 times, and 20 times, respectively along with the provided durations. iteration_count and duration will be auto-filled by Ddosify according to manual_load configuration. In this example, iteration_count will be 35 and the duration will be 18 seconds.
  Also manual_load overrides load_type if you provide both of them. As a result, you don't need to provide these 3 parameters when using manual_load.

  json Copy

  "manual_load": [
      {"duration": 5, "count": 5},
      {"duration": 6, "count": 10},
      {"duration": 7, "count": 20}
  ]

• proxy (optional)

  This is the equivalent of the -P flag.

• output (optional)

  This is the equivalent of the -o flag.

• engine_mode (optional)

  Can be one of distinct-user, repeated-user, or default mode ddosify.

  • distinct-user mode simulates a new user for every iteration.
  • repeated-user mode can use pre-used user in subsequent iterations.
  • ddosify mode is default mode of the engine. In this mode engine runs in its max capacity, and does not show user simulation behaviour.

• env (optional)

  Scenario-scoped global variables. Note that dynamic variables changes every iteration.

  json Copy

  "env": {
          "COMPANY_NAME" :"Ddosify",
          "randomCountry" : "{{_randomCountry}}"
  }

• data (optional)

  Config for loading test data from a CSV file.
  CSV data used in below config.

  json Copy

  "data":{
      "info": {
          "path" : "config/config_testdata/test.csv",
          "delimiter": ";",
          "vars": {
                  "0":{"tag":"name"},
                  "1":{"tag":"city"},
                  "2":{"tag":"team"},
                  "3":{"tag":"payload", "type":"json"},
                  "4":{"tag":"age", "type":"int"}
                  },
          "allow_quota" : true,
          "order": "sequential",
          "skip_first_line" : true,
          "skip_empty_line" : true
      }
  }

  Field	Description	Type	Default	Required?
  path	Local path or remote url for your CSV file	string	-	Yes
  delimiter	Delimiter for reading CSV	string	,	No
  vars	Tag columns using column index as key, use type field if you want to cast a column to a specific type, default is string, can be one of the following: json, int, float,bool.	map	-	Yes
  allow_quota	If set to true, a quote may appear in an unquoted field and a non-doubled quote may appear in a quoted field	bool	false	No
  order	Order of reading records from CSV. Can be random or sequential	string	random	No
  skip_first_line	Skips first line while reading records from CSV.	bool	false	No
  skip_empty_line	Skips empty lines while reading records from CSV.	bool	true	No

• success_criterias (optional)

  Config for pass fail logic for the test. abort and delay fields can be used to adjust the abort behaviour in case of failure. If abort is true for a rule and rules fails at certain point, engine will decide to abort test immediately if delay is 0 or not given. If delay is given, it will wait for delay seconds and reassert the rule.

  Example: Check 90th percentile and fail_count;

  json Copy

  {
   "duration": 10,
   <other_global_configurations>,
   "success_criterias": [
    {
      "rule" : "p90(iteration_duration) < 220",
      "abort" : false
    },
    {
      "rule" : "fail_count_perc < 0.1",
      "abort" : true,
      "delay" : 1
    },
    {
      "rule" : "fail_count < 100",
      "abort" : true,
      "delay" : 0
    }
  ],
   "steps": [....]
  }

• steps (required)

  This parameter lets you create your scenario. Ddosify runs the provided steps, respectively. For the given example file step id: 2 will be executed immediately after the response of step id: 1 is received. The order of the execution is the same as the order of the steps in the config file.

  Details of each parameter for a step;

  • id (required)

    Each step must have a unique integer id.

  • url (required)

    This is the equivalent of the -t flag.

  • name (optional)

    Name of the step.

  • method (optional)

    This is the equivalent of the -m flag.

  • headers (optional)

    List of headers with key:value format.

  • payload (optional)

    Body or payload. This is the equivalent of the -b flag.

    Note: If you want to use x-www-form-urlencoded, set Content-Type header to application/x-www-form-urlencoded.

    Example: send x-www-form-urlencoded data;

    json Copy

    {
      "headers": {
        "Content-Type": "application/x-www-form-urlencoded"
      },
      "payload": "key1=value1&key2=value2"
    }

  • payload_file (optional)

    If you need a long payload, we suggest using this parameter instead of payload.

  • payload_multipart (optional)

    Use this for multipart/form-data Content-Type.

    Accepts list of form-field objects, structured as below;

    json Copy

    {
        "name": [field-name],
        "value": [field-value|file-path|url],
        "type": <text|file>,    // Default "text"
        "src": <local|remote>   // Default "local"
    }

    Example: Sending form name-value pairs;

    json Copy

    "payload_multipart": [
        {
            "name": "[field-name]",
            "value": "[field-value]"
        }
    ]

    Example: Sending form name-value pairs and a local file;

    json Copy

    "payload_multipart": [
        {
            "name": "[field-name]",
            "value": "[field-value]",
        },
        {
            "name": "[field-name]",
            "value": "./test.png",
            "type": "file"
        }
    ]

    Example: Sending form name-value pairs and a local file and a remote file;

    json Copy

    "payload_multipart": [
        {
            "name": "[field-name]",
            "value": "[field-value]",
        },
        {
            "name": "[field-name]",
            "value": "./test.png",
            "type": "file"
        },
        {
            "name": "[field-name]",
            "value": "http://getanteon.com/test.png",
            "type": "file",
            "src": "remote"
        }
    ]

    Note: Ddosify adds Content-Type: multipart/form-data; boundary=[generated-boundary-value] header to the request when using payload_multipart.

  • timeout (optional)

    This is the equivalent of the -T flag.

  • capture_env (optional)

    Config for extraction of variables to use them in next steps.
    Example: Capture NUM variable from steps response body;

    json Copy

    "steps": [
        {
            "id": 1,
            "url": "http://getanteon.com/endpoint1",
            "capture_env": {
                 "NUM" :{"from":"body","json_path":"num"},
            }
        },
    ]

  • assertion (optional)

    The response from this step will be subject to the assertion rules. If one of the provided rules fails, step is considered as failure.
    Example: Check status code and content-length header values;

    json Copy

    "steps": [
        {
            "id": 1,
            "url": "http://getanteon.com/endpoint1",
            "assertion": [
                "equals(status_code,200)",
                "in(headers.content-length,[2000,3000])"
            ]
        },
    ]

  • sleep (optional)

    Sleep duration(ms) before executing the next step. Can be an exact duration or a range.

    Example: Sleep 1000ms after step-1;

    json Copy

    "steps": [
        {
            "id": 1,
            "url": "http://getanteon.com/endpoint1",
            "sleep": "1000"
        },
        {
            "id": 2,
            "url": "http://getanteon.com/endpoint2",
        }
    ]

    Example: Sleep between 300ms-500ms after step-1;

    json Copy

    "steps": [
        {
            "id": 1,
            "url": "http://getanteon.com/endpoint1",
            "sleep": "300-500"
        },
        {
            "id": 2,
            "url": "http://getanteon.com/endpoint2",
        }
    ]

  • auth (optional)

    Basic authentication.

    json Copy

    "auth": {
        "username": "test_user",
        "password": "12345"
    }

  • others (optional)

    This parameter accepts dynamic key: value pairs to configure connection details of the protocol in use.

    json Copy

    "others": {
        "disable-compression": false,    // Default true
        "h2": true,                      // Enables HTTP/2. Default false.
        "disable-redirect": true         // Default false
    }

Parameterization (Dynamic Variables) Copy Chapter

Just like the Postman, Ddosify supports parameterization (dynamic variables) on URL, headers, payload (body) and basic authentication. Actually, we support all the random methods Postman supports. If you use {{$randomVariable}} on Postman you can use it as {{_randomVariable}} on Ddosify. Just change $ to _ and you will be fine. To simulate a realistic load test on your system, Ddosify can send every request with dynamic variables.

The full list of dynamic variables can be found in the documentation.

Parameterization on URL Copy Section

Ddosify sends 100 GET requests in 10 seconds with random string key parameter. This approach can be also used in cache bypass.

ddosify -t https://getanteon.com/?key={{_randomString}} -d 10 -n 100

Parameterization on Headers Copy Section

Ddosify sends 100 GET requests in 10 seconds with random Transaction-Type and Country headers.

ddosify -t https://getanteon.com -d 10 -n 100 -h 'Transaction-Type: {{_randomTransactionType}}' -h 'Country: {{_randomCountry}}'

Parameterization on Payload (Body) Copy Section

Ddosify sends 100 GET requests in 10 seconds with random latitude and longitude values in body.

ddosify -t https://getanteon.com -d 10 -n 100 -b '{"latitude": "{{_randomLatitude}}", "longitude": "{{_randomLongitude}}"}'

Parameterization on Basic Authentication Copy Section

Ddosify sends 100 GET requests in 10 seconds with random username and password with basic authentication.

ddosify -t https://getanteon.com -d 10 -n 100 -a '{{_randomUserName}}:{{_randomPassword}}'

Parameterization on Config File Copy Section

Dynamic variables can be used on config file as well. Ddosify sends 100 GET requests in 10 seconds with random string key parameter in URL and random User-Key header.

ddosify -config ddosify_config_dynamic.json

{
  "iteration_count": 100,
  "load_type": "linear",
  "duration": 10,
  "steps": [
    {
      "id": 1,
      "url": "https://getanteon.com/?key={{_randomString}}",
      "method": "POST",
      "headers": {
        "User-Key": "{{_randomInt}}"
      }
    }
  ]
}

Environment Variables Copy Section

In addition, you can also use operating system environment variables. To access these variables, simply add the $ prefix followed by the variable name wrapped in double curly braces. The syntax for this is {{$OS_ENV_VARIABLE}} within the config file.

For instance, to use the USER environment variable from your operating system, simply input {{$USER}}. You can use operating system environment variables in URL, Headers, Body (Payload), and Basic Authentication.

Here is an example of using operating system environment variables in the config file. TARGET_SITE operating system environment variable is used in URL and USER environment variable is used in Headers.

export TARGET_SITE="https://getanteon.com"
ddosify -config ddosify_config_os_env.json

{
  "iteration_count": 100,
  "load_type": "linear",
  "duration": 10,
  "steps": [
    {
      "id": 1,
      "url": "{{$TARGET_SITE}}",
      "method": "POST",
      "headers": {
        "os-env-user": "{{$USER}}"
      }
    }
  ]
}

Assertion Copy Chapter

By default, Ddosify marks a step result as successful if it sends the request and receives the response without any network errors. Status code or body type (or content) does not affect the success/failure criteria. However, this may not provide a good test result for your use case, and you may want to create your own success/fail logic. That's where Assertions come in.

Ddosify supports assertions on status code, response body, response size, response time, headers, and variables. You can use the assertion parameter in the config file to check if the response matches the given condition per step. If the condition is not met, Ddosify will fail the step. Check the example config to see how it looks.

As shown in the related table, the first five keywords store different data related to the response. The last keyword, variables, stores the current state of environment variables for the step. You can use Functions or Operators to build conditional expressions based on these keywords.

You can write multiple assertions for a step. If any assertion fails, the step is marked as failed.

If Ddosify can't receive the response for a request, that step is marked as failed without processing the assertions. You will see a Server Error as the failure reason in the test result instead of an Assertion Error.

Keywords Copy Section

Functions Copy Section

Operators Copy Section

Assertion Examples Copy Section

Success Criteria (Pass / Fail) Copy Chapter

Ddosify supports success criteria, allowing users to verify the success of their load tests based on response times and failure counts of iterations. With this feature, users can assert the percentile of response times and the failure counts of all iterations in a test.

Users can specify the required percentile of response times and failure counts in the configuration file, and the engine will compare the actual response times and failure counts to these values throughout the test continuously. According to the user's configuration, the test can be aborted or continue running until the end. Check the example config to see how the success_criterias keyword looks.

Note that the functions and operators mentioned in the Step Assertion section can also be utilized for the Success Criteria keywords listed below.

You can see a success criteria example in the EXAMPLES file.

Difference Between Success Criteria and Step Assertions Copy Chapter

Unlike assertions focused on individual steps, which determine the success or failure of a step according to its response, Success Criteria create an abort/continue logic for the entire test, which is based on the accumulated data from all iterations.

Keywords Copy Section

Functions Copy Section

Examples Copy Section

Correlation Copy Chapter

Ddosify enables you to capture variables from steps using json_path, xpath, xpath_html, or regular expressions. Later, in the subsequent steps, you can inject both the captured variables and the scenario-scoped global variables.

:warning: Points to keep in mind

• You must specify 'header_key' when capturing from header.
• For json_path syntax, please take a look at gjson syntax doc.
• Regular expression are expected in 'Golang' style regex. For converting your existing regular expressions, you can use regex101.
• You can extract values from headers, body, and cookies.

You can use debug parameter to validate your config.

ddosify -config ddosify_config_correlation.json -debug

Capture with json_path Copy Section

{
  "steps": [
    {
      "capture_env": {
        "NUM": { "from": "body", "json_path": "num" },
        "NAME": { "from": "body", "json_path": "name" },
        "SQUAD": { "from": "body", "json_path": "squad" },
        "PLAYERS": { "from": "body", "json_path": "squad.players" },
        "MESSI": { "from": "body", "json_path": "squad.players.0" }
      }
    }
  ]
}

Capture with XPath on XML Copy Section

{
  "steps": [
    {
      "capture_env": {
        "TITLE": { "from": "body", "xpath": "//item/title" }
      }
    }
  ]
}

Capture with XPath on HTML Copy Section

{
  "steps": [
    {
      "capture_env": {
        "TITLE": { "from": "body", "xpath_html": "//body/h1" }
      }
    }
  ]
}

Capture with Regular Expressions Copy Section

{
  "steps": [
    {
      "capture_env": {
        "CONTENT_TYPE": {
          "from": "header",
          "header_key": "Content-Type",
          "regexp": { "exp": "application/(\\w)+", "matchNo": 0 }
        },
        "REGEX_MATCH_ENV": {
          "from": "body",
          "regexp": { "exp": "[a-z]+_[0-9]+", "matchNo": 1 }
        }
      }
    }
  ]
}

Capture Header Value Copy Section

{
  "steps": [
    {
      "capture_env": {
        "TOKEN": { "from": "header", "header_key": "Authorization" }
      }
    }
  ]
}

Scenario-Scoped Variables Copy Section

{
  "env": {
    "TARGET_URL": "http://localhost:8084/hello",
    "USER_KEY": "ABC",
    "COMPANY_NAME": "Ddosify",
    "RANDOM_COUNTRY": "{{_randomCountry}}",
    "NUMBERS": [22, 33, 10, 52]
  }
}

Overall Config and Injection Copy Section

On array-like captured variables or environment vars, the rand( ) function can be utilized.

// ddosify_config_correlation.json
{
  "iteration_count": 100,
  "load_type": "linear",
  "duration": 10,
  "steps": [
    {
      "id": 1,
      "url": "{{TARGET_URL}}",
      "method": "POST",
      "headers": {
        "User-Key": "{{USER_KEY}}",
        "Rand-Selected-Num": "{{rand(NUMBERS)}}"
      },
      "payload": "{{COMPANY_NAME}}",
      "capture_env": {
        "NUM": { "from": "body", "json_path": "num" },
        "NAME": { "from": "body", "json_path": "name" },
        "SQUAD": { "from": "body", "json_path": "squad" },
        "PLAYERS": { "from": "body", "json_path": "squad.players" },
        "MESSI": { "from": "body", "json_path": "squad.players.0" },
        "TOKEN": { "from": "header", "header_key": "Authorization" },
        "CONTENT_TYPE": {
          "from": "header",
          "header_key": "Content-Type",
          "regexp": { "exp": "application/(\\w)+", "matchNo": 0 }
        }
      }
    },
    {
      "id": 2,
      "url": "{{TARGET_URL}}",
      "method": "POST",
      "headers": {
        "User-Key": "{{USER_KEY}}",
        "Authorization": "{{TOKEN}}",
        "Content-Type": "{{CONTENT_TYPE}}"
      },
      "payload_file": "payload.json",
      "capture_env": {
        "TITLE": { "from": "body", "xpath": "//item/title" },
        "REGEX_MATCH_ENV": {
          "from": "body",
          "regexp": { "exp": "[a-z]+_[0-9]+", "matchNo": 1 }
        }
      }
    }
  ],
  "env": {
    "TARGET_URL": "http://localhost:8084/hello",
    "USER_KEY": "ABC",
    "COMPANY_NAME": "Ddosify",
    "RANDOM_COUNTRY": "{{_randomCountry}}",
    "NUMBERS": [22, 33, 10, 52]
  }
}

// payload.json
{
  "boolField": "{{_randomBoolean}}",
  "numField": "{{NUM}}",
  "strField": "{{NAME}}",
  "numArrayField": ["{{NUM}}", 34],
  "strArrayField": ["{{NAME}}", "hello"],
  "mixedArrayField": ["{{NUM}}", 34, "{{NAME}}", "{{SQUAD}}"],
  "{{NAME}}": "messi",
  "obj": {
    "numField": "{{NUM}}",
    "objectField": "{{SQUAD}}",
    "arrayField": "{{PLAYERS}}"
  }
}

Test Data Set Copy Chapter

Ddosify enables you to load test data from CSV files. Later, in your scenario, you can inject variables that you tagged.

We are using this CSV data in config below.

// config_data_csv.json
"data":{
      "csv_test": {
          "path" : "config/config_testdata/test.csv",
          "delimiter": ";",
          "vars": {
                  "0":{"tag":"name"},
                  "1":{"tag":"city"},
                  "2":{"tag":"team"},
                  "3":{"tag":"payload", "type":"json"},
                  "4":{"tag":"age", "type":"int"}
                },
          "allow_quota" : true,
          "order": "random",
          "skip_first_line" : true
      }
    }

You can refer to tagged variables in your request like below.

// payload.json
{
  "name": "{{data.csv_test.name}}",
  "team": "{{data.csv_test.team}}",
  "city": "{{data.csv_test.city}}",
  "payload": "{{data.csv_test.payload}}",
  "age": "{{data.csv_test.age}}"
}

Cookies Copy Chapter

Ddosify supports cookies in the following engine modes: distinct-user and repeated-user. Cookies are not supported in the default ddosify mode.

In repeated-user mode, Ddosify uses the same cookie jar for all iterations executed by the same user. It sets cookies returned at the first successful iteration and does not change them afterward. This way, the same cookies are passed through steps in all iterations executed by the same user.

In distinct-user mode, Ddosify uses a different cookie jar for each iteration, so cookies are passed through steps in one iteration only.

You can see a cookie example in the EXAMPLES file.

Initial / Custom Cookies Copy Section

You can set initial/custom cookies for your test scenario using cookie_jar field in the config file. You can enable/disable custom cookies with enabled key. Check the example config.

Cookie Capture Copy Section

You can capture values from cookies from its name just like you do for headers and body and use them in your test scenario.

{
    "iteration_count": 100,
    "load_type": "linear",
    "duration": 10,
    "steps": [
        {
          ...
          "capture_env": {
            "TEST" :{"from":"cookies","cookie_name":"test"}
          }
        }
    ]
}

Cookie Assertion Copy Section

You can refer to cookie values as cookies.cookie_name while you write assertions for your steps.

Following fields are available for cookie assertion:

• name: Name of the cookie
• domain: Domain of the cookie
• path: Path of the cookie
• value: Value of the cookie
• expires: Expiration date of the cookie
• maxAge: Max age of the cookie
• secure: Secure flag of the cookie
• httpOnly: Http only flag of the cookie
• rawExpires: Raw expiration date of the cookie

Examples:

• cookies.test.expires < time(\"Thu, 01 Jan 1990 00:00:00 GMT\") is a valid assertion expression. It checks if the cookie named test has an expiration date before Thu, 01 Jan 1990 00:00:00 GMT.
• cookies.test.path == \"/login\" is another valid assertion expression. It checks if the cookie named test has a path value equal to /login.

Common Issues Copy Chapter

macOS Security Issue Copy Section

"ddosify" can’t be opened because Apple cannot check it for malicious software.

• Open /usr/local/bin
• Right click ddosify and select Open
• Select Open
• Close the opened terminal

OS Limit - Too Many Open Files Copy Section

If you create large load tests, you may encounter the following errors:

Server Error Distribution (Count:Reason):
  199      :Get "https://getanteon.com": dial tcp 188.114.96.3:443: socket: too many open files
  159      :Get "https://getanteon.com": dial tcp 188.114.97.3:443: socket: too many open files

This is because the OS limits the number of open files. You can check the current limit by running ulimit -n command. You can increase this limit to 50000 by running the following command on both Linux and macOS.

ulimit -n 50000

But this will only increase the limit for the current session. To increase the limit permanently, you can change the shell configuration file. For example, if you are using bash, you can add the following lines to ~/.bashrc file. If you are using zsh, you can add the following lines to ~/.zshrc file.

# For .bashrc
echo "ulimit -n 50000" >> ~/.bashrc

# For .zshrc
echo "ulimit -n 50000" >> ~/.zshrc

Contributing Copy Chapter

See our Contribution Guide and please follow the Code of Conduct in all your interactions with the project.

Communication Copy Chapter

You can join our Discord Server for issues, feature requests, feedbacks or anything else.

Disclaimer Copy Chapter

Ddosify is created for testing the performance of web applications. Users must be the owner of the target system. Using it for harmful purposes is extremely forbidden. Ddosify team & company is not responsible for its’ usages and consequences.

License Copy Chapter

Licensed under the AGPLv3

File: selfhosted/README.md Copy Chapter

Anteon Self Hosted: Effortless Kubernetes Monitoring and Performance Testing

📚 Documentation Copy Chapter

• 🐝 Installing Anteon Self-Hosted
• ⚙ Installing eBPF Agent (Alaz)
• 📰 Upgrading to Self-Hosted Enterprise
• 📧 Slack Integration

See the documentation for other guides such as disabling telemetry.

📝 License Copy Chapter

Anteon Self Hosted is licensed under the AGPLv3