CentOS 6.4

that shouldn't be the case. are you sure you haven't specified listenip as 0.0.0.0 ?

ZBX-6313 explain some things and could help in such cases.

Sorry, I shouldn't have put that last part in there. It was a red herring. I think that was a maybe a problem with an older version of the agent. I just tested again and is no longer the case.

The main point of this request is: it seems that no matter what, the host gets added with "connect to IP" defaulted (and works just fine), it's just that I would like to in some cases have "connect to DNS" be the default instead.

One possible way as mentioned would be to make it a configurable option in the auto registration path, but if I only have a subset of hosts that need this, may become more complex with having to set conditions.

Perhaps more flexible would be to have the host specify this somehow in the agent conf. One possible suggestion would be if you were able to specify the FQDN as the ListenIP, then the server would know based off this that you want it to connect to the DNS name instead of IP, but I will leave that logic up to the coders.

I'm facing the same issue as described by Rob Brown.

In disk image I use to provision my VMs with, the agent is preconfigured to listen on 0.0.0.0 address (since there is no way to know beforehand which IP the VM will be assigned with)
Unfurtunately, when such machine autoregisters, It's set to communicate with it's discovered IP (which is 0.0.0.0, taken from the agent ?) and obviously this doesn't work. Switching it to "connect to" DNS instead, solves the problem, but needs to be done manually for all machines autoregisterd.

I'm using Ubunu 14.04 with zabbix software installed from the official repo:

1. zabbix_agentd -V
   Zabbix Agent (daemon) v2.4.3 (revision 51175) (15 December 2014)
   Compilation time: Dec 18 2014 17:15:52

1. zabbix_server -V
   Zabbix server v2.4.2 (revision 50419) (5 November 2014)
   Compilation time: Nov 11 2014 05:45:04

Any status update on this issue ?

Host autoregistered, IP is 0.0.0.0 as specified in zabbix_agentd.conf ( ListenIP=0.0.0.0 ).
The registered host is set to connect to IP.
Screenshot is attached...

I may be having this same issue. Setting up a brand new test environment. 2.4.3 agent, 2.4.2 server, 2.4.2 proxy.

Agent auto-registers without issue, with proper IP and hostname. ListenIP is not configured, however it defaults to using the IP interface.

May I ask for some progress on this issue ?
This functionality is critical for cloud infrastructues.
A machine may never have a fixed IP (DHCP) so the agent can only be configured to listen on 0.0.0.0, such machines are configured incorrectly by auto discovery: IP 0.0.0.0, connect to IP (see screenshot)

Suggestion:
If autodiscovered IP is 0.0.0.0 set the "connect to" option to DNS

or

let this be configured in the agents config.

Our workstations are using dynamic dns and can change ip from time to time, it would be useful to have the option on add a host by dns instead of ip so we can use auto registration/discovery on them

Got some spare time to attempt and make a patch for this issue. (just for fun)
It works but, there should be something small, that I'm missing...

The host is created with two interfaces instead of one:
1. The default interface (IP: 0.0.0.0, host's name and "Connect to" DNS) - just what I wanted
2. Second interface (the 0.0.0.0 and "Connect to" IP) - not sure where this comes from

This configuration works (host is being checked ok), but the second interface is not something that should be there...
I'll get to this later, when I have more time....

edited

Found the problem with double interface, attaching patch if someone wants to play with it.

Disclaimer: I made it just for fun, the code may not be pretty (copy-paste), I'm not a pro-C-Programmer.

This patch works for machines with zabbix agent configured to listen on 0.0.0.0.
If agent's IP is 0.0.0.0, the host's interface is configured with host's name and "Connect to" DNS is set automatically.

I can understand reluctance to introduce DNS as a dependency of Zabbix, however the increasing need to monitor DHCP pools of servers means that this patch (or one like it) is a must.

Hello. Is there any plans to do something with it? It's really important feature for dhcp networks and many people want it. Thanks.

Kell,
apparently it's not on the road map yet.

you can use mysqlquery for this. like this one
mysql --database=zabbix --execute="update interface SET useip=0 where dns<>'';"

it will set in the table zabbix all useip values to 0 where dns values are NOT(edited) empty. you can add it to crontab as a job.

you can check which values will be affected, just run mysql
USE zabbix;
select * from interface where dns<>'';

it will set in the table zabbix all useip values to 0 where dns values are empty. you can add it to crontab as a job.

Yeah that's how you build an enterprise monitoring system, with zabbix.

[quote]Yeah that's how you build an enterprise monitoring system, with zabbix.[/quote]
Yep, with dances in mysql)

guys, better place for such discussions is forum or IRC

Issue summary extended to include network discovery too, I believe it's ok to consider both "parts" in single feature request.

Is there any plans to fix it? I think 2 years is enough to wait
It's really hard to monitor dhcp pools with 300+ computers without such feature, also I don't think it will break anything.

kell,
are you aware of the possibility to (co-)sponsor development?

No offence, but this looks like an extortion (create an 'enterprise' monitoring software while 'forgetting' to include some basic functionality, then have customers (who already 'hooked up' to the software) pay for this basic functionality).

Для рабочих станций это делается по-другому. Через auto-registration по host metadata.
в жабе auto-registration
A Host metadata like workstations

zabbix_agent.conf

ServerActive=10.10.120.11
HostnameItem=system.hostname
HostMetadataItem=workstations

Он сам будет толкаться в жабу, причем регается по днс

hmm, please see http://zabbix.org/wiki/Docs/bug_reporting_guidelines#Reporting_an_issue - especially the very first sentence there

zerthimon, issue comments is not the right place for general discussion - but what's "the principle of 'open source software'" in your opinion ?
you deleted that part, but it seems to be important to the understanding on how we interpret these things.

@richlv, I deleted that sentence 'cuse thought it's more of a way to taunt you, somtheing I actually don't want, really.
But anyway, a component of the software connecting by a DNS name to another component of the same software, does look like an advanced feature to you that should be payed for ?

it doesn't matter that much what exact functionality it is - you can probably find hundreds of missing simple and very important pieces requested in jira.
and the same for most/all other products

This pains me too. I think it started after upgrade to 2.4, though. Before autoregistered nodes seemed to have used DNS.

I agree that Zabbix lacks many features needed by an enterprise system. But, anyone who thinks that a feature is not worth paying for, can implement it himself for free. Or STFU.

This would be great to have for sure! Very helpful when using DHCP

I am in the process of setting up a new site with a new zabbix 3.2 server, and was surprised to find this still is an issue, and ran across this old post of mine. I decided to dig into it and came up with a nice, easy solution that so far is working for me (with limited testing).
Here is what I did:
1) Install zabbixapi rubygem on zabbix server (https://github.com/express42/zabbixapi)
2) Copy the attached script into /usr/lib/zabbix/externalscripts/set-interface-to-dns.rb (and update your connect parameters)
Make it executable and owned by zabbix server user.
3) On the zabbix server GUI, go to: Administration/Scripts/Create script.
Name: set-interface-to-dns
Type: Script
Execute on: Zabbix server
Command: /usr/lib/zabbix/externalscripts/set-interface-to-dns.rb {HOST.HOST}
4) Configuration/Actions/Auto registration/Create action
Name: default auto registration (or whatever you like)
Conditions: leave blank as a catchall, or specify based on your needs
Operations/New:
Operation type: Remote command
Target list: Current host, add
Type: Global script
Script name: select, set-interface-to-dns
Add (the text link, not blue button)
Operations/New: again, and add an "add host" operation, and any other operations you need to do on registration.
When all done, click Blue "Add" button.

Now, when hosts auto-register, they will immediately be reconfigured to use DNS instead of IP.
You could probably also do this as just a "custom script" type inside of the registration rules instead of global script, but I found having it defined as a global script is handy because you can click a hostname in various places in the GUI which shows the scripts popup and run the script against any stray hosts.

I just kinda scraped this script together from various other posts, so any improvements are welcomed!

I, for one, would like to see this native, and not require an external script.

I agree completely. I can script this myself, but believe the community benefits from native support.

hah, well I submitted the feature request 3 years ago, so don't hold your breath.

I'm saying I wouldn't mark this closed.

agreed. Please Re-open. If not, I will open a new ticket.

I, for one, will not introduce ruby into my environment any more than I have to (puppet)

Nor will I fiddle with the API for something that really needs to be native, inherent to Zabbix itself.

I commend OP for solving his/her problem, but there are many others out there who still have it, out of the box.

reopened

@Rob Brown, the script only works on hosts without templates. I add templates directly and this gives some problems.

I made some changes to your script:

#!/usr/bin/ruby

require "zabbixapi"
# from: https://github.com/express42/zabbixapi

if ARGV.empty?
  puts "Usage: "
  puts "#{$0} hostname"
  exit 1
end

zbx = ZabbixApi.connect(
  :debug => "1",
  :url => 'http://zabbixserver/zabbix/api_jsonrpc.php',
  :user => 'username',
  :password => 'password'
) # obviously, update these for your environment

hostname = ARGV[0]

hostid = zbx.hosts.get_id(:host => hostname)

unless hostid.nil?
  interface_id = zbx.query(
  :method => "hostinterface.get",
  :params => {
    :output => "interfaceid",
    :hostids => hostid,
    :filter => {:main => 1, :type => 1}
    }).first["interfaceid"]

  zbx.query(
    :method => "hostinterface.update",
    :params => {
    :interfaceid => interface_id,
		:ip => '0.0.0.0',
		:dns => hostname,
		:port => 10050,
		:useip => 0
	})

else
  puts "host not found #{hostname}"
end

This sets the hostname to the name the Zabbix host gets (we add all our hosts with the FQDN as hostname), it changes the IP to something pointless 0.0.0.0.

Any progress?

Holy crap, this is not implemented, after 5 years ?

This issue brings memories....

Damn, I'm not even using this crappy monitoring soft anymore (partly because of issues like this) and still get notifications. There so much better monitoring solutions available.

Unsubscribed.

For networks with DHCP this functionality is critical, can you listen to the opinion of the people who left the comment and solve this problem?

Denis, Mikhail - in Zabbix, the most sure way to get some functionality would be to finance it as per https://www.zabbix.com/forms/development_services_DevelopmentRequest .

Dear developers, you have been keeping the task for 5 years, which is possible to solve with minimal expenses, namely to realize the choice of how to inventory nodes by IP address or DNS name, when auto-adding nodes, while the functionality of the type of inventory is present in the product? At the same time, the flexibility and attractiveness of this system will only increase, which in turn will attract new users, but instead you ask one client to pay for the entire scope of work. If there is an irresistible desire to earn money, then calculate the cost of this refinement and publish it here and we will try to collect the necessary amount in the form of donations by the whole world.

I agree with Mikhail on this. 

Agreed.

I don't think that anyone want to criticize someone for open source project, but it's really important feature and one of those about which you don't even think that they are not implemented.

It is likely to be implemented in 4.4, thanks for you patience. 

Dear voters, please tell us what you think: shall this be configured on Zabbix agent or Zabbix server side and why? Which way is preferable in your case?

At a minimum, I'd like to be able to setup the default server-side. It'd be great if you could override that from the agent. The preference for this is that we wouldn't have to change any of the current configuration on clients that are being provisioned. 

alexjhart, what should be used as DNS name? Agent hostname? Or try to retrieve DNS with reverse PTR query using IP registration came from?

I expect that agent hostname is what most would expect to be used. 

I would recommend it coming from the Agent, that way it comes from the source instead of relying on outside servers to identify it

Dear Zabbix dev team, any chance to release this feature in a 4.2.X maintenance release instead of 4.4 release, unless 4.4 is near the corner. Thank you!

Does this feature will also fix or somehow help with https://support.zabbix.com/browse/ZBXNEXT-1740?

Currently I'm using only 'Connect to DNS' option, and IP also removed from host settings after registration because it can change. As a result new duplicate interfaces are created for every host time to time.

It is highly likely this functionality is coming in Zabbix 4.4 in September.

Fixed in:
    * 4.4.0alpha2 (master) 4b41ef5a7be, 0f245dfbeb6, 40fb4042f0c

Updated documentation:

• What's new
• Auto registration
• Agent configuration files: UNIX, Windows

Thank you for the doc updates, Alexander.
The whatsnew page link anchor should lose the first underscore (auto_registration_with_dns_name -> autoregistration_with_dns_name).

Thanks, richlv, fixed.

What's the difference between HostInterface and HostInterfaceItem? Why would I use one over the other? It's not obvious to me from any of the above documentation links.