Why do we try to read /etc/dd-agent/datadog.conf?

[tgwizard]

Why does the datadog library try to read the Datadog Agent config on /etc/dd-agent/datadog.conf? It seems to only be used in

datadogpy/datadog/util/hostname.py

Line 54 in 969c703

config = get_config()

, and it is causing some issues for us.

To be able to read the config file, the service running the datadog library must have read privileges for that file. However, the default settings from the datadog cookbook marks the config file as owned by dd-agent:root, with permissions 0640. We don't want to run our services as either the dd-agent user or a user in the root group, and the datadog cookbook doesn't allow us to change the permissions.

It all works fine even without the read permissions - datadog defaults to parsing hostname -f. However, as of #161, we get a log line like

2016-10-30 20:57:28,874: INFO: (-) datadog.api: No agent or invalid configuration file found

every time we start our services.

Why do we need to read the hostname from the config file - isn't hostname -f good enough? Or do people often have custom hostnames in the datadog agent config file? How do people solve the config file permission issue?

[yannmh]

Thanks for reporting @tgwizard.

The idea is to grab, if defined, the hostname configured in the datadog.conf so that metrics, events and service checks sent via the HTTP API (datadog.api or datadog.threadstats packages) can use the same hostname as the agent active on the same host.

However, I realize this is not a good idea:

1. As you described, the library should not and may not have the permission to read the datadog.conf agent configuration file.
2. This is unnecessary. If an agent is running on the host, one can use datadog.statsd to automatically tag resources with the agent's hostname.

[shpoont]

Is fix for this issue planned for release?

[dabcoder]

Apologies for the really long delay in updating this thread. We've taken care of this in #428 (downgrade to warning and add an option hostname_from_config=False to turn this off completely and we aim to deprecate this feature in the future.

[bkabrda]

Closing this issue now, see @dabcoder's comment above on how to get rid of these errors.