It should be due to the server not responding, but to be sure, can you run the same command with the --debug option?
Hi @t0bpr3
It should be due to the server not responding, but to be sure, can you run the same command with the --debug option?
When I run the command with --debug I get this output:/usr/lib/centreon/plugins/centreon_vmware_esx_wsman.pl --plugin=apps::vmware::wsman::plugin --mode=hardware --hostname='<IP>' --wsman-username='root' --wsman-password='<PASSWORD>' --wsman-scheme='https' --wsman-port='443' --component='.*' --verbose --debugUNKNOWN: Could not enumerate instances: Failure when receiving data from the peerThe interesting thing is that this is the only service for the host which is not responding.
Thank you so far.
Sorry my suggestion was not accurate, the option to add is --wsman-debug=debug
We have the following messages from different hosts:
UNKNOWN: Could not enumerate instances: Failure when receiving data from the peer
or
UNKNOWN: Could not enumerate instances: use debug option to have details
Hi
I have the same problem, getting the socind output: UNKNOWN: Could not enumerate instances: use debug option to have details.
When using the --wsman-debug=debug option, and comparing two identical servers (one fails, one ends ok), the only difference is:
For the bad one:
There are just two connections, and after the second one, a 500 code is gotten and check finishes with an UNKNOWN status:
< HTTP/1.1 100 Continue * We are completely uploaded and fine < HTTP/1.1 500 < Content-Type: application/soap+xml;charset=UTF-8 < Server: Microsoft-HTTPAPI/2.0 < Date: Tue, 07 Nov 2023 13:13:02 GMT < Content-Length: 2755 < Nov 7 14:13:01 03520575] write_handler: recieved 2755 bytes, all = 2755
* Closing connection 2 Nov 7 14:13:01 :3520575] curl error code: 0. Nov 7 14:13:01 33520575] cl->response_code: 500. Nov 7 14:13:01 13520575] cl->last_error code: 0. UNKNOWN: Could not enumerate instances: use debug option to have details
For the good one:
There are up to 4 blocks getting info:
< HTTP/1.1 100 Continue * We are completely uploaded and fine < HTTP/1.1 200 < Content-Type: application/soap+xml;charset=UTF-8 < WWW-Authenticate: Negotiate oYxxxxxxxxxxxxxxxxxxxxxxxxxxxxxCFf1YCwbuZuV7PCi2RZxcjibTR2JUznYhNF/vVsPRPnDtx/rjaOP+V1XsZGQm < Server: Microsoft-HTTPAPI/2.0 < Date: Tue, 07 Nov 2023 13:11:57 GMT < Content-Length: 1091 < Nov 7 14:11:57 43517374] write_handler: recieved 1091 bytes, all = 1091
* Closing connection 2 Nov 7 14:11:57 13517374] curl error code: 0. Nov 7 14:11:57 3517374] cl->response_code: 200. Nov 7 14:11:57 73517374] cl->last_error code: 0. Nov 7 14:11:57 3517374] *****set post buf len = 1009****** * Hostname MyHostName was found in DNS cache * Trying x.x.x.x... * TCP_NODELAY set * Connected to MyHostName (x.x.x.x) port 5986 (#3) * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/pki/tls/certs/ca-bundle.crt CApath: none * SSL re-using session ID * SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384 * ALPN, server did not agree to a protocol * Server certificate: * subject: CN=MyHostName * start date: May 8 07:36:15 2023 GMT * expire date: May 8 07:56:15 2024 GMT * issuer: CN=MyHostName * SSL certificate verify result: self signed certificate (18), continuing anyway. > POST /wsman HTTP/1.1 Host: MyHostName:5986 Accept: */* Content-Type: application/soap+xml;charset=UTF-8 User-Agent: WS-Management for all Content-Length: 1009
* upload completely sent off: 1009 out of 1009 bytes < HTTP/1.1 401 < Server: Microsoft-HTTPAPI/2.0 < WWW-Authenticate: Negotiate < WWW-Authenticate: Kerberos < Date: Tue, 07 Nov 2023 13:11:57 GMT < Connection: close < Content-Length: 0 < * Closing connection 3 * Issue another request to this URL: 'https://MyHostName:5986/wsman' * Hostname MyHostName was found in DNS cache * Trying x.x.x.x.... * TCP_NODELAY set * Connected to MyHostName (x.x.x.x) port 5986 (#4) * ALPN, offering http/1.1
…..
´´´´
and this block is repeated 4 times util a successful ending.
I have more cases. Sometimes, check fails from insede Centreon but it works from command-line. I imagine there is some problem with environment values, specially those related to TLS.
Any idea? It’s getting hard to use this plugin in all cases….
Thanks in advance.
Albert
Hi, a 500 error means an internal server error. I do not see how it could come from the plugin, particularly if it works well with one of your servers. This type of error generally leaves traces in the server logs. You should start the investigation there.
Hello
I use the vmware api, which work for vcenter and is a bit limited for a single ESX, so I don’t really use wsman on an ESX, and for hardware status I use the BMC card (ilo, idrax, ibmc, etc...)
however maybe I can help depending on your esxi configuration :
but maybe there is an issue on one of your host, that will cause the 500 error code. as Omercier said, it’s a server side error, 500 is something not working correctly on the host, not the consumer (poller here)
what is this run against, when you say multiple instance are working, What kind of host are you checking, Esxi? which version? are they all the same version or did they have a security fix recently?
WSMAN is linked to CIM and maybe SLP (not really clear where wsman is really but it’s behind CIM) and there have been security issue with these service.
A workaround was to stop some service to protect you, and the latest esxi I deployed recently didn’t have these services running by default a startup .
Is your “CIM Server” Service started on your ESXi, compare also the status of the slp service on the “good” ESX
Hello!
First of all, thanks to all of you for your time.
We don’t use WSMAN for ESXs, we’re using other Centreon plugins. Our problem is always on Windows targets. I’m sure the problem is on the target side, but we don’t know where to look for. Debug information is very generic and ambiguous, so it is difficult to guest where the problem is.
Sometimes you find some events in the Windows event log, but most of the times you get nothing. So it is complicated how to solve the problem. Some times events are related to TLS versions, some other tomes there is no event at all, or we are not able to relate any event to the problem.
In those cases we don’t know how to face the situation, and it is very frustrating.
if I understand what you are trying to do, you want to monitor windows machine with wsman, if i’m wrong please explain more.
if you want to monitor windows host with wsman you need to use another plugin, these one :
they come with templates and command specific for a windows host, out of the box they will connect to WinRM in http, and you need an admin account, but there are documentation on centreon that explain how to setup https, and how to create an window account with limited access for monitoring
Hello,
Oops, my fault :(
My confusion was caused by the error message. I have a very similar one using /usr/lib/centreon/plugins//centreon_windows_wsman.pl.
I followed all the documentation to configure it and it works fine in almost all cases. But when it fails, it is very difficult to get the root cause.
Anyway, I suppose I have to move my comments to another thread.
Sorry for the inconvenience and thanks.
Regards,
Albert
ah it makes more sense as why there was “server: microsoft...” in the debug :)
yes, I would suggest to open a new post as I don’t think you can change the original title
but the debug questions will be the same :
os version, patch version, and now we know it’s windows, : check everything that could be different (workgroup/domain, firewall mode, status of defender, etc.. only different things)
and include thing like winrm command that dumps the listener on both ok and non ok windows:
winrm e winrm/config/listener
and full command line for each of your --debug (hide password)
