[Feature request] Add some small things to make output plugin writing easier

[gena01]

So I've been hacking on a little output plugin and I noticed a few things:

• metrics in telegraf don't have types (internally). Various Input plugins can inject various types, but those are not saved internally.
• When sending points to some external services which do have various supported types (gauge, counter, cumulative_counter, etc..) you have to either pick one like "gauge" as default or figure out some sort of complex configuration to map metrics to proper types. (I guess InfluxDb doesn't have types either?) Is it possible to somehow add this in?
• "points" are not documented. Took me some time to figure out what they actually contain.
• "tags" which are attached to points seem to be on only one level. One possible scenario I am running into is that "host" level tags like: "host", "dc", etc... are listed on the same level as lets say "diskio" tags. Ideally I'd like to separate those out into two separate buckets, but this is not an easy task since I can't easily tell which came from a plugin scope and which came from the global one. If i send those tags as is then the dataset gets somewhat polluted and it's harder to find what came from where on the graphics/analysis side. One thing i was thinking was to see if I can somehow tell the type of a tag and prefix those by a plugin name for my particular output plugin (or not prefix it for some default/global tags).

P.S. Let me know if I should split this up and how, and I'll try my best.

[sparrc]

@gena01

some thoughts:

• Re "types" metrics in Telegraf do have types, it is the influxdb client.Point type. This type is more low-level because it corresponds to an entry in a database. The types that you're referencing "gauge" and "counter" are specific metric types to prometheus and statsd and don't exist in the database. There are many systems that come up with their own special type of metrics, so it's not clear to me the benefit of Telegraf adopting these. IMO, it's better for Telegraf to keep it's types low-level, which allows for greater flexibility.
• Re "points" I agree that I should make an interface within Telegraf to wrap client.Point so that the available methods can be seen within the repo.
• Re "tags" I'm not sure I understand this use-case, Why do you need to know why tags came from plugin or global scope? The whole point of global tags is that they apply to each collected metric, why do you want them in a different scope from the plugin tags? From an InfluxDB perspective, each tag is relevant to the metric, global and plugin, so you can make queries like

SELECT usage_idle FROM cpu WHERE host='foo' AND cpu='cpu-total'

where cpu is a plugin tag and host is a global tag.

[gena01]

In regards to tags. That query looks like InfluxDb query and it might be fine there. The system I am pushing stats to everything is flat (one big bucket). There are no "metric" tables. There is no "FROM". Think of dumping everything into one influxdb "metric" table/metric. Then you can have the same "name" tag coming from multiple plugins potentially clashing the dataset and making filtering harder if tags is all you have.