banshee/virtualization-collection/virtualization/vsphere/https/vcenter-7.0u2/vcenter-health

Health of a VMware vCenter appliance, by its REST API

Returns the health level the vCenter appliance gives each of its components, the one its management interface (port 5480) shows, read from the vCenter REST API with an account. Two watches are offered, each one set on the probe.

Versions

Written for the REST API that vCenter serves under /api from vSphere 7.0 Update 2 (7.0, 8.0 and 9.0). The older API under /rest, the only one of vSphere 6.5 to 7.0 Update 1, is not served: those versions are out of VMware's general support. Hence the folder vcenter-7.0u2.

How it works

The collector logs in once (POST https://<host:address>/api/session, the account in Basic; the id of the session kept 50 minutes in the cache of the probe, encrypted on the poller, and asked again, once, when vCenter answers 401), then reads, the id in the header vmware-api-session-id, one GET https://<host:address>/api/appliance/health/<component> for each of eight components:

Component	What vCenter judges
`system`	the overall health of the appliance
`applmgmt`	its management services
`load`	the load of its processors
`mem`	its memory
`swap`	its swap
`storage`	its disks
`database-storage`	the space of its database
`software-packages`	its software updates

Each answers a JSON text, the health level: "green".

The health is vCenter's: green, yellow, orange, red, or gray when it does not know.
A code 401 or 403 at the login stops the collector misconfigured, a code 403 on a reading too; any other code but 200 stops it unreachable.

The password comes from protocol:http:password, a secret variable: it only goes in the Basic header of the login. The id of the session is a secret too: it only goes in the header and in the cache.

Prerequisites

The vCenter's address as the host's address, reachable from the poller in HTTPS (443), its certificate trusted by the TLS profile of the probe: the root certificate of the vCenter's own authority (VMCA, in https://<vcenter>/certs/download.zip) under protocol:tls:authorities, a pinned fingerprint in protocol:http:fingerprint, or the first fingerprint trusted in the tab "Security".
A vSphere account in protocol:http:user and protocol:http:password that may read the health of the appliance.

Outputs

Name	Label	Unit	Per instance
`health`	Health	—	yes, per component

Watches

Name	Title	Kind	Defaults	Checked by default
`degraded`	Component degraded	state to avoid, on `health`	warning on `yellow`, `gray`; critical on `orange`, `red`	yes
`missing`	Component missing	expected instances, on `health`	no component named: it raises nothing until names are set on the probe	no

Limits

software-packages turns yellow or worse when updates are waiting: leave it out of the selection (Components: All except software-packages) where updates are followed elsewhere.
Which least role may read the health of the appliance is not verified: the specification does not say it. Try first an account given the role Read-only on the vCenter root, as for the other collectors of this folder: a code 403 says it is not enough.
The values applmgmt answers are not listed by the specification, which gives a text only: they are taken to be the same five levels.
The address is written into the URL as is: an IPv6 address must be given as a name.
Not checked against a vCenter: the routes and levels are those of the published OpenAPI specification of the vCenter appliance API, 7.0.3 (as the Ansible collection vmware.vmware_rest carries it); whether every component is served as early as 7.0 U2 is not verified.