Allow Setting-up docker container hostname via environment variable

[jo-chemla]

Is your feature request related to a problem? Please describe.
Context is mentioned here, I'm using portainer edge stacks to deploy a glances agent on a list of servers. Portainer does not pass its own container hostname to the containers created from the stack. Passing the HOSTNAME environment variable from a env_file: .env in the compose stack, or mapping the /etc/hostname:/etc/hostname:ro is not sufficent enough, since running the hostname command on the container will show a hostname different from both values.

Describe the solution you'd like
It would be nice if hostname could be passed to the docker container as an environment variable. This way it would be possible to have an explicit name that is dependent on the real host hostname, rather than a manually set value. Manually setting that value is indeed impossible for agents deployed as portainer stacks.

Describe alternatives you've considered
Using one .env per host is probably the solution, but docker-compose doees not populate environment variables like hostname: ${CUSTOM_HOSTNAME}

Also, it is possible using such endpoint could potentially work, but at the moment I'm faced with error: hostname: sethostname: Operation not permitted. Or cap_add: - SYS_ADMIN but would give root access to host.

    volumes:
      # ...
      - /etc/hostname:/etc/hostname:ro
    entrypoint: ['/bin/sh', '-c', 'echo "setting hostname" && hostname -F /etc/hostname && hostname && python -m glances -C /glances/conf/glances.conf $GLANCES_OPT']

[nicolargo]

Hi @jo-chemla

let me reword in order to be sure that i understand this enhancement request goal.

When you run Glances Docker image from Portainer, then hostname in the system plugin is not displayed correctly.

So you need a way to use a environment variable ${CUSTOM_HOSTNAME} in this plugin.

Is it correct ?

Nevertheless, do you know that the message (displayed by system's plugin) is configurable deom the configuration file:

[system]
# This plugin display the first line in the Glances UI with:
# Hostname / Operating system name / Architecture information
# Set to true to disable a plugin
disable=False
# Default refresh rate is 60 seconds
#refresh=60
# System information to display (a string where {key} will be replaced by the value)
# Available information are: hostname, os_name, os_version, os_arch, linux_distro, platform
system_info_msg= | My MachineHostName system |

For the moment it is not possible to use environment's variables in the system_info_msg value but the improvement is possible. In the meanwhile you can set it statically.

[jo-chemla]

Thanks for getting back.

That's indeed correct, except that I don't know about the system plugin. The glances container hostname is a random string, that does not appear in the glances browser (since I can set the agent IP and friendly-name), but does get written to the influxdb and sqlite databases by each agent. Therefore, with the grafana dashboard proposed for influxdb 2, the same rand strings appear as hostnames rather than friendly names for each agent. .

It is probably set by portainer or docker when it creates the container, also probably due to a portainer bug introduced recently which does not populate environment variables and might get resolved at some point. It would therefore be useful to pass-through that hostname variable from docker host to container.

After reading through the demo config, that system_info_msg could be the solution if it is indeed what is retrieved by grafana dashboard drop-down list.

Thanks!

[jo-chemla]

By the way, is there a way to reduce the RAM memory footprint for glances? The command with export to influxdb does show some pretty high memory footprint: python3 -m glances -C /glances/conf/glances.conf --export influxdb2

I assume there is a way to do so via glances retention policies, similar to how netdata does it

For the Parent, besides setting up streaming, this example also provides configuration for multiple tiers of metrics storage, for 10 Children, with about 2k metrics each. This allows for:

• 1s granularity at tier 0 for 1 week
• 1m granularity at tier 1 for 1 month
• 1h granularity at tier 2 for 1 year

Requiring:

• 25GB of disk
• 3.5GB of RAM (2.5GB under pressure)

# netdata.conf
[db]
    mode = dbengine
    dbengine tier backfill = new
    storage tiers = 3
    dbengine page cache size = 1.4GiB
    # storage tier 0
    update every = 1
    dbengine tier 0 retention space = 12GiB
    # storage tier 1
    dbengine tier 1 update every iterations = 60
    dbengine tier 1 retention space = 4GiB
    # storage tier 2
    dbengine tier 2 update every iterations = 60
    dbengine tier 2 retention space = 2GiB

EDIT: I've tried to set refresh=5, history_size=100 to see if this helps, since it's exporting there is no need for a large history. It seems to solve the memory-hundry behavior.