I'm not quite sure if tags is the right field for this. Isn't it common that tags is just a simple list instead of key-value pairs? I would set a different field or make it configureable.

The field tags as a dictionary was used because the influxdb-writer is also using it that way.
The functionality would stay the same with a different field name so if you have a preference I could change it accordingly.
(labels would come to mind as a alternative.)

I gave it some thought and I could also simply allow tags to be of type array. (in addition to dict)
That would change some of the logic we had reviewed until now but if that would be preferred by you, I could also implement it that way.

Isn't it common that tags is just a simple list instead of key-value pairs?

I'm afraid, in perfdata DB context, they indeed are key-value pairs:

• https://docs.influxdata.com/influxdb/v1/concepts/glossary/#tag-key
• https://graphite.readthedocs.io/en/latest/tags.html

I'm afraid, in perfdata DB context, they indeed are key-value pairs:

Please show me where we set a field called tags in one of them. Supporting tags in both just means adding key-value pairs, with no reference to a tags field, right?. But here we set the field where I wonder if users of Elasticsearch or similar would expect a list rather than key-value pairs. tag_set sounds more reasonable to me. Anyway, before we just merge this, I'd like to get an informed opinion.

For Icingas influxdbcommonwriter this is done here:
https://github.com/Icinga/icinga2/blob/master/lib/perfdata/influxdbcommonwriter.cpp#L253

But tags never reaches Influx DB.

The graphite writer does only allow to configure templates for the host and service name.

Otherwise there would not be a tags field either.

Found it as well just after Commenting. 🙈
That was my bad.
I'm very sorry for the confusion.

To prevent confusion about the Type of tags, would you prefer to:

• Rename the field to tag_set or
• Add the configured key-values directly into the elasticSearch-Entries as done in the influxdb case?

To prevent confusion about the Type of tags, would you prefer to:

• Rename the field to tag_set or

I think a tag_set property would be rather confusing in ES/Kibana.

• Add the configured key-values directly into the elasticSearch-Entries as done in the influxdb case?

This, in contrast, has the advantages:

• No tags. boilerplate in our ES data
• Consistency with InfluxDB

After my changes the configured tags are now added to the root element.
That also allows for tags = ["foo", "bar"] if desired.

Notice:
Since the templated_tags are added after the default fields and the performance Values this change will also allow to overwrite them.

Isn't it common that tags is just a simple list instead of key-value pairs?

I'm afraid, in perfdata DB context, they indeed are key-value pairs:

• https://docs.influxdata.com/influxdb/v1/concepts/glossary/#tag-key
• https://graphite.readthedocs.io/en/latest/tags.html