Disabling VMware WMI Performance Logging - Does it affect LogicMonitor?
We have all of our VMs monitored with LogicMonitor which does a good job gathering details from our VMs. However, we have VMware tools installed on all VMs and leave WMI Performance Logging enabled. This VMware tools feature ends up generating a ton of events: 256 and 258 which reference vmGuestLibraryvmStatsProvider alerts. This is just standard behavior of VMware tools since it is pulling logging details in and creates these events. What I am trying to determine is if I can safely disable this WMI performance logging and allow LogicMonitor to still do the WMI calls, and if there is any impact. I am not sure if LogicMonitor relies on this WMI performance logging anyway since I believe it is gathering data directly from Windows and doesn't care that VMware tools is generating anything. Anyone have any insight on this?25Views0likes1CommentVMware Overview Dashboard
Hello, I'm new to LogicMonitor and we've just got our first vCenter server configured and monitored. I'm trying to figure out why theVMware Virtual Machine Status dashboard is saying "Instance limit exceeded (2000) (other than the obvious - that we exceeded the limit) and how to modify the dashboard to provide some meaningful data and visualizations that we can use. Has anyone else encountered this? And if so do you have a smaller query or dashboard panel that can help correct this? Thanks in advance.17Views0likes2Comments
VMware vSphere In-Guest Monitoring
VMware "In-Guest" DataSources - Version 1.0 - LogicMonitor Custom Development Summary: The following provides information and deployment instructions for the application of hypervisor-level monitoring data - as presented within a Windows virtual machine in LogicMonitor. There are three "InGuest" VMware DataSources - they are: VMware_vSphere_VMperformance_InGuest (locator code: CHLF7C ) VMware_vSphere_VMsnapshots_InGuest(locator code: 9YF42D) VMware_vSphere_VMstatus_InGuest(locator code: ZMEJ6P) How it Works: These datasources were cloned from the official LogicMonitor VMware DataSources with ‘_InGuest’ appended to the end of the standard name. They have been altered in the following fashion to apply them 'within' the virtual machine device: A critical feature built into the DataSources is the ability to ‘override’ a vCenter location with ‘esx.url.’ ○ This allows us to apply the DataSource to a VM and point it to vCenter for data. The AppliesTo language is updated to apply the DataSources to Windows Virtual Machines: ○ system.model =~ "Vmware Virtual Platform" && esx.url && esx.user && esx.pass The host property variable is switched from system.hostname to system.sysname: ○ def host = hostProps.get("system.sysname") The Active Discovery of virtual machines is limited to the device hostname to which it is applied: ○ ManagedEntity[] vms = new InventoryNavigator(rootFolder).searchManagedEntity("VirtualMachine","${host}"); Implementation: Three properties are required to be applied to the virtual machine device(s) in LogicMonitor: esx.user esx.pass esx.url in format: https://<vcenteripaddress>/sdk Once the device properties are present, the AppliesTo language will kick in and the DataSources will apply. Suggestion: create a dynamic group of Windows virtual machines, and set the ‘ESX’ properties at that group level. Notes: These DataSources are custom development and officially unsupported by LogicMonitor. Restrict the application of property esx.url to ONLY the virtual machines needed. This property will apply to ESXi hosts if allowed, which impacts vCenter collection and performance. Deploy this in stages - we will be increasing the load on vCenter due to the additional API queries. We do not currently identify Linux VM’s out of the box, for now this is Windows-only. Automated detection of VM to vCenter relationship is difficult at the device level, hence the need for esx.url. vCenter is the preferred integration point for esx.url, but an ESXi host should also work (until the VM moves.)13Views0likes0CommentsFYI: LM can trigger ESXi 6.5 hostd to crash
Hi, I just got done working with VMware support on an issue where our ESXi 6.5 hostd process would crash during a booting phase. We eventually traced it back to a bug in some vSAN code that LM monitoring is polling.. It doesn't matter if you're running vSAN in your environment or not. Our work around has been to disable host level monitoring in LM for ourESXi hosts for now and it's been stable ever since. The expected fix is scheduled for release in Q3 2018 from VMware.11Views2likes12CommentsVMware vCenter monitor VM disk space alerts
Previous versions of VMware datasources had the ability to monitor disk space for VMs via vCenter. Looks like this ability has disappeared after LM fixed a datasource bug in January. We now have 100+ VMs that we monitor via vCenter but no alerts for their disk space. Is this something we are missing by accident, or has LM stripped this functionality on purpose?11Views0likes2CommentsGroup VM instances in VMware by VDC/Resource Pool
I would love to see the "ESX VM" datasource allow grouping its instances by the VDC/Resource Pool in which each VM is contained. Use case: Each VDC in our infrastructure may have different alerting rules. We have many VDCs and most of these VDCs are available directly to customers through vcloud director, allowing them to create their own VMs using names over which we have no control (so we can't use the automated name filters to group them). Customers may add a new VM at any time within their own VDC and they have the option to expand out at will without notifying us. Currently, grouping VMs by their VDC in LogicMonitor is a manual process which gets outdated everytime a new VM is created - which is at least daily. As a workaround, if the LogicMonitor APIs allowed a way to create instance groups and add instances to those groups, we could script this out and just add new VMs into the appropriate groups as the scripts detect that they have been added into the environment, however, it appears that this functionality doesn't exist in the API either.8Views0likes11CommentsVMware_Status Datasource update
We were running into an issue where disks were not consolidating properly following our backup completing, we are using Veeam with VMware. Since this wasn't included our of the box I have updated the default datasource to include a consolidationNeeded graph and datapoint. consolidationNeeded - Whether any disk of the virtual machine requires consolidation. This can happen for example when a snapshot is deleted but its associated disk is not committed back to the base disk.(https://code.vmware.com/apis/358#/doc/vim.vm.RuntimeInfo.html) This can cause a problem with performance as it will require more IO and for database servers this can be damaging for high io solutions. Since I am not able to attach XML files, I have copied the exported code below. If you want to do this manually, you will need to modify theactive discovery script to the collector attributes script and then add the data point and graph. In the active discovery script make the following changes: In the props_hash def include a line for "'auto.runtime.consolidationNeeded' : vm?.runtime?.consolidationNeeded" make sure you include a comma to separate the values. def props_hash = ['auto.config.alternate_guest_os_Name': vm?.config?.alternateGuestName, 'auto.config.annotation' : vm?.config?.annotation, 'auto.config.firmware' : vm?.config?.firmware, 'auto.config.guest_os_full_Name' : vm?.config?.guestFullName, 'auto.config.guest_os_id' : vm?.config?.guestId, 'auto.config.managed_by' : vm?.config?.managedBy?.type ?: "false", 'auto.config.modified' : vm?.config?.modified?.getTime(), 'auto.config.template' : vm?.config?.template, 'auto.guest.guest_os_family' : vm?.guest?.guestFamily, 'auto.guest.guest_os_full_name' : vm?.guest?.guestFullName, 'auto.guest.guest_os_id' : vm?.guest?.guestId, 'auto.guest.hostname' : vm?.guest?.hostName, 'auto.guest.tools_version' : vm?.guest?.toolsVersion, 'auto.guest.tools_version_status' : vm?.guest?.toolsVersionStatus2, 'auto.hardware.memory_mb' : vm?.config?.hardware?.memoryMB ?: 0, 'auto.hardware.num_cpu' : vm?.config?.hardware?.numCPU ?: 0, 'auto.hardware.num_cores_per_socket' : vm?.config?.hardware?.numCoresPerSocket ?: 0, 'auto.hardware.num_virtual_disks' : vm?.summary?.config?.numVirtualDisks ?: 0, 'auto.hardware.num_ethernet_cards' : vm?.summary?.config?.numEthernetCards ?: 0, 'auto.resource_pool' : vm?.resourcePool?.name, 'auto.resource_pool_full_path' : resource_pool_array.reverse().join(' -> '), 'auto.snapshot_count' : vm?.layoutEx?.snapshot?.size() ?: 0, 'auto.cluster' : esxhost?.parent?.name, 'auto.cluster_full_path' : cluster_path_array.reverse().join(' -> '), 'auto.runtime.host' : esxhost?.name, 'auto.runtime.connection_state' : vm?.runtime?.connectionState, 'auto.runtime.power_state' : vm?.runtime?.powerState, 'auto.runtime.consolidationNeeded' : vm?.runtime?.consolidationNeeded] Test the script against a vcenter server to make sure you are getting a true or false response from a server. In thecollector attributes script make the following changes Create a consolidation_states def, this will allow us to translate the value of the boolean to a 0 or 1 def consolidation_states = [ 'false' : 0, 'true' : 1 ] In the Iteration of VMs section, add a line for the def consolidation_Needed value, this is where we are actually translating the value to 0 or 1 with a toString compare. // iterate over vms vms.each { vm -> // Get AD info def wildvalue = vm.MOR.val def power_state = power_states[vm?.runtime?.powerState?.val] def consolidation_Needed = consolidation_states[vm?.runtime?.consolidationNeeded?.toString()] Finally, at the end, create a println to make the value go to standard out // Print that data println wildvalue + ".PowerState=" + power_state println wildvalue + ".ConsolidationNeeded=" + consolidation_Needed Test the script against a vcenter server to make sure you are getting a 0 or 1 response from a server if you are getting a null something is misconfigured. Once you get that working it is just a simple matter of adding a datapoint and graph Datapoint graph6Views2likes1CommentVMware vSphere log monitoring
The Windows EventSources monitoring has been very useful for us, and we were hoping to be able to replicate the same with vSphere's logging (vCenter, vpxd, etc). Right now our only alternative is leveraging VMware's "Log Insight" tool, but we were hoping to have this integrated into LogicMonitor so we're not duplicating monitoring across separate monitoring tools.6Views0likes0Comments
