In my previous article I looked at the “Service Discovery” functionality within vRealize Operations 8.0. In this article I am going to build on that by showing you what the “Application Monitoring” functionality can offer which is provided by the “VMware vRealize Application Management Pack”. Note that I am not going to cover the pros and cons of “EPOps vs Application Monitoring” in this article as EPOps will soon be EoL (next 8.x release).
Well, essentially it is the replacement for EPOps (Endpoint Operations). This was a vROps management pack that used in-guest agents to collect application level data and metrics to allow vROps administrators to perform analysis, monitoring and alerting for applications installed inside virtual workloads within the vROps inventory.
In vROps 7.5 we added VMware vRealize Application Management Pack which provides application monitoring functionality as an alternative to using EPOps (and in 8.0 both do still function alongside each other) with the view to making EPOps EoL sometime in the future.
Application Monitoring also requires the deployment of in-guest agents to provide vROps the data it needs for analytics however the difference here is the agents deployed are based on opensource telegraf agents (see https://www.influxdata.com/dm-telegraf/) which are deployed, configured and collected on from dedicated collector appliances.
Unlike Service Discovery, Application Monitoring needs additional components in order to function, namely agents and collectors. Lets take the following as an example.
In my example I have a central vROps cluster made up of one or more nodes (the quantity here is not really important).
In Site 1 I have 2 vCenter appliances, each managing their own set of clusters and VMs. vCenter 1 has no requirement for application level monitoring of its virtual machines where as vCenter 2 contains some VMs that do require it. In Site 2 I have a single vCenter appliance which also has some virtual machines that need application level monitoring.
In all cases I am using one or more remote collectors for performing the standard vCenter level data collection. In each site I have also placed an ARC (“Application Remote Collector”) appliance. These appliances deploy the telegraf agents to selected VMs and collects data from them to pass onto the vROps cluster for processing.
In Site 1 the ARC is linked to only the vCenter (vCenter 2) which contains virtual machines I want to perform application level monitoring on. It could also be linked to vCenter 1 in the future if there was a requirement to do so. Site 2’s ARC is linked to vCenter 3.
As with any remote collector, there is a finite number of objects the ARC can collect on and you should therefore deploy a sufficient number of collectors to handle your environment accordingly. Check the sizing KB (https://kb.vmware.com/s/article/2093783) for more details.
ARC’s are added in a slightly different way to standard remote collectors. Once the OVA is downloaded and deployed with a basic configuration (i.e. hostname, IP address etc.) to the desired location the appliance is added to vROps from “Administration > Configuration > Application Remote Collector”.
At this point the ARC can be mapped to one or more vCenter appliances and will therefore be the ARC responsible for performing the application level data collection for any VMs required in the associated vCenters inventory.
As I stated previously, application monitoring using this method requires the deployment of in-guest agents. vROps manages the lifecycle of the telegraf agents from the “inventory” section on the “Administration” page which you can get to from the home page as shown below.
The agent configuration is handled on a separate tab to the “Service Discovery” configuration however the process is mostly the same to enable the agents. The idea is too highlight one or more VMs that you want to deploy an agent on, select deploy and then provide some configuration information. In this example I am configuring a machine called “iaas1”.
I now have the option to provide authentication credentials to the selected machines based on whether I have common account or whether I need a specific account for each machine. If you have a separate account for each then the wizard will offer you the option of downloading a template to populate for the account mappings. I have a windows service account for my single VM so I’m using the first option.
If your VM (or VMs) is/are Linux based the installer will by default create a run-time user for the agent services on each machine.
The agent installation process now starts for my “iaas1” VM. Any installation errors that you encounter will be flagged up here in the “Last Operation Status” column.
After a data collection cycle the agent should show any supported applications that have been discovered by the telegraf agent. Discovered however does not mean configured! Here MS IIS has been discovered on “iaas1” but I still need to do some additional work.
The application discovered (or applications if more than one) can be selected one by one from the drop-down list as shown.
This gives you the ability to provide any information required including turning on/off data collection. In this example for IIS I only need to provide the agent instance a name however for applications such as MS SQL you need to provide additional information such as SQL instance names, ports etc.
Once everything has been configured and another data collection cycle has run the configured application should turn green. If this is not the case then there is likely an error in the configuration data (i.e. wrong password, port, instance etc.). Remember, case sensitivity can also come into play here.
Discovered and configured applications are shown on the home screen “Monitor Applications” section. The hyperlinks can be used to get to the various agents and will automatically filter the agent list accordingly.
As we saw in the “Service Discovery” article, application/service data is not shown when you browse to a vCenter inventory object (i.e. a VM). You only see the native vCenter related objects.
Switching the view (either double clicking on the VM or using the switch icon) flips the focus into the “related objects” view.
Using the “All Objects” filter opens up the view to show everything, not just the vCenter related objects.
Now I can see operating system information and applications beyond that. Here I have double clicked on the operating system and then again on the IIS instance. This opens up the IIS cache, web service and service requests objects each of which has their own metrics and properties.
Now I can start to look at granular metrics for IIS including queue lengths, locking errors, connection attempts etc. In this example I am pulling metrics for the total number of GET requests to the default website.
This provides significantly more information than “Service Discovery” at the cost of having more agents, configuration and appliances to manage. In addition vROps includes symptoms and alert definitions for all the known applications which can be included in any of your policies.
Hopefully this give you an idea of how powerful the “VMware vRealize Application Management Pack” is.
