-
Notifications
You must be signed in to change notification settings - Fork 63
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
Submitting Passive Checks by IP #363
Comments
This ain't be a hacky approach but this decision is up to you^^ Your SNMPTT is probably execution a script (or whatever) to pass the traps as passive checks to Naemon. Naemon (and Nagios as well) has a file called You can then add a lookup method to the script that gets executed by SNMPTT to find the right ip address. |
I thing all these info about Naemon objects are retirevable via livestatus with its own query language. Parsing cache would work until somebody decides to change file format. |
Sorry for the late response ... but mixing in some livestatus magic here sounds like a really good idea. I haven't tinkered with livestatus before, but I'm well aware of what it is. Once I get something working I can share it here, in case someone else encounters this issue. |
This is really kinda ugly and could use a lot of error checking and improvement ... but in case it helps anyone, just a real quick hack to the generic submit_check_result:
I copied it to submit_trap_check_result so the generic one stays intact for other purposes. submit_check_result itself is pretty darn simple, so 🤷 ;) |
you could append a |
Fantastic idea, thanks!
|
(I originally posted this issue to naemon-users)
I am currently working on migrating a system from Nagios Core 3.4.1 + Merlin to Naemon Core 1.2.4 + Merlin. We use the system to handle SNMP traps, and this is done through SNMPTT (version 1.4), and hence we submit the results as passive check results.
Some of our devices that send traps live behind a Linux machine masquerading traffic over an OpenVPN link. When these traps traverse the masquerading host / VPN link snmptrapd interprets the message slightly differently than if it traversed the network normally.
Here's a trap that traverses over the NAT/VPN path:
And here is one that doesn't traverse the NAT/VPN path:
The key difference is here:
versus:
For reasons which still remain a mystery to me the packets which are NAT'd are identified differently by snmptrapd than those which are not. When those hit SNMPTT, the Y.Y.Y.Y address was being used (the "host name") instead of the actual address of the device "X.X.X.X". We switched to using the "$aA" variable in SNMPTT which is the "Trap agent IP address" instead of the default "$ar" which is simply "IP address".
We would then submit a passive check result with the actual "trap agent IP address" which would map back to the correct device in our Nagios config. Now it appears that Naemon will not accept IP addresses in a passive check submission, rather only a valid host_name. Trying to submit using an IP address yields:
And understandably so - IP addresses aren't required to be unique in either a Nagios or Naemon config but host_name variables certainly are. So a conflict could occur when trying to submit a passive check result to an IP address which is defined more than once. Would the first match get the check result? Would both? Would neither get the result and an error be generated? Certainly if such functionality would be implemented I think there'd be a specific configuration directive in naemon.cfg to enable "Passive Checks by IP", with a warning that if conflicts occur a certain behavior would exist to handle those.
To further complicate my own issues, none of our devices are in DNS - and can't be. And, we cannot enable DNS lookups in SNMPTT either, for performance and reliability reasons. After I did populate all of our devices into a local /etc/hosts file, and switched SNMPTT to use the "$A" variable (the trap agent host name) the passive checks started working - but not for any of the traps traversing the NAT/OpenVPN link. Those remained as IP addresses, despite having entries in the /etc/hosts file. So, there is potentially an SNMPTT bug mixed in there. And, overall I'd prefer not to manage a static /etc/hosts file, either.
Sorry for the long-drawn out explanation of this issue. I hope it's helpful to frame my position on the matter.
The text was updated successfully, but these errors were encountered: