-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent disk plugin behavior using autofs with different types of maps #3430
Comments
I think with NIS it probably could not find the mounts at all. I agree that it would be good to not trigger autofs filesystems if possible. Can you add the contents of |
Here are snippets key portion of /proc/self/mounts with one filesystem ( /xxx/it/foo4 ) automounted. The notable difference is that in the NIS case /proc/self/mounts does not list the mountpoints for unmounted filesystems. Plain text map:
NIS map:
No difference in the /proc/filesystems:
|
Since the actual NFS mount is also listed when mounted, I guess we should just always skip autofs filesystems. I can't think of any reason one would want to include them. |
I'm going to put the fix in 1.5 since there is an available workaround. |
So I actually spun up telegraf to monitor some autofs mounts. Is there a way to re-enable this? |
No, but if you did Telegraf would always keep the filesystem mounted. I suspect you would rather have Telegraf not mount the filesystems but report on them only if they are mounted? |
Actually in this case we expect the filesystem to be always mounted. Corporate infrastructure just has it first mount via AutoFS. We use the mounts so often they are always alive. I might be able to manually mount everything via NFS (no AutoFS involved). I expect this will only temporarily work as this is a data center and the machines exporting a drive sometimes change (why we use AutoFS). I will probably explore the PR and manually undo it for my needs. I might make a PR for adding an option to allow monitoring AutoFS. To answer your question directly: Yes I would rather have telegraf only report on them if they are mount. Currently it doesn't report on them at all. |
@danielnelson Can you confirm for me the default behaviour in Telegraf regarding this issue? I have an NFS share which is configured with In the "Bug fixes" for V1.5 here, I see "Always ignore autofs filesystems in disk input." Is this relevant for what I am asking, or is this simply about ignoring already-mounted drive which have the tag "aufs" ? Please advise. Thanks |
Directions
Bug report
We moved from using NIS mapping autofs NFS mounts to using ones defined in regular text files. All of the sudden all of our servers started mounting all the filesystems defined in the autofs files. We tracked this down to Telegraf which started triggering all of our autofs mounts after the aforementioned change.
I found an (undocumented) ignore_fs parameter which can be used to fix this:
What made this challenging to debug was that we had been running with the old Telegraf config for ages with Telegraf happily ignoring the NIS mapped autofs filesystems. Thus it was not the most obvious suspect.
This solves the immediate issue, but the underlying bug (inconsistent autofs behavior based on map) should be addressed and documentation improved.
System info:
Telegraf v1.4.1 9cf19df
RHEL 7.3
Steps to reproduce:
Expected behavior:
Telegraf should either consistently mount or not mount the autofs mounts regardless of how the mounts are mapped (NIS, LDAP, file etc.)
It should clearly stated that autofs mounts may be triggered by the disk plugin unless they are ignored with the ignore_fs option (which itself should be documented!).
I feel that unmounted autofs filesystems should not be touched by the collector at all unless explicitly defined to do so. However I understand that changing this might cause issues for other users.
Actual behavior:
Telegraf disk plugin ignores autofs mounts when they are mapped via NIS but then triggers them when they are mapped in a regular file.
Additional info:
The text was updated successfully, but these errors were encountered: