btrfs filesystem monitoring;

[ktsaou]

fixes #3095 (check it for the discussion of this implementation - we went through a few phases)

btrfs monitoring:

1. physical disk space allocation + alarm
2. data allocation + alarm
3. metadata allocation + alarm
4. system allocation + alarm

---

also re-arranged the priorities of NFS and ZFS to appear after Disk on the dashboard, and all of them close to each other.

[Ferroin]

I've left some comments about the implementation in the associated issue (#3095, I saw the messages for that before I saw the PR).

Beyond those comments though, I've tested this, and it all works as advertised for every setup I tested (single disk with both single and dup profile, two disks with raid1, raid0, single, and dup profile, and 4 disks with raid10 profile).

[ktsaou]

@Ferroin thanks!
Check the new one too. It is implemented as we agreed (physical disk monitoring, etc).

[Ferroin]

@ktsaou Comments about the implementation back on the issue.

I won't be able to test this today, but will try to get to it first thing tomorrow.

[ktsaou]

@Ferroin this is done.
I have added dashboard information and alarms.

Ideally, I would love to have a better description above each chart. I used a few of your phrases already. If you can spare some time on this I would love to add better info and possibly simple instructions or links to related documentation.

This is what I have added:

    'btrfs.disk': {
        info: 'Physical disk usage of BTRFS. The disk space reported here, is the raw physical disk space assigned to the BTRFS volume (i.e. <b>before any RAID levels</b>). BTRFS uses a two-stage allocator, first allocating large regions of disk space for one type of block (data, metadata, or system), and then using a regular block allocator inside those regions. <code>unallocated</code> is the physical disk space that is not allocated yet and is available to become data, metdata or system on demand. When <code>unallocated</code> is zero, all available disk space has been allocated to a specific function.'
    },

    'btrfs.data': {
        info: 'Logical disk usage for BTRFS data. The disk space reported here is the usable allocation (i.e. after any RAID levels).'
    },

    'btrfs.metadata': {
        info: 'Logical disk usage for BTRFS metadata. The disk space reported here is the usable allocation (i.e. after any RAID levels).'
    },

    'btrfs.system': {
        info: 'Logical disk usage for BTRFS system. The disk space reported here is the usable allocation (i.e. after any RAID levels).'
    }

[Ferroin]

I can look into providing a better description, but it will probably be later this week.

I don't know whether you want to merge what's here now, and I can just submit a PR to update the descriptions, or just wait for me to get the updated descriptions, but I'm fine with either option.

[ktsaou]

ok. looking forward for your PR...
merged it.

[Ferroin]

OK, I'll look at getting the PR made out some time this week.

I'm also going to make an announcement on the BTRFS mailing list that Netdata now has support for monitoring BTRFS space usage, so you may get an above average influx of new users over the next few weeks (there's a very significant demand for better monitoring with BTRFS).

[ktsaou]

perfect!

[Ferroin]

OK, just took the time to read through the actual descriptions you provided, and I don't think I can come up with any better descriptions without getting into the really-technical low-level stuff about the allocator. Unless you particularly want me to come up with such highly-technical descriptions, I think it's best to just leave them as-is.

[ktsaou]

hm... ok. I was thinking of some information about what can be done when people run out of space. I mean, if I run out of btrfs space, I normally search for something to guide me how to reclaim space.

But anyway, you know...

[Ferroin]

Good point. I"ll look at getting something a bit more descriptive written up today, but it likely won't be much beyond basic advice. If things are bad enough that you really are out of space, then it's generally simpler to just blow away the whole volume and restore from a backup (onto a bigger volume of course), and I don't feel that it presents the best image to put such advice in the descriptions.