VCF Load Balancer Insight: Introduction

Version: 2026.1.2.1

What it is

VCF Load Balancer Insight is a VMware Aria Operations (VCF Operations) Management Pack that monitors the load balancing layer of a data centre. It is built as a single multi-vendor product: one adapter kind and one shared object model, in which the producer of a device is expressed only through the vendor and model properties. Two F5 models are supported today, both over the same iControl REST API: F5 BIG-IP LTM (model=LTM) and F5 BIG-IP SSL (model=SSL, the SSL-offload / SSL-termination role). Additional load-balancer vendors (for example Citrix ADC or NGINX) are intended to map onto the same objects rather than introduce new ones, and the F5 SSL model is itself a template for adding a further F5 model additively.

The Management Pack covers both the base layer of a BIG-IP, namely its system health, HA devices, network ports and SSL certificates, and the load balancing layer above it, namely virtual servers, pools, pool members, nodes, monitors and profiles. Both layers are mapped onto the same vendor-neutral model and shown together with their relationships in Aria Operations.

How does it work?

Authentication: the adapter signs in to the BIG-IP management interface over HTTPS and obtains a session token, or uses basic authentication when a token cannot be issued.
Capability probing: the adapter reads the module provisioning and the device list to decide which object families can be collected from the instance.
Base layer: the system identity, HA devices, network interfaces, VLAN membership and SSL certificates are read from the iControl REST API.
Load balancing layer: the virtual servers, pools, pool members, nodes, monitors and profiles are read from the /mgmt/tm/ltm/* namespace, together with their statistics.
SSL offload detail: on the SSL model the client-ssl and server-ssl profiles are read with their extended payload (certificate reference, cipher group, ciphers, TLS protocol set, SNI flags), and the cipher groups are resolved from /mgmt/tm/ltm/cipher/group.
Clusters: the HA group is read from the F5 Device Group when the account is permitted to see it, and otherwise synthesized from the device member list so that a cluster object always exists.
Mapping and emission: every value is mapped onto the shared object model. A value that the target does not expose or the account may not read produces no data point, never a zero.
Relationships: the topology, including the external links to virtual machines and IP addresses, is rebuilt on every collection cycle.

Models

The MP reports the running model of the instance through the top-level model property, selected with the Model instance parameter. Both models use the same F5 iControl REST client and the same endpoints; the parameter only labels the instance and never switches collection on its own — collection is still driven by the /sys/provision capability gate.

Vendor	Model	What it is	Where the difference shows
F5	`LTM`	BIG-IP running the LTM module (local load balancing)	Default model. The `ssl` group on LB Profile is empty unless the instance also serves SSL profiles.
F5	`SSL`	BIG-IP running the LTM module in the SSL-offload / SSL-termination role (for example an r4800 appliance)	The `ssl` group on LB Profile carries the SSL-offload configuration (certificate, cipher group, TLS versions, SNI).

Because the object model carries no vendor or model names, both models appear under the same dashboards, custom groups and relationships. When an instance has no ltm module provisioned, no LTM object and no ssl group is created — not a zero-valued one.

Features

One adapter instance per BIG-IP management address, covering system, HA, ports, certificates and the full LTM layer.
Ten object kinds shared across vendors: LB Cluster, LB Device, LB Port, LB Virtual Server, LB Pool, LB Pool Member, LB Node, LB Monitor, LB Profile and SSL Certificate.
Two F5 models under one adapter kind: LTM and SSL, distinguished only by the model property, so an SSL-offload estate is monitored with the same dashboards, groups and relationships as an LTM estate.
SSL-offload visibility: on the SSL model the LB Profile carries an ssl group with the terminating certificate, cipher group, cipher string, TLS protocol set and SNI behaviour.
Automatic cluster resolution: when the read-only account cannot see the F5 Device Group, the cluster is synthesized from the device members.
Full LTM topology: the virtual server -> pool -> pool member -> node chain is built as parent-child relationships every cycle.
External topology: virtual machines and IP addresses are linked to the LB objects they host or own.
Honest data: a value that could not be measured or read is omitted, so alerts never fire on a value that does not exist.
A multi-vendor foundation: because the object model carries no vendor names, a second load-balancer vendor can be added under the same dashboards, groups and relationships without rebuilding the monitoring model.

Benefits

Centralized load-balancer visibility: virtual servers, pools, members, nodes, monitors and certificates are monitored through a single adapter instance in Aria Operations, instead of being checked device by device.
Proactive health monitoring: CPU, memory and disk data on the polled device, plus availability and failover state on every cluster member, surface a degrading BIG-IP before it affects users.
Service-path awareness: the VS to Pool to Member to Node chain is visible as a topology, so an unhealthy backend is found from the virtual server that serves it.
Certificate peace of mind: every SSL certificate is inventoried with the number of days remaining, so renewals are planned rather than discovered in an outage.
Traffic and connection insight: current and maximum connections, request counters and bits per second per virtual server, pool, member and node show how close the load-balanced service is to its limits.

Products referenced:

VMware Aria Operations (VCF Operations)
F5 BIG-IP LTM and F5 BIG-IP SSL (iControl REST API)
phpIPAM Management Pack (external IP address relationship)
VMware vCenter (external virtual machine relationship)