Felix Barnsteiner

I think ideally, all dynamic config options should be in Kibana. One thing that we have to ensure when adding something to central config is the consistency of the config...

I checked where we are in terms of alignment and there's just one option I found that's misaligned. There are a bunch of options that are currently only implemented for...

As this affects all agents at least in the way the default behaves, I have created implementation issues for all agents and I'm waiting two more days for objections.

I think agents should default to sending all three fields and if they detect that the APM Server they're connected to is new, they MAY drop the old field. But...

Ideally, I think the description and this discussion should happen on the spec PR. Otherwise, it may get out-of-sync.

I don't think that this is compatible with ECS: ```json { "tags": { "teams": ["team1","team2"] } } ``` Not sure about that version: ```json { "labels": { "teams": ["team1","team2"] }...

@ruflin Do you know about prior art regarding labels with multiple values? Is that something you'd consider legal from an ECS perspective?

Makes sense Mat. In APM, label values can be of type string, Boolean, or number. This allows, for example, to create graphs based on label values. Any plans to support...

FWIW, this is the `labels` definition form APM Server: https://github.com/elastic/apm-server/blob/2359a46408b558ae88d07dff3f4eb73618c2e0d2/_meta/fields.common.yml#L121-L131 Which gets converted to this dynamic template: ```json "dynamic_templates" : [ { "labels" : { "path_match" : "labels.*", "mapping" :...

When agents check the version of the APM Server there is no Breaking change. But for the RUM agent, that might not be possible.