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 vmGuestLibrary vmStatsProvider 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?67Views0likes1Comment
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.)35Views0likes0CommentsFYI: 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 our ESXi hosts for now and it's been stable ever since. The expected fix is scheduled for release in Q3 2018 from VMware.32Views2likes12CommentsVMware 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 the VMware 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.22Views0likes2CommentsLM Exchange module request
Is there a an LM Exhange module similar to/ or a variation of the one below which can alert for VMs if they go offline as long as their properties are tagged with a certain keyword? We have had instances where running VMs go offline but LM does not alert, because of this particular filter. Lookign for a simple module to only alert if VM is down based ona vm tag we can set.19Views0likes2CommentsVMware 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?18Views0likes2CommentsGroup 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.14Views0likes11Comments
How support troubleshoots ESX connections.
These are some simple troubleshooting steps I use when dealing with ESX servers. LogicMonitor has debug tools that can be run in the debug window on the collector the ESX currently assigned collector. The first useful tool is !http. This simply sends a HTTP request to a host and print the response. The ESX API has a few pages we can use that DOES NOT require authentication. This is helpful to test a connection outside of credential issues. For example the below debug command returns “The Web Services Description Language (WSDL) file containing definition of the VMware Infrastructure Management API.” !http https://10.73.42.10/sdk/vim.wsdl What data is returned isn't important, what this command will tell us is can the collector connect to the ESX device or is network infrastructure somehow stopping communication. The next command is !esx and it's a bit more powerful help !esx !esx: query a list of esx performance counter against the given host and print the result usage: !esx [username=foo password=bar] <host> <entityName> <entityType[host|vm|datastore|cluster|resourcepool|hoststatus|cpu|memory|disk|network]> [counter1 [counter2...]] If you don't give the username/password, the agent will use esx.user/esx.pass properties of the host. !esx is a debug tool that allows us to query the VMware API directly in the same way the datasources poll data. To decode the help example let’s run this on the ESX server 10.73.42.10 and the virtual machine “marvin”. The example !esx command is "!esx vc-server esx-name host cpu.usage.average mem.consumed.average" Broken down for the test environment "!esx 10.73.42.10 marvin vm cpu.usage.average mem.consumed.average" If you don't give the username/password, the agent will use the esx.user/esx.pass properties of the host. This is a fantastic way to test the credentials entered into LogicMonitor. You could also push the credentials by using the username= and password= options with the !esx command to verify they work with LogicMonitor. So far we have only tested connectivity which is the most common form of ESX troubleshooting. We can also use the !esx to query individual datapoints in the datasources to ensure the data presented by LogicMonitor is accurate. The command can be built by viewing the datapoint in question. For this example we can use the Cpu Usage counter used in previous examples. Lets take another look at the !esx usage usage: !esx [username=foo password=bar] <host> <entityName> <entityType[host|vm|datastore|cluster|resourcepool|hoststatus|cpu|memory|disk|network]> [counter1 [counter2...]] We know the host is the ESX server 10.73.42.17, Entity Name is the Virtual Machine Marvin, EntityType can be found in the datapoint which is "VM" and the ESX counter is cpu.usage.average. !esx 10.73.42.10 marvin vm cpu.usage.average cpu.usage.average which will return the value cpu.usage.average=211.013Views0likes0Comments
