initial commit of ZFSonLinux plugin

[richardelling]

initial commit of ZFSonLinux collector compatible with versions up to v0.7.5

re-order makefile's install-modules because npm install can remove NAD_LIB

[maier]

Is the npm/makefile change due to the npm v5 issues w/re to removing other dependencies when npm install is run?

The script errors if zfs is not in use. The plugin should be removed from the default plugin list or fixed to be benign when zfs is not in use. Since zfs is not the default fs, it may not be wise to include it as a default plugin at this point since it will result in a fork for every collection interval.

cosi-u16-f9d8aa554:~$ ./zfs.sh
./zfs.sh: line 52: /proc/spl/kstat/zfs/*/io: No such file or directory

[richardelling]

Hi @maier thanks for taking a look, I have limited test environments here and have only tested npm v8. There I see that npm removes the nad module. If there is a better solution, by all means let's do it.

wrt to the error be sure to get the latest commit f8f2675

[richardelling]

wrt optional use, the zfs module can be loaded late. So it isn't clear to me the best approach to setting it as optional. We should treat it the same as zpool.sh and I followed that lead.

That said, we should also bail quickly if PROC_DIR does not exist. I'll add that logic.

[maier]

Ah, ok, yeah, I had the script from a previous commit. It doesn't error now. Yeah, I'm good with reshuffling the npm install. I had it that way to intentionally catch issues such as adding a dependency that would result in nad specific modules being overwritten. The install would be broken in either case but I wanted it to fail fast and hard.

I'm still thinking about whether to have it be a default plugin at this point since zfs currently isn't a default filesystem.

[maier]

Let's move it to an optional plugin. ZFS is the default filesystem for OmniOS/Illumos which is why zpool is enabled by default for those OSes.

[richardelling]

ok, so we agree we should treat both zpool.sh and zfs.sh as optional for linux?

[maier]

Our best bet will be to create a test (like the zpool one) which reflects ZFS installed and active - that works on both RHEL and debian based systems. If Ubuntu is now including ZFS support by default (but not using ZFS as the default fs) then the zpool test is not really viable any longer either.

For now, just put the creation of the link in the same block as the zpool one. That will get us part of the way there on systems that requiring installing additional package(s) to utilize zfs.

I'll reorganize when I promote the plugins to a separate repository in order to work with both NAD and the Circonus Agent simultaneously. Maybe switching to detecting if ZFS is in use in the package (rpm/deb) at the time of install. (e.g. possibly something like using the exit code from df -t zfs to determine if there are any active zfs mounts, though I haven't checked to see if that would be reliable across distros.)

[richardelling]

Actually, looking for /sbin/zpool doesn't work perfectly in Linux-land because, for example, Ubuntu ships the zpool command in an optional package: zfsutils-linux. Though it is possible to use zfs without the zpool command, we can consider it to be rare enough to not worry about it.

[maier]

Since the plugin relies on /proc/spl/kstat/zfs check for the existence of that directory. If it exists, create the symlink.

[richardelling]

/proc/spl is sufficient as the spl driver is required for zfs and there is no other use for spl.
Another alternative is searching for the zfs kernel module modprobe zfs returns 0 if the named module is found in the kernel's module search path.

[richardelling]

egads, too many years in Solaris, that should be modinfo zfs :-)