collectd / collectd

The system statistics collection daemon. Please send Pull Requests here!
http://collectd.org
Other
3.03k stars 1.23k forks source link

disk plugin: Allow multiple instances of (or regex in) UdevNameAttr option. #1752

Open Speeddymon opened 8 years ago

Speeddymon commented 8 years ago

I have both md and lvm in use on my server and right now with filtering off, the md and lvm devices both appear with their raw device names (mdxxx and dm-x)

If I set UdevNameAttr "DM_LV_NAME" then the lvm devices show with their lv names (lv_8tb for example) If I set UdevNameAttr "MD_NAME" then the lvm devices show with their md names (8tb_raid10 for example) If I try to set both on two different lines, as can be done with MountPoint in the df plugin, then only the last entry applies, and so I still get raw devnames for whichever one is not last.

Please add support for multiple lines of UdevNameAttr, or allow RegEx. Either of the below will be sufficient, though Option A is my personal preference.

Option A: UdevNameAttr "DM_LV_NAME" UdevNameAttr "MD_NAME"

Option B: UdevNameAttr "/^(DM_LV|MD)_NAME$/"

rpv-tomsk commented 8 years ago

PR #1721 has a problem (Need specify "phase" how to apply ignorelist - before name rewrite by udev or after) which may be related.

rpv-tomsk commented 8 years ago

How should we resolve the situation when both rules can change the [reported] device name? Should we stop on first match or we need to specify filter rules in UdevNameAttr (something like UdevNameAttr 'ATTR' 'MATCHREGEX' syntax)?

At first look, 'stop on first match' applicable when used with MD + LVM + SATA. Typical usecase will use unique identifiers for each subsystem.

Speeddymon commented 8 years ago

Collectd shouldn't be changing device names. Udev handles that. Collectd should only change the rrd paths.

If there is a path naming conflict resulting from the changing of rrd paths based on the devname selected by UdevNameAttr, then just adding _1 or whatever to the rrd pathname would be acceptable.

rpv-tomsk commented 8 years ago

Collectd core does not know nothing about rrd files. Plugin 'rrdtool' writes rrd files but it does not know nothing about device names and unable to 'just add _1 or whatever' therefore. I see no way how to help you in this case.

Speeddymon commented 8 years ago

I understand. Allow me to rephrase my original request.

I request to specify each device as separate section in the config, as in how apache plugin is done:

LoadPlugin apache
<Plugin apache>
    <Instance a>
        URL "http://example.com/status?auto"
    </Instance>
</Plugin>

Except for Disk plugin, I request for it like this:

LoadPlugin disk
<Plugin Disk>
    <Type PhysicalDisks>
        Disk "/^[hs]d[a-z]?[0-9]?[0-9]?$/"
    </Type>
    <Type MD_Arrays>
        Disk "/^md[0-9]?[0-9]?[0-9]?$/"
        UdevNameAttr "MD_NAME"
    </Type>
    <Type Logical_Volumes>
        Disk "/^vg.*-lv_.*$/"
        UdevNameAttr "DM_LV_NAME"
    </Type>
</Plugin>

To address that concern with the ignore list, the Grouping could be like so:

LoadPlugin disk
<Plugin Disk>
    <Type Partitions>
        Disk "/^[hs]d[a-z][0-9][0-9]?$/"
        IgnoreSelected true
    </Type>
    <Type PhysicalDisks>
        UdevNameAttr "ID_PATH"
        IgnoreSelected false
    </Type>
</Plugin>

In this way, partitions are filtered out and physical disks are processed with UdevNameAttr enabled, so that the partitions don't get the UdevNameAttr applied to them, and thus the partitions won't be renamed.

If you implement this method, then the output plugins should divide up the different outputs by the groups and then by the devices. So rrdtool plugin should output rrd files in subdirectories like:

/PhysicalDisks/disk-sda/*.rrd

rpv-tomsk commented 8 years ago
So rrdtool plugin should output rrd files in subdirectories like: 
/PhysicalDisks/disk-sda/*.rrd

That is impossible. Submitted metric are named from:

The rrdtool plugin uses first two to build folder name and second two - for file name. There is no place for 'groups'.

Speeddymon commented 8 years ago

Fair enough. The rest of the request is still valid.