check nrpe/check nt communication issues
Re: check nrpe/check nt communication issues
An intermittent issue. Could be the Nagios side, could be the remote server side. Could be a device somewhere in between. It's hard to tell.
As of May 25th, 2018, all communications with Nagios Enterprises and its employees are covered under our new Privacy Policy.
Be sure to check out our Knowledgebase for helpful articles and solutions!
Be sure to check out our Knowledgebase for helpful articles and solutions!
-
- Posts: 222
- Joined: Thu Jul 06, 2017 8:55 am
Re: check nrpe/check nt communication issues
Does agent nsclient.log will have capacity to read what exact error. ?? Could you please suggest this.
I don't think it's issue from nagios server because in a minute it's polling to nearly 600 checks.
I don't think it's issue from nagios server because in a minute it's polling to nearly 600 checks.
Re: check nrpe/check nt communication issues
You can enable debugging in the nsclient.ini file:
and restart the NSClient++ service, so that changes can take effect. Then, you can post the nsclient.log and nsclient.ini file on the forum. Hopefully, we will find some clues in there. The assumption is that this is a configuration issue. If this is an intermittent networking issue, it would be a lot more difficult to troubleshoot it.
Code: Select all
level = debug
Be sure to check out our Knowledgebase for helpful articles and solutions!
-
- Posts: 222
- Joined: Thu Jul 06, 2017 8:55 am
Re: check nrpe/check nt communication issues
Observed this CHECK_NRPE: Receive header underflow - only 0 bytes received (4 expected) happening in night hours only.
Re: check nrpe/check nt communication issues
The general scenario is this:
Things work great during the day, things don't work great during the night
Backups and other high resource intensive tasks (such as vulnerability scanning) are scheduled at night, that's usually what it is.
vMotions/VMWare backups, etc, something is impacting the network or the remote systems.
My assumption is they are backups/other resource intensive tasks. Please investigate those systems directly for load and other issues and find out when backups occur. Then you could use the scheduled downtime or recurring downtime to preemptively predict it to suppress them or adjust your timeouts to be longer and see if that fixes it.
Things work great during the day, things don't work great during the night
Backups and other high resource intensive tasks (such as vulnerability scanning) are scheduled at night, that's usually what it is.
vMotions/VMWare backups, etc, something is impacting the network or the remote systems.
My assumption is they are backups/other resource intensive tasks. Please investigate those systems directly for load and other issues and find out when backups occur. Then you could use the scheduled downtime or recurring downtime to preemptively predict it to suppress them or adjust your timeouts to be longer and see if that fixes it.