bluewave-labs / bluewave-labs/capture
[BUG]: Disk discovery fails to identify all mounted filesystems (only shows the root partition, ignoring other mounted volumes)
- Dominant language
- Go
- Stars
- 301
- Forks
- 37
- PR merge metrics
- No merged PRs in 30d
Description
**Describe the bug**
The monitoring application does not seem to be correctly detecting all mounted disk partitions. In my case, the application only displays the root filesystem (/), while other mounted partitions, such as /mnt/example and /home/example, are not being monitored or displayed in the dashboard.
The dashboard shows a single "Disk0" with 50 GB of storage, which corresponds to my root partition (/dev/sda1). However, it ignores other larger partitions that are clearly mounted and in use, as shown in the df -Th output.
**To reproduce**
Steps to reproduce the behavior:
1. Run the Capture application on a system with multiple mounted disk partitions.
2. Open the web dashboard.
3. Observe the "Disk" and "Disk0 usage" widgets.
4. Notice that only the root partition is displayed, and other partitions are missing.
**Screenshots**


**System information**
Please provide the following information to help us debug the issue:
- Operating System (with version): Centos 7
- CPU Architecture:
- Capture Version: Latest (V1.1.0)
- Installation Method (binary, container, etc.): Docker
- Output of `uname -a`:
```shell
Linux d2-8-gra11-backup-matisse 3.10.0-1160.118.1.el7.x86_64 #1 SMP Wed Apr 24 16:01:50 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
```
- Output of `lsblk`:
```shell
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 50G 0 disk
└─sda1 8:1 0 50G 0 part /
sdb 8:16 0 1000G 0 disk
└─sdb1 8:17 0 1000G 0 part /home/example
sdc 8:32 0 2.5T 0 disk
└─sdc1 8:33 0 2.5T 0 part /mnt/example
```
- Output of `df -Th`:
```shell
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 3.7G 0 3.7G 0% /dev
tmpfs tmpfs 3.8G 0 3.8G 0% /dev/shm
tmpfs tmpfs 3.8G 33M 3.7G 1% /run
tmpfs tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup
/dev/sda1 xfs 50G 29G 22G 58% /
/dev/sdc1 ext4 2.5T 1.9T 454G 81% /mnt/example
/dev/sdb1 ext4 985G 854G 81G 92% /home/example
overlay overlay 50G 29G 22G 58% /var/lib/docker/overlay2......
tmpfs tmpfs 764M 0 764M 0% /run/user/0
```
- Root Filesystem Type: xfs
**Logs**
- Capture metrics responses (if applicable):
```json
{
"data": {
"cpu": {
"physical_core": 4,
"logical_core": 4,
"frequency": 2394.452,
"current_frequency": 0,
"temperature": null,
"free_percent": 1,
"usage_percent": 0
},
"memory": {
"total_bytes": 8001392640,
"available_bytes": 7119503360,
"used_bytes": 543305728,
"usage_percent": 0.0679
},
"disk": [
{
"device": "/dev/sda1",
"total_bytes": 53675536384,
"free_bytes": 22882369536,
"used_bytes": 30793166848,
"usage_percent": 0.5737,
"total_inodes": 26213824,
"free_inodes": 25767815,
"used_inodes": 446009,
"inodes_usage_percent": 0.017,
"read_bytes": 1021183488,
"write_bytes": 1034708992,
"read_time": 10029,
"write_time": 102036
}
],
"host": {
"os": "linux",
"platform": "centos",
"kernel_version": "3.10.0-1160.118.1.el7.x86_64"
}
},
"errors": [
{
"metric": [
"cpu.temperature"
],
"err": "unable to read CPU temperature"
},
{
"metric": [
"cpu.current_frequency"
],
"err": "open /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq: no such file or directory"
}
]
}
```
Contributor guide
Research direction
Start by reproducing the disk metrics response on a system matching the issue's lsblk and df -Th examples, then trace the disk-metrics collection entry point. Compare the reported disk list with all mounted filesystems. Done means the dashboard and metrics response include the mounted volumes beyond the root partition.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- observability-sre
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100