search

BaldMansMojo / check_vmware_esx

chech_vmware_esx Fork of check_vmware_api.pl
GNU General Public License v2.0
124 stars 67 forks source link

SOAP request error - possibly a protocol issue: 500 read timeout one 1 of 4 hosts #88

Closed bill22152 closed 5 years ago

bill22152 commented 8 years ago

./check_vmware_esx.pl -H 172.16.1.11 -S cpu -s usage failes

./check_vmware_esx.pl -t100 -H 172.16.1.12-14 -S cpu -s usage works

Is there something that should be enabled on host #1?

bill22152 commented 8 years ago

[root@Nagios bfitzpatrick@lssi.hqmd]# cpan -D Net::HTTP Loading internal null logger. Install Log::Log4perl for logging messages CPAN: Storable loaded ok (v2.53) Reading '/root/.local/share/.cpan/Metadata' Database was generated on Tue, 05 Apr 2016 20:53:38 GMT

Net::HTTP

    CPAN: Module::CoreList loaded ok (v5.20160121)

(no description) E/ET/ETHER/Net-HTTP-6.09.tar.gz /usr/share/perl5/vendor_perl/Net/HTTP.pm Installed: 6.09 CPAN: 6.09 up to date Karen Etheridge (ETHER) ether@cpan.org

BaldMansMojo commented 8 years ago

Hi, this seems to be a connection problem ;-)) . The command line tools from Vmware are enclosed with the SDK. First test the connection with the CLI. If this will work the plugin should work (normally). Maybe you haven't set up the local monitor user on that host?

Which ESX versions do you run?

Regards - Martin

bill22152 commented 8 years ago

The 'esxcli' command works fine on all four hosts. I did notice that once I migrated guests off the host the issue moved to another host.

Is it possible it's a load issue or thread count limit? My typical ram utilization is 40% and the CPU is typically half of that. On Apr 6, 2016 5:35 AM, "Martin Fuerstenau" notifications@github.com wrote:

Hi, this seems to be a connection problem ;-)) . The command line tools from Vmware are enclosed with the SDK. First test the connection with the CLI. If this will work the plugin should work (normally). Maybe you haven't set up the local monitor user on that host?

Which ESX versions do you run?

Regards - Martin

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/BaldMansMojo/check_vmware_esx/issues/88#issuecomment-206259498

BaldMansMojo commented 8 years ago

I never heard of such a problem. Can you measure the time for connecting with esxcli for a host the plugin is not working?

bill22152 commented 8 years ago

The connection with esxcli is instantaneous or nearly.

On Apr 6, 2016, at 10:40 AM, Martin Fuerstenau notifications@github.com wrote:

I never heard of such a problem. Can you measure the time for connecting with esxcli for a host the plugin is not working?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub

BaldMansMojo commented 8 years ago

As asked earlier: which VSphere version?

bill22152 commented 8 years ago

Esx 5.5 u2 Vsphere 6 On Apr 8, 2016 10:34 AM, "Martin Fuerstenau" notifications@github.com wrote:

As asked earlier: which VSphere version?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/BaldMansMojo/check_vmware_esx/issues/88#issuecomment-207454390

BaldMansMojo commented 8 years ago

Am I right - you're running a mix of version 5.5 and 6? have you tested it without session file (--nosession)? Do you use an authfile or submit the user and password? Does the problem only happens with the check above or with all others? To seperate a login problem from a check timeout insert in check_vmware_esx.pl in line 1797 (after the login part before the trace part) a print "Here we are\n"; So if you test from the command line you will see the message. If this happens fast the problem is not based on login. It's based on server response. If you use the plugin in production us a copy of check_vmware_esx.pl for the test.

Regards - martin

bill22152 commented 8 years ago

I've had mixed results with session files And I use username password

Let me test with no session and your 'I'm here' version.

Bill On Apr 11, 2016 4:50 AM, "Martin Fuerstenau" notifications@github.com wrote:

Am I right - you're running a mix of version 5.5 and 6? have you tested it without session file (--nosession)? Do you use an authfile or submit the user and password? Does the problem only happens with the check above or with all others? To seperate a login problem from a check timeout insert in check_vmware_esx.pl in line 1797 (after the login part before the trace part) a print "Here we are\n"; So if you test from the command line you will see the message. If this happens fast the problem is not based on login. It's based on server response. If you use the plugin in production us a copy of check_vmware_esx.pl for the test.

Regards - martin

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/BaldMansMojo/check_vmware_esx/issues/88#issuecomment-208235427

BaldMansMojo commented 8 years ago

Session files - these are important. Otherwise you will have a lot of login/logout in your Logfiles. In case of problems with sessionfiles it's mostly an incorrect setup. But for testing it can be wise to disable as much as possible.

Martin

ramkomatlapalli commented 5 years ago

Is the issue resolved, if so share me the same. Even i am having the same issue.

Error that I got

CoCHECK_VMWARE_API.PL CRITICALSOAP request error - possibly a protocol issue: 500 read timeout

I use esxi 6.7 and managed by vcenter 6.7

BaldMansMojo commented 5 years ago

Unfortunately I can't reproduce it. Use latest version from Plugin. It contains a lot of changes and improvements.