Telegraf DNS issue with .local address

Hi, new user here. I am getting Telegraf set up on a Raspberry Pi and I would like to connect to an InfluxDB server on the local network using a “.local” address. This is all pretty unfamiliar to me and I am just learning, but I will describe the problem as best I can.

The InfluxDB server is running fine, the Pi resolves the “.local” address of the server using commands like ping and I can perform queries to the server from the Pi using curl, e.g.:

curl -G ‘http://david-desktop.local:8086/query?pretty=true’ --data-urlencode “db=_internal” --data-urlencode “q=SELECT * FROM runtime” > test.txt

But when I start up telegraf, I get the following:

2017/04/19 00:27:16 I! Using config file: /etc/telegraf/telegraf.conf
2017-04-19T04:27:16Z E! Database creation failed: Post http://david-desktop.local:8086/query?db=&q=CREATE+DATABASE+"telegraf": dial tcp: lookup david-desktop.local on 192.168.1.1:53: no such host

It appears to be trying to resolve the domain name using the /etc/resolv.conf file, which I confirmed by manually changing the IP address for the name server in the file and saw that the corresponding text in the error message would change.

A bit of homework suggests that this might be due to the Go language DNS resolver not handling these types of addresses (see “name resolution” in net package - net - Go Packages). The documentation says that it should try a different (C based) resolver in these cases, but perhaps this isn’t happening? Any ideas?

Thank you for your help!

@David_Ford Have you tried adding a line to your /etc/hosts file? That works for me in most cases. Welcome to InfluxDB btw!

If you are using our official arm builds, I expect that the cgo resolver cannot be used since they were cross compiled. You could try using the GODEBUG options from the go documentation you linked to confirm this.

Perhaps the dns resolution for ping is using a different method than go supports. Can you try running dig @192.168.1.1 david-desktop.local to see what the dns server’s response is and also cat /etc/nsswitch.conf to show any additional resolution methods your system might be configured to use?

Thanks @jackzampolin and @daniel! Good ideas. I am using avahi/mDNS to resolve the host and now I see that is very different from the normal lookup services used by many commands.

Troubleshooting this problem has allowed me to learn a lot more about these zero-config services that allow for easy lookup of these .local domains and I am starting to realize what a challenge this is!

For my particular use, I think it will be easier to write a simple python script to do what I need and use the HTTP API using Requests or the influxdb library instead of using the full feature set of Telegraf.

Thank you both for your help!

Thanks for update @David_Ford. If you were to rebuild Telegraf on your pi it should enable the cgo resolver and I think it will work. Python script sounds like it might do the job as well. Good luck with your project.

@daniel I had a little bit more time just now and did as you suggested and built Telegraf on the pi. It works just as you thought it might, resolving the mDNS name without any difficulty. Thanks!

Thanks for reporting back, we will have to keep an eye out for this as it affects all of our none amd64 linux builds.

Hi all,
I face the same problem that David had. I work on an IoT project involving multiple Pi’s. I configure all of them using ansible in order to manage “configuration as code”, so I stick to standard distribution of packages. Since the number of Pi’s can grow, I use zeroconfig/mDNS/avahi services. So, I cannot afford to re-build telegraf on my machines. Furthermore, I do not want to manage my own packages repository to keep as “standard” as possible.
Do you guys have any plan to include a fix in a forthcoming release ?

Thanks for the great job you are doing !

Best,

@ThierryGandilhon We will probably not be able to do this for some time since it would require substantial changes to our build scripts.

Hi @daniel. Thanks for the answer. Too bad … I’ll have to find another the solution.
Have a good day.
Best,