datadog issues

[justin8]

Just trying to test telegraf on datadog, as I need it working there before I can try to swap out datadog for influxdb+grafana+etc. I've found a couple issues, and I'll try and add more as I find them. Initially though I've found the following:

• Data is pushed with a 'host:foo.example.com' as expected, but (using system_load1 as an example) it shows data as coming from '*' and when doing system_load1 over host:foo.example.com shows 'nothing to be displayed':
  
  
• Metric names are not dot seperated on datadog; i.e. datadog-agent will push 'system.load.1'. It splits metrics similar to graphite; i.e. based on a dot split. telegraf pushes stats like 'system_load1'

[sparrc]

I'm not very familiar with datadog, @jipperinbham can you comment?

Re: dot-separated values, why is that an issue? InfluxDB doesn't put any meaning on dot-separated values so Telegraf doesn't either. We can easily convert "_" -> "." but then your measurements will have different names in InfluxDB and datadog.

[justin8]

That's true. but I don't believe we can query datadog's database directly; it's all via their webfrontend which is similar to grafana. I would at least vote for having the _ replaced by a . for that as it would allow it to be seamlessly swapped on the machines, but now reporting to two locations. Which allows current datadog users to very easily change over.

[jipperinbham]

@justin8 thanks for the info here, I'll try and get a PR up soon to address these.

Doing a gsub on _ to . makes sense for this use case.

I'm not sure what the deal is with the over portion of the query. I'll take a look at the datadog API again and see what I can figure out.

[justin8]

Let me know if you need any help with testing it. I have a few hundred machines on datadog currently that I can use to test some of these changes.

[sparrc]

@jipperinbham I'm working on a fairly large change to the accumulator that is affecting the datadog code quite a bit. Just an FYI that you might want to wait for me to get that pushed first. See #292

[jipperinbham]

@sparrc thanks for the heads up!

Is that refactor going to replace the need to do a deepcopy when sending points to outputs?

[sparrc]

yep 👍

[jipperinbham]

nice! I had toyed around with using a channel to send the points back when adding the outputs so very happy to see this happening.

[sparrc]

@justin8 Has this case been fixed by PR #312?

[sparrc]

closing as fixed, please feel free to re-open if there are still issues