The idea of containers is to ensure a certain isolation of processes, especially due to the namespace. This means, among others the default restriction of information that users can expect to monitor.

In the current situation Zabbix-Agent running in the container is not able even to monitor the used and available space of file systems. It has not been properly adapted to work in a containerized environment and there is no access to such information.

In order to solve such a problem, software of similiar class use mount of directories from the host that contain the required information to custom paths. For example, through the Docker container launch parameters "-v /dev:/host/dev -v /proc:/host/proc". This allows process inside container to read the required information if the application will be adapted to try such paths. Limiting insulation does not deny the idea of container, because - in my environment - the largest value of containers is easy management of configuration and software version, which is not eliminated by additional mounting points like that.

See examples of mountpoint at https://github.com/bvis/docker-node-exporter/blob/master/README.md and https://github.com/google/cadvisor .

Filesystems discovered inside of container:
root@73da6b91545d:/var/lib/zabbix# zabbix_agentd -t vfs.fs.discovery
vfs.fs.discovery s

Values similar hosts without container:
$ sudo zabbix_agentd -t vfs.fs.discovery
vfs.fs.discovery s