16.2 Application & Guest Monitoring

Observe the Layer That Owns the Symptom

A VM can have spare hypervisor CPU and memory while its database connections are exhausted or its web service is unavailable. Application monitoring adds guest/application measurements to the infrastructure view. It complements vCenter metrics, Logs and Service Discovery; it does not make any one of them unnecessary.

Start with the application symptom and service objective. Useful measurements can include operating-system filesystem use, process health, web requests or database-specific counters, depending on supported integrations. A hypervisor virtual-disk capacity metric does not reveal every guest filesystem's free space. A running process does not prove a successful client transaction.

Select a Supported Collection Method

Operations supports application-monitoring paths using Telegraf and applicable integration/plugin configuration. Verify the supported guest OS, application/version, agent and collector before installation. Select a small representative scope and the required application metrics. Installing an agent is not the same as configuring a database input with valid access and enabling collection.

For Kubernetes workloads, use the supported VKS/Supervisor monitoring integration and agent configuration for that service/release. Do not install an arbitrary guest-VM agent into every container and assume it becomes cluster monitoring. Separate cluster/node health from application/container measurements and check the integration's object relationships.

Prepare and Deploy

Confirm guest and collector reachability, time and certificate trust. Use the installation workflow supported by the installed Operations version and record whether deployment needs guest credentials, administrative rights or preinstalled prerequisites. Restrict the runtime monitoring account to its documented privileges rather than leaving a general administrator credential in every plugin.

Cloud Proxy communication is feature-specific. Broadcom KB 374807 documents ports 443, 4505 and 4506 in applicable Telegraf monitoring communication. Validate the required direction and endpoints against the current port matrix; do not assume the single HTTPS connection used by another collector feature covers application monitoring.

Install/enable the supported agent on a representative VM, configure the intended application input and verify its collection state. Check current timestamps and at least one independently known value inside the guest/application. If the agent is connected but application fields are missing, inspect input configuration, application compatibility and credentials before reinstalling it.

Correlate Without Confusing Units

Suppose users report slow web responses while guest CPU remains low. Compare request rate/error/response-time data, guest memory and filesystem metrics, VM scheduling contention, storage latency and relevant logs for the same absolute interval. A database dependency or network connection issue can dominate response time even when CPU utilization is low.

Conversely, a high guest CPU percentage can reflect useful load rather than a hypervisor fault. Check host contention and application throughput. Rightsizing a VM requires understanding both demand and the application's concurrency/resource behavior; adding vCPUs is not the default response to every performance alert.

Configure a Useful Alert

Choose the correct object and metric, define an appropriate threshold or dynamic condition, add a wait/cancel behavior and provide a diagnostic recommendation. Use a controlled lab threshold to validate evaluation. Then enable the definition under the effective policy and test the outbound notification separately.

For example, an alert about a guest data filesystem nearing capacity must refer to that filesystem, not the entire datastore or a VM's configured virtual-disk size. Before automating expansion, check datastore headroom, virtual-disk/guest support, partition layout and the allowed maximum. Expanding the VMDK alone does not necessarily extend the guest filesystem.

Troubleshoot and Maintain

If measurements stop, check agent/service state, collector reachability, trust, application credentials, effective policy and the last successful sample. A certificate replacement can invalidate agent-to-collector trust. A plugin can remain installed while the target account expires. Preserve the relevant error and scope the repair to the affected layer.

Track deployment changes and agent/plugin versions. After an application upgrade, verify that expected metrics still exist and retain the same semantics/units. Remove or revise stale monitoring for decommissioned services so dashboards do not imply coverage that no longer exists. Review resource overhead under realistic event/metric volume rather than promising zero monitoring cost.

A complete exercise demonstrates a supported monitored application, a verified known measurement, a controlled fault or threshold, alert evaluation and authorized notification. Record how the application maps to its VM and supporting datastore/host. This evidence supports practical incident response and distinguishes deep application monitoring from a simple discovered service name.

Review Takeaways

• Infrastructure metrics, guest/application metrics, logs and discovery answer different questions.
• A connected agent still needs supported application inputs, credentials and current collection.
• Validate feature-specific collector network paths, certificate trust and effective policy.
• A VMDK expansion and guest filesystem expansion are separate operations.