Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
The vCenter Server Appliance (VCSA) is a preconfigured Linux virtual machine, which is optimized for running VMware vCenter Server and the associated services on Linux. Using LogicMonitor’s VMware VCSA package, you can monitor CPU usage, file system capacity, disk performance, memory, and much more.
A majority of the DataSources included in the VCSA API package are compatible with vCenter Server Appliance (VCSA) version 6.5 or greater. However, there are several DataSources that require the appliance be at least version 6.7 before they can be executed. It is recommended that you use the latest version of either VCSA build (6.5 or 6.7) as VMware has identified and corrected several bugs with the API that existed in earlier iterations. Visit VMware’s Knowledge Base for additional information regarding current and past versions of VCSA.
The vCenter Server build version for the VCSA can be determined using one of the following methods:
Note: VCSA version information (including release dates and build numbers) can be identified in the Build numbers and versions of VMware vCenter Server article found in the VMware Knowledge Base.
In order for LogicMonitor’s VCSA API DataSources to query data, LogicMonitor must provide the appropriate credentials when establishing a connection with the API. As outlined in the following sections, these credentials must belong to a user included in the “SystemConfiguration.Administrators” group. Additionally, these credentials must be set as properties on the VCSA device in LogicMonitor.
Once the new VCSA user account is created, it must be added to the “SystemConfiguration.Administrators” group. Even if the new VCSA user account is assigned administrative access, it will not be authorized to pull API information without the privileges provided by this particular group.
The username, including the SSO domain (i.e. [email protected]), and the password must be established in the vcsa.user and vcsa.pass custom property fields for the VCSA device in LogicMonitor. This allows the Groovy scripts to provide the appropriate credentials when establishing a connection with the API.
Note: If the vcsa.user and vcsa.pass properties are not set, the LogicModules in this package will use the esx.user and esx.pass properties if available. However, if it is your intention to use ESX and VCSA credentials for resources in the same device group, you’ll want to set the VCSA credentials specifically so that they can take precedence where appropriate, as they do differ.
For more information on setting properties for devices, see Resource and Instance Properties.
Each VCSA DataSource is written to handle certain exception errors that might occur during execution. The script will output the error that occurred to the “scriptOutput” row for each DataSource (viewed from the Resources page under Raw Data| Poll Now). If you are seeing “No Data” or unexpected results, start by checking the returned values listed here.
Some of the common errors that have been identified are related to user access and permissions. If you receive an HTTP response status of 401 (UNAUTHORIZED), it is an indication that the user does not have access to the API. Start by checking whether the user exists in the VCSA vSphere Web Client Users & Groups Section. Also confirm that you have input the correct credentials for the device’s vcsa.user and vcsa.pass properties.
If you receive an HTTP response of 403 (FORBIDDEN), it is generally an indication that the user exists and has access to the API, but is attempting to query endpoints that are restricted. This is likely because the user is not associated with the “SystemConfiguration.Administrators” group which is required to query monitoring data from the API.
Outside of access issues, sometimes you may receive error messages similar to ERROR: Data from ‘<DEVICE>’ is not a valid format and cannot be processed followed by the data that the server returned. Generally, this occurs when collecting data such as disk latency when disks are inactive (i.e. zero read/write activity) or backup/backup instance information when backups are not scheduled and have never occurred. Check the VCSA to ensure that these activities are taking place (i.e. disks are processing data and backups are enabled/occurring).
In This Article