How You Can Use vSphere APIs to Collect vCenter and ESX Logs
If you manage a vSphere infrastructure, you may want to collect logs for troubleshooting, debugging, etc. You can get these logs from vSphere Client manually. You can also use vSphere API to collect them automatically.
The related managed object type in vSphere API is the DiagnosticManager. It helps to access logs from either a vCenter server or ESX server. It has no property but three methods:
1. queryDescriptions() provides a list of diagnostic files for a given system. It takes in an optional parameter host for specifying the HostSystem to extract information from. When you connect to the ESX server directly, the parameter isn’t needed. In vSphere Java API, you just pass in a null. When you connect to the vCenter server and the parameter isn’t specified, the method assumes you’re looking for vCenter logs. The return of this method is an array of DiagnosticManagerLogDescriptor data objects. The data object includes six properties: creator, fileName, format, info, key, and mimeType.
The creator property represents the component that creates the log; the value has to be one of the string values defined in the DiagnosticManagerLogCreator enumeration type. The filename is the full path to the log file on the ESX server, such as /var/log/vmware/hostd.log, or a simple filename on the VirtualCenter server, such as vpxd-0.log. The format has only one choice—plain—as defined in the DiagnosticManagerLogFormat enumeration type. The property key is used by other methods for browsing or downloading; it can have values like vpxd:vpxd-0.log on VirtualCenter, or hostd, messages, vmkernel, vmksummary, vmkwarning, or vpxa on the ESX server. The mimeType is Multipurpose Internet Mail Extensions (MIME). With the format as plain, the mimeType is limited to text/plain.
2. browseDiagnosticLog() allows you to “browse” a log file that is identified by the key as returned from the queryDescriptions() method. In addition to the key parameter, you can optionally specify two integers as the starting line and the number of lines in the log file you want to browse. If not specified, the starting line defaults to the top, and the number of lines defaults to the total from the starting to the end of the log. To browse the entire log, just leave the two optional parameters empty.
The return from the method is a DiagnosticManagerLogHeader data object, which has properties such as lineStart for the starting line and lineEnd for the ending line, as well as an array of strings as log entries in the log file.
3. generateLogBundles_Task() creates diagnostic bundles on the server side to be downloaded. A diagnostic bundle includes log files and other configurations, such as a virtual machine configuration that can be used to investigate potential server issues. The method has a boolean parameter, includeDefault, that specifies whether to include the default server, and optionally an array of HostSystems while connecting to a VirtualCenter server.
The return of the method, as its name suggests, is a Task. When it’s done successfully, the info.result property contains a list of DiagnosticManagerBundleInfo data object. The data object includes two properties: a system pointing to the HostSystem from which the diagnostic bundle is generated; and url, which represents the location where you can download the bundle. When you connect to the ESX server directly, url might have * as a placeholder for the real host name. Just replace it with the real host name or IP address before downloading it.
As the file extension suggests, the bundle is a compressed archive file. Use tools like 7-Zip to extract the files inside. Depending on your environment, the bundle could have thousands of files for you to do a thorough analysis of the system. It means the bundle could be huge, so please be cautious while using this method.
Well, I guess too many description. Why not a sample? Good idea. Please stay tuned for one.