Green Metric tool on Linux VM

[Orokusaki90]

Hi all,

I need a little help regarding the green metric tool. I have tried to install the tool on linux VM in Hyper-V virtualization. Tool is installed, containers are up and running but scanning of the repositories are not working.
Also tried that example measuring test app locally, running the py script but still no luck, got this error:

Tried the same on VM on azure and the error is still the same. Could it be that it cant work on virtualized machine? Did anybody tried to use this on vm?
Thank you so much for help.

[ArneTR]

Hey @Orokusaki90

thx for trying out the tool!

The message you are getting is related to the restrictions in the VM. The CpuFrequency Provider will not work as in your VM this resource in the linux subsystem is blocked from reading.

Just deactivate the reporters in the config.yml that are throwing similar errors. Probably the RAPL reporters will also not work and you might have to resort to use one of our estimation reporters like XGBoost Estimation

Feel free to add more comments if further erros occur. Happy to help :)

[ArneTR]

To also follow up on your question: Yes our tool works in VMs. Just some reporters are restricted depending on where you run it.

Here is an example of a a config.yml we use at our provider Hetzner

    linux:
    #--- Always-On - We recommend these providers to be always enabled
      cpu.utilization.procfs.system.provider.CpuUtilizationProcfsSystemProvider:
        resolution: 100
    #--- CGroupV2 - Turn these on if you have CGroupsV2 working on your machine
      cpu.utilization.cgroup.container.provider.CpuUtilizationCgroupContainerProvider:
        resolution: 100
      memory.total.cgroup.container.provider.MemoryTotalCgroupContainerProvider:
        resolution: 100
      network.io.cgroup.container.provider.NetworkIoCgroupContainerProvider:
        resolution: 100
    #--- RAPL - Only enable these if you have RAPL enabled on your machine
#      cpu.energy.RAPL.MSR.system.provider.CpuEnergyRaplMsrSystemProvider:
#        resolution: 100
#      memory.energy.RAPL.MSR.system.provider.MemoryEnergyRaplMsrSystemProvider:
#        resolution: 100
    #--- System power - These providers need special hardware / lab equipment to work
#      psu.energy.ac.gude.system.provider.PsuEnergyAcGudeSystemProvider:
#        resolution: 100
#      psu.energy.dc.picolog.system.provider.PsuEnergyDcPicologSystemProvider:
#        resolution: 61 # Do not change this. Provider is tailored to work at fixed resolution
#      psu.energy.ac.powerspy2.system.provider.PsuEnergyAcPowerspy2SystemProvider:
#        resolution: 250
#      psu.energy.ac.ipmi.system.provider.PsuEnergyAcIpmiSystemProvider:
#        resolution: 100
    #--- Sensors
#      lm_sensors.temperature.provider.LmSensorsTempProvider:
#        resolution: 100
      #-- Please change these values according to the names in '$ sensors'
#        chips: ['thinkpad-isa-0000', 'coretemp-isa-0000']
#        features: ['CPU', 'Package id 0', 'Core 0', 'Core 1', 'Core 2', 'Core 3']
#      lm_sensors.fan.provider.LmSensorsFanProvider:
#        resolution: 100
      # Please change these values according to the names in '$ sensors'
#        chips: ['thinkpad-isa-0000']
#        features: ['fan1', 'fan2']
    #--- Debug - These providers are just for development of the tool itself
#      cpu.time.cgroup.container.provider.CpuTimeCgroupContainerProvider:
#        resolution: 100
#      cpu.time.cgroup.system.provider.CpuTimeCgroupSystemProvider:
#        resolution: 100
#      cpu.time.procfs.system.provider.CpuTimeProcfsSystemProvider:
#        resolution: 100
    macos:
    #--- MacOS: On Mac you only need this provider. Please delete all others!
#      powermetrics.provider.PowermetricsProvider:
#        resolution: 100
    common:
    #--- Model based
#      psu.energy.ac.sdia.machine.provider.PsuEnergyAcSdiaMachineProvider:
#        resolution: 100
      #-- This is a default configuration. Please change this to your system!
#        CPUChips: 1
#        TDP: 150
      psu.energy.ac.xgboost.machine.provider.PsuEnergyAcXgboostMachineProvider:
        resolution: 100
      #-- This is a default configuration. Please change this to your system!
        CPUChips: 1
        HW_CPUFreq: 2100
        CPUCores: 1
        CPUThreads: 1
        TDP: 150
        HW_MemAmountGB: 2
        Hardware_Availability: 2015
  #--- END

The parameters that you have to feed into your config for the XGBoost will however for sure be different. So just check the specs of your VM

[Orokusaki90]

When install script asks me for api url i set http://example-gmt:9142 and for dashboard i use the same just with different port http://example-gmt:9143?

[ArneTR]

jap, this is exactly what I meant.

I forgot to mention some changes though, since I was assuming some stuff was done automatically, which is not the case for the NGINX and compose files. Only for Python and Javascript.

You also must tell the container to bind to the other port and also tell the NGINX server to listen on that respective address.

Here is the relevant files and their parts that you have to change:

docker/nginx/frontend.conf

server {
    listen [::]:80;
    listen [::]:9143;
    listen [::]:443;

    listen 80;
    listen 9143;
    listen 443;
   ...

docker/compose.yml

...
green-coding-nginx:
    image: nginx
    container_name: green-coding-nginx-container
    depends_on:
      - green-coding-postgres
    ports:
      - 9143:9143
      - 9142:9142
...

These both files are in the ´.gitignore´, so the changes will not get lost if you make a git pull. However they will not persist an update, so they have to be replayed if you run the install script again.

At the moment we do not have this feature officially supported, but if have it working and want to have it in the repo, we are happy to take a pull requests with the needed modifications in the install script to preserve the port choices if it differs from 9142

[Orokusaki90]

I have reinstalled the tool, and separated the api and dashboard. Now i got an error when i open the dashboard:

API i available, i can access it

[ArneTR]

maybe a caching issue? Can you open the developer tools, open the network tab, turn on "disable cache", reload, and if it still does not work send a screenshot showing only the "Fech/XHR" requests and which URLs they are going to?

Similar to this:

[Orokusaki90]

Cache disable didnt help. It looks like it is using the internal name(Dashboard trying to reach API on that name).

[Orokusaki90]

I have managed to make it work. I have hardcoded the API_URL and METRIC_URL in config.js to use ipaddress instead of names, and added in CORS source ip

[ArneTR]

Nice that you got it working! I am lacking some information to further understand why my explanation did not work, but that should have been the correct steps.

Hardcoding is always an option though :)

[oblancox]

Hello, I currently have the tool running on a virtual machine in Azure, although as you have mentioned with some reporters disabled. However I am running into some problems running the measurement tool (runner.py) on an own example application. From what I see, the application code should be below the directory of the usage_scenario file (already solved).
But when using a puppeter image (based on the examples in repo)

the following error occurs: Is it not possible to reference an absolute path?

[ArneTR]

my first question is: What are you trying to accomplish with the scenario in particular?

Binding the X11 socket is usally only useful if you have a Window Manager running and also a display to look at stuff. Does your Azure VM have that?

2. You cannot issue bind mounts for paths outside of the repository folder in normal mode for security reasons. If you want to do that you have to start the tool in CLI mode with the flag --allow-unsafe

Hope that helps. Please follow up for any more questions., happy to help.

If the question is separte / new topic please consider making a separate issue which is better searchable in the end and might others with a similar issue :)

[oblancox]

Thank you so much
I was doing tests to measure the SCI in a web application (Backend, frontend and client). I have already seen the problem and it is solved and working. I'm closing the topic so as not to dirty the thread.