Good Day. I'm in the processes of configuring Zabbix monitoring for our corporate network and I've run into an issue for which I have not been able to find a solution. (All of this is referring to Windows hosts by the way.)
I have Discovery and Actions configured to auto register hosts as new agents are deployed to my Windows hosts. Discovery picks up the request from unknown host and the Action registers, groups and attaches a template.
Some hosts are easy because they have Static IP addresses; the auto-registration simply works out of the box with HostnameItem=system.hostname in the agent config file. The auto-registration creates hosts with the Windows NetBios name as the 'Name' in Zabbix server and the IP address as the interface which keeps DNS query traffic from the Zabbix server to a minimum.
Where this falls apart is when I try to configure the auto-registration for my DHCP Client hosts (workstation class equipment). I would prefer that the DHCP Client hosts auto-register with their DNS name as the interface - given that the IP address on those hosts may change over time; I don't want to invalidate metric history or end up with abandoned or mis-matched hosts if host IP addresses change around (say after an extended power outage).
I have a separate Discovery rule limited to my DHCP client pool IP range and an Action to register any discovered host attached to that Discovery rule. In my agent config file (a specific version of the config for DHCP client hosts) I have set HostnameItem=system.hostname for the visible identifier in the Zabbix server and I've also set HostInterfaceItem=system.hostname - which, according to the documentation, should determine the interface defined for the host object in the Zabbix server.
This, however, does not seem to work as intended. The first thing I can honestly say that I'm missing is a practical example of what the entry HostInterfaceItem in the config file is expecting. I'm simply guessing (for lack of any clear documentation or practical example) to use the same key as I have in HostnameItem, however as mentioned, it does not seem to work. Hosts are auto-registering with the Zabbix server having the correct 'name' but incorrect 'interface'. I want the NAME to be the Windows Netbios Name - which is currently functioning properly - however the Interface only ever utilizes the host's IP address and not the hosts DNS name (FQDN), regardless of the entries in the config file.
It is not documented (that I've seen) where HostInterfaceItem is overridden by HostnameItem; only that HostInterfaceItem is ignored if HostInterface is defined - and I have not defined HostInterface; it remains commented out.
I have 3 test hosts (Windows workstations obtaining IP by DHCP) which have the Agent installed (Agent1 - v.5.1) - for 2 of those hosts I have created manual host entries in Zabbix server using the DNS FQDN as the interface. The server and host agents communicate fine, the Agent heartbeats in with the server and passes metric data.
For these 3 test hosts, the Discovery and Auto-registration continue to function - with the default behavior of using an IP for Interface. After a while when Discovery runs (I have the Discovery time set real low for testing purposes) all 3 hosts are auto-registered, for the 2 hosts that were manually created using the DNS FQDN for the interface, duplicate hosts (suffixed by _2 ) are created with the IP as the interface; these are clearly duplicates. The 3rd test host is generated as a new host object on Zabbix server also with the IP address as the Interface. I would expect this 3rd host (also using HostInterfaceItem=system.hostname in the agent config) to be created with the DNS FQDN as the Interface, however it does not.
I continually delete the 3 errant hosts from Zabbix server pending my next attempt/trial/test, however when they are recreated the behavior is unchanged; only the IP address is used as the Interface for the host object in Zabbix server despite the agent config. So, either I have some conflicting configuration in the agent config file or HostInterfaceItem simply doesn't work as intended.
I've looked through the logs on both server and agent and I do not see any errors related to discovery/actions/registration at all; no entries at all for the two [..._2] duplicate hosts objects; Successful Active Checks initiated (or whatever the log message says) for the successfully registered hosts, so i know they are communicating and functioning.
At the very least, can someone either validate that system.hostname is a valid key for HostInterfaceItem or give me some practical examples, or if possible a complete list of available keys that will function for that configuration item.
OR
If someone knows or can point me in another direction to investigate where this might be falling apart it would be greatly appreciated. As mentioned, I have discovery and auto-registration functioning fine where the desired end result is a Zabbix host object with an IP only interface; however variations on that configuration - intended to create Zabbix host objects having a DNS Interface simply do not function as intended and the default behavior of IP interface is the only behavior.
Thanks so much in advance for any insight, assistance or sympathy.
I have Discovery and Actions configured to auto register hosts as new agents are deployed to my Windows hosts. Discovery picks up the request from unknown host and the Action registers, groups and attaches a template.
Some hosts are easy because they have Static IP addresses; the auto-registration simply works out of the box with HostnameItem=system.hostname in the agent config file. The auto-registration creates hosts with the Windows NetBios name as the 'Name' in Zabbix server and the IP address as the interface which keeps DNS query traffic from the Zabbix server to a minimum.
Where this falls apart is when I try to configure the auto-registration for my DHCP Client hosts (workstation class equipment). I would prefer that the DHCP Client hosts auto-register with their DNS name as the interface - given that the IP address on those hosts may change over time; I don't want to invalidate metric history or end up with abandoned or mis-matched hosts if host IP addresses change around (say after an extended power outage).
I have a separate Discovery rule limited to my DHCP client pool IP range and an Action to register any discovered host attached to that Discovery rule. In my agent config file (a specific version of the config for DHCP client hosts) I have set HostnameItem=system.hostname for the visible identifier in the Zabbix server and I've also set HostInterfaceItem=system.hostname - which, according to the documentation, should determine the interface defined for the host object in the Zabbix server.
This, however, does not seem to work as intended. The first thing I can honestly say that I'm missing is a practical example of what the entry HostInterfaceItem in the config file is expecting. I'm simply guessing (for lack of any clear documentation or practical example) to use the same key as I have in HostnameItem, however as mentioned, it does not seem to work. Hosts are auto-registering with the Zabbix server having the correct 'name' but incorrect 'interface'. I want the NAME to be the Windows Netbios Name - which is currently functioning properly - however the Interface only ever utilizes the host's IP address and not the hosts DNS name (FQDN), regardless of the entries in the config file.
It is not documented (that I've seen) where HostInterfaceItem is overridden by HostnameItem; only that HostInterfaceItem is ignored if HostInterface is defined - and I have not defined HostInterface; it remains commented out.
I have 3 test hosts (Windows workstations obtaining IP by DHCP) which have the Agent installed (Agent1 - v.5.1) - for 2 of those hosts I have created manual host entries in Zabbix server using the DNS FQDN as the interface. The server and host agents communicate fine, the Agent heartbeats in with the server and passes metric data.
For these 3 test hosts, the Discovery and Auto-registration continue to function - with the default behavior of using an IP for Interface. After a while when Discovery runs (I have the Discovery time set real low for testing purposes) all 3 hosts are auto-registered, for the 2 hosts that were manually created using the DNS FQDN for the interface, duplicate hosts (suffixed by _2 ) are created with the IP as the interface; these are clearly duplicates. The 3rd test host is generated as a new host object on Zabbix server also with the IP address as the Interface. I would expect this 3rd host (also using HostInterfaceItem=system.hostname in the agent config) to be created with the DNS FQDN as the Interface, however it does not.
I continually delete the 3 errant hosts from Zabbix server pending my next attempt/trial/test, however when they are recreated the behavior is unchanged; only the IP address is used as the Interface for the host object in Zabbix server despite the agent config. So, either I have some conflicting configuration in the agent config file or HostInterfaceItem simply doesn't work as intended.
I've looked through the logs on both server and agent and I do not see any errors related to discovery/actions/registration at all; no entries at all for the two [..._2] duplicate hosts objects; Successful Active Checks initiated (or whatever the log message says) for the successfully registered hosts, so i know they are communicating and functioning.
At the very least, can someone either validate that system.hostname is a valid key for HostInterfaceItem or give me some practical examples, or if possible a complete list of available keys that will function for that configuration item.
OR
If someone knows or can point me in another direction to investigate where this might be falling apart it would be greatly appreciated. As mentioned, I have discovery and auto-registration functioning fine where the desired end result is a Zabbix host object with an IP only interface; however variations on that configuration - intended to create Zabbix host objects having a DNS Interface simply do not function as intended and the default behavior of IP interface is the only behavior.
Thanks so much in advance for any insight, assistance or sympathy.
Comment