Best practice for combining VMware-discovered VMs, Zabbix agent hosts?
I am looking for guidance on the best way to model a monitoring situation in Zabbix where a single real-world system may appear as multiple Zabbix objects depending on the discovery or collection method.
Environment / context
I am monitoring VMware through vCenter using the Zabbix VMware templates and low-level discovery. The VMs are discovered automatically and created as Zabbix hosts from the VMware discovery host prototype.
In addition to the VMware-level monitoring, I also install the Zabbix agent or Zabbix agent 2 inside the guest OS so I can collect OS-level metrics, application metrics, filesystems, services, processes, and other agent-based checks.
The issue is that these can become two different Zabbix hosts:
I understand that one workaround is to make the Zabbix agent report the same host name as the VMware-discovered host, for example using the VMware UUID or the VMware FQDN naming scheme. However, that does not fully solve the modeling problem.
Main problem
Once a VM is created by VMware discovery, important configuration such as host group membership is effectively owned by the VMware discovery host prototype. I cannot simply manage that VM like a normal manually-created host and freely add it into the operational host groups that would normally be assigned by agent autoregistration.
The workaround appears to be:
That works technically, but it becomes awkward when different discovery sources or monitoring methods need to describe the same real-world entity. Similar pattern with HA / website monitoring
I also run into a similar conceptual issue with HA website monitoring. A single logical service may depend on multiple technical objects:
Zabbix Services can represent a service tree and calculate parent status from child services, but that is not quite the same as having a logical parent host-like object that aggregates multiple related hosts, interfaces, templates, inventory, tags, and problems. Zabbix service trees are status-oriented and use child services/problem tags to calculate service state, which is helpful, but it does not solve the host identity/configuration issue. 1 Service tree
What I am trying to achieve
Ideally, I want one logical object for the real-world system, even if the data comes from multiple sources.
Example:
The goal would be to see and manage the system as one thing while still preserving the individual discovered/technical objects underneath it.
Questions
What is the recommended Zabbix design pattern for this today?
Should this be handled with:
Also, is there a better way to handle cases where the VMware-discovered object and the agent-discovered object represent the same real-world machine, but each discovery method wants to own different parts of the configuration?
I am trying to avoid creating duplicate hosts, but I also do not want to force every monitoring source into one discovery template if that is not the right model.
Thanks for any advice or examples from people who are handling VMware + agent + service-level monitoring at scale.
Environment / context
I am monitoring VMware through vCenter using the Zabbix VMware templates and low-level discovery. The VMs are discovered automatically and created as Zabbix hosts from the VMware discovery host prototype.
In addition to the VMware-level monitoring, I also install the Zabbix agent or Zabbix agent 2 inside the guest OS so I can collect OS-level metrics, application metrics, filesystems, services, processes, and other agent-based checks.
The issue is that these can become two different Zabbix hosts:
Code:
VMware-discovered VM host - Created by VMware LLD / host prototype - Identified by VMware UUID, FQDN, or vCenter-derived data - Host groups and discovery-owned settings are controlled by the VMware host prototype Agent-discovered or autoregistered host - Created or updated by agent autoregistration - Identified by agent Hostname / system hostname - Can be assigned to groups/templates through autoregistration actions
Main problem
Once a VM is created by VMware discovery, important configuration such as host group membership is effectively owned by the VMware discovery host prototype. I cannot simply manage that VM like a normal manually-created host and freely add it into the operational host groups that would normally be assigned by agent autoregistration.
The workaround appears to be:
Code:
Clone/customize the VMware template
-> Edit the VM discovery rule
-> Edit the VM host prototype
-> Add static host groups or group prototypes there
I also run into a similar conceptual issue with HA website monitoring. A single logical service may depend on multiple technical objects:
Code:
Logical service: Company Website - Public HTTPS checks - Internal application checks - Load balancer / VIP checks - Web server VMs - Database or backend dependencies - Possibly multiple HA nodes
What I am trying to achieve
Ideally, I want one logical object for the real-world system, even if the data comes from multiple sources.
Example:
Code:
Logical object / parent: prod-web-01 Children / data sources: VMware-discovered VM object Zabbix agent object Web scenario object SNMP/iLO/IPMI object Cloud/discovery object
The goal would be to see and manage the system as one thing while still preserving the individual discovered/technical objects underneath it.
Questions
What is the recommended Zabbix design pattern for this today?
Should this be handled with:
Code:
1. VMware FQDN template and agent hostname alignment? 2. Cloned VMware templates with customized host prototypes? 3. Group prototypes based on VMware folders/tags? 4. Zabbix Services? 5. Host tags and tag-based views? 6. API automation to keep discovered hosts aligned? 7. Some other approach?
I am trying to avoid creating duplicate hosts, but I also do not want to force every monitoring source into one discovery template if that is not the right model.
Thanks for any advice or examples from people who are handling VMware + agent + service-level monitoring at scale.