attach additional tags as defined in DATADOG_TAGS environment variable

[ewdurbin]

creates an additional technique for adding tags to all metrics by defining a comma separated list of tags in the DOGSTATSD_TAGS environment variable.

use case:

currently we add a plethora of global tags by adding them to our dd-agent configuration on each node. as we progress towards using container technologies, it would be swell if we could seamlessly inject some of these tags on a container by container basis (app name, version, build) rather than adding them to the dd-agent which will be configured with tags for instance id, region, availability-zone etc.

[yannmh]

Nice feature, thanks a lot @ewdurbin. We'll review and consider your changes for an upcoming release.

On a side note, I am quite confused by the use case you are describing. It sounds like you are looking for a convenient way to set constant tagging on Datadog Agent metrics (including metrics received from statsd protocol). If so, I think the following changes on dd-agent repository would be a better fit DataDog/dd-agent#2095.
Your changes would only add constant tagging to metrics sent using datadogpy library, i.e. a subset of custom metrics.
What do you think ?

[ewdurbin]

@yannmh there's a bit of finesse.

Example:

Assume we have two docker hosts hostA and hostB running in separate availability zones, and a few applications with information like name, version, build.

Currently, running dd-agent as a docker container on each docker host, we may configure it to have the following tags:

• instance-id
• region
• availability-zone

Unfortunately this leaves the owners of the application to manually add the application_name, application_version and application_build_number to their code before instantiating their statsd client.

This feature allows us to inject DOGSTATSD_TAGS into the docker container with the application specific tags at launch and have it point blindly at the shared dd-agent, but still end up with the following tags:

• instance-id
• region
• availability-zone
• application_name
• application_version
• application_build

without needing to either manually add them in code (passing constant_tags to the client) or running a separate dd-agent for each application on the docker host.

[yannmh]

It completely makes sense. Thanks for the further explanations @ewdurbin !

[yannmh]

Can we limit env_tags scope to the function only ? i.e.

env_tags = ...

# Instead of
self.env_tags = ...

[yannmh]

It looks great, thanks again @ewdurbin.

I simply added a few nitpicks. Please let me know your thoughts about it, so we can merge your contribution.

[yannmh]

Thanks for the quick update @ewdurbin ! Let's merge it

[yannmh]

I am thinking about adding the same feature to dogstatsd's HTTP cousin ThreadStats.
Thus, I am wondering if it wouldn't be better to rename DOGSTATSD_TAGS to DATADOG_TAGS instead. What do you think @ewdurbin ?

[ewdurbin]

This PR already includes the addition to ThreadStats. I'm fine with renaming it to a more general DATADOG_TAGS.

[yannmh]

Thanks @ewdurbin. Let's merge it 🚢