Documentation for up.time 7.1 If you are looking for the latest version view

Unknown macro: {spacejump}

or visit the current documentation home.

VMware vSphere Monitoring Concepts

There are three main conceptual components to integrated virtual and physical monitoring:

  • metrics for VMware vSphere components, mainly pertaining to resource usage, but also including power states
  • up.time ’s vSync feature, the syncing engine that ensures VMware vSphere components and inventories are accurately mirrored in up.time , as well as their basic, non-agent-based metric data
  • vSphere components that are monitored and managed as up.time Elements; these include VMware vCenter servers, ESX servers, and VMs

In addition to understanding these concepts, it is important that you also understand the way other up.time functions change in a VMware vSphere monitoring context.

About up.time vSync

The core of integrated monitoring is up.time ’s vSync, whose key functions are replicating metrics and mirroring topologies, from VMware vSphere to up.time .

vSync takes performance metrics gathered by VMware vSphere, normally for use in VMware tools such as the vSphere Client, and represents them in up.time . VMware vSphere metrics that are available in up.time include performance data for VMs, the ESX servers that host them, and the VMware vCenter servers that manage your configurations (including but not limited to datacenters, clusters, and resource pools).

vSync also regularly monitors your VMware vSphere datacenter’s dynamic environment (including both physical and virtual assets), ensuring the VMware vSphere inventory that up.time is using for monitoring and reporting is always current. For more information, see Managing vSync.

vSphere Components as up.time Elements

Some VMware vSphere components that act as logical groupings, including datacenters, clusters, resource pools, and vApps, are hierarchically mirrored in up.time ’s My Infrastructure inventory, and are represented through their reported resource metrics. On the other hand, VMware vSphere components that are actual hosts, whether virtual or physical (i.e., a VMware vCenter server, its component ESX servers,or their respective VMs) are represented in up.time as Elements.

When you add a VMware vCenter server as an Element, all of the VMware vSphere components, whether organizational or compute resources, as defined through the vSphere Client, are imported to up.time , and their VMware-vSphere-collected metric data is migrated to the up.time DataStore. Additionally, all ESX servers and VMs also become Elements.

There will be cases where administrators will want to actively manage which ESX server Elements (and subsequently, which VMs) are monitored by up.time . For example, licensing constraints may prevent you from monitoring every ESX server in up.time , or the performance of particular portions of your virtual infrastructure may not be considered mission critical, and demand the same level of uptime.

In these cases, administrators can include or exclude specific up.time Elements from being monitored. Exclusions can be made on a per-VM basis, or by a logical grouping at the VMware vSphere level (e.g., by cluster).

Any VMware vCenter component is by default represented in My Infrastructure as either a known host or a known VM, and is grouped as such in the inventory. (By default, the My Inventory group names are Discovered Hosts and Discovered VM Hosts ). When Elements are ignored, they are removed from My Infrastructure . If new hosts or VMs are discovered during vSync, they are added to the appropriate My Infrastructure group.

For more information, see Managing vCenter Inventories in up.time.

vSphere Components and Topological Dependencies

When a VMware vCenter server is added to up.time , the hierarchical structure of its components is retained (and used in My Infrastructure ). up.time observes particular monitoring rules to these existing VMware vSphere topologies that supplement the behavior of physical topologies that have been defined in up.time . (See Topological Dependencies for more information.)

When you define a physical topology or VMware vSphere topology in a Topological Dependency, the following behaviors are commonly observed:

  • if a topological parent is experiencing downtime, the child Elements in the topology will share the status (i.e., an Element's dependencies will automatically switch to its status)
  • an outage with an Element, whether actual or topological, will initiate a host check on its parent (e.g., a service monitor and its host, or a host and its topological parent)

However, there are behaviors unique to Topological Dependencies based on a VMware vSphere topology:

  • as VMs migrate, their links to their ESX hosts is maintained
  • up.time will be aware of power states in the virtual infrastructure, such that parent Elements that are powered down will not spawn alerts with its child Elements (e.g., all of a VMware vCenter servers many ESX servers and VMs)

vSphere Object Names in up.time

When you first add a VMware vCenter server to up.time as an Element, all of its managed ESX hosts and VMs are automatically added to up.time ’s monitored inventory. Each of these Elements is configured to sync its display name and host name with values used with the VMware vSphere Client. The display name is mapped to the ESX host or VM object name in the VMware vSphere Client, and the host name is mapped to its DNS name. During vSync, any naming changes in vSphere are migrated to up.time Elements, and as such these names are by default not editable in up.time .

If desired, you can manually disable display name and host name syncing with individual ESX hosts or VMs, and enter a name that will be used in up.time , regardless of what it is on the network or in the VMware vSphere Client. See ESX Server Element Profiles or VM Element Profiles for more information.

Note that when a VMware vCenter server is added to up.time , and there are ESX hosts and VMs that are already part of the up.time inventory, these pre-existing Elements’ display names and host names are not synced with vSphere. After adding a VMware vCenter server, if you would like all ESX host and VM names to be updated through vSync, you will have to manually enable the name sync options for each of these Elements.

vSphere Components and Service Groups

In up.time , vSphere service groups exist to allow you to group similar Elements to perform common host checks, not unlike groupings created in the vSphere Client (e.g., a cluster or datacenter). The key difference with vSphere service groups from regular ones is once established, vSphere service groups will be managed by the vSync process. Any changes detected with the VMware vCenter server’s topology will automatically be reflected in the up.time service group.

For information on creating a service group, see Creating Service Groups.

Reports and Graphs for vCenter Server Metrics

As one of vSync’s main benefits is to enable you to combine virtual and physical monitoring, the following up.time tools are available assist with VMware vSphere analysis and reporting.

Service Monitors consist of the following:

Diagnosis graphs consist of the following:

Reports consist of the following:

  • No labels