I was wondering why the numbers reported for free disk space were way too high and went to investigate. Switched on debug log and found this in the log:
Compare free disk space of ~8.4 GB with reported free disk space of 23922294784 and total disk space of ~16G with reported total disk space of 35769786368.
I'm running the 5.0.0-alpha4 versions of ELK+beats.
It looks like you are comparing verf. to system.fsstat.free which are not the same. Metricbeat's fsstats does not report available, but I think it should (care to file an issue or open a PR to fix it?). If you sum the system.filesystem.avail values they will equal 8.4G.
I will look into it re PR if I have time. Any idea about "total" and "used" sizes which are seemingly wrong as well? The VMs disk is only 16GB in total, how can fsstat report 35GB total nad 11GB used?
Try doing the same analysis that I did. I expect you'll be able to better determine the source of the error or bug. Compare the output of df --total against one set of samples from the fsstats and filesystem metricsets.
Thanks for the information. Looks like the mount table contains entries for rootfs and /dev/sda3 that are identical. It seems that df ignores the rootfs entry.
Where is the rootfs device coming from? Is that LVM? Why does df ignore that device? At this point I have more questions than answers. I need to do some reading.
I did a bit of research, and it looks like df doesn't always list all the mounted file systems. Here is an example where df doesn't list all NFS mounted file system, and it only works with df -a.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.