The config.yml configures some global measurement settings that are used when executing the directly or through cron mode.

Here is an example configuration:

  name: My test project

  idle-time-start: 5
  idle-time-end: 5
  flow-process-runtime: 60
        resolution: 100
        resolution: 100
        resolution: 100
        resolution: 100
  #      resolution: 100
        # This is a default configuration. Please change this to your system!
  #      CPUChips: 1
  #      HW_CPUFreq: 3100
  #      CPUCores: 28
  #      TDP: 150
  #      HW_MemAmountGB: 16

  # This address will get an email, when a new project was added through the frontend
  email: [email protected]
  # no_emails: True will suppress all emails. Helpful in development servers
  no_emails: True

The postgresql, smtp and config key were already discussed in the installation → part.

We will this only focus on the measurement key:

  • idle-time-start [integer]: Seconds to idle containers after orchestrating but before start of measurement
  • idle-time-end [integer]: Seconds to idle containers after measurement
  • flow-process-runtime [integer]: Max. duration in seconds for how long one flow should take. Timeout-Exception is thrown if exceeded.
  • metric-providers:
    • linux/macos/common [string]: Specifies under what system the metric provider can run. Common implies it could run on either.
      • METRIC_PROVIDER_NAME [string]: Key specifies the Metric Provider. Possible Metric Providers →
      • METRIC_PROVIDER_NAME.resolution [integer]: sampling resolution in ms

Some metric providers have unique configuration params:

Also note that some providers are deactivated by default, because they either need a additional configuration parameters, extra hardware or a specially configured system.

Once you have set them up you can uncomment the line. In this example for instance the line and all the lines directly below it.


The admin key provides no configuration for the measurements themselves, but rather how the framework behaves.

  • email: The email where to error mails and debug mails to
  • no_emails: If the framework should send emails at all (including error mails).
    • If you have not SMTP configured you must set this to False

Switches for

Apart from the config.yml some configuration is additionally possible when doing manual runs with the

  • --uri The URI to get the usage_scenario.yml from.
    • If given a URL starting with http(s) the tool will try to clone a remote repository to /tmp/green-metrics-tool/repo
    • If given a local directory starting with /, this will be used instead.
  • --branch When providing a git repository, optionally specify a branch
  • --name A name which will be stored to the database to discern this run from others
  • --filename An optional alternative filename if you do not want to use “usage_scenario.yml”
  • --no-file-cleanup flag to not delete the metric provider data in /tmp/green-metrics-tool
  • --debug flag to activate steppable debug mode
    • This allows you to enter the containers and debug them if necessary.
  • --allow-unsafe flag to activate unsafe volume bindings, ports, and complex env vars
    • Arbitrary volume bindings into the containers. They are still read-only though
    • Portmappings to the host OS.
    • Non-Strict ENV vars mapped into container
  • --skip-unsafe flag to skip unsafe volume bindings, ports and complex env vars
    • This is typically done when reusing already present compose.yml files without the need to alter the file
  • --verbose-provider-boot flag to boot metric providers gradually
    • This will enable the user to see the impact of each metric provider more clearly
    • There will be a 10 second sleep for two seconds after each provider boot
    • RAPL metric providers will be prioritized to start first, if enabled

These options are not available when doing cron runs.

Typical calls

Local app

python3 --uri PATH_TO_MY_SAMPLE_APP_FOLDER --name MY_NAME`

Github repository

python3 --uri --name MY_NAME