OTLP: store units in mappings

[felixbarny]

This is enabled by adding a new dynamic_templates_params option to the bulk request header. It can be used in combination with the dynamic_templates option to provide parameters that can be used within a dynamic template.

The dynamic template can control which parameters it accepts and can provide a default value in case clients don't provide the parameters in the bulk request. If no default value is provided, and the bulk request also doesn't specify the parameter, the value is kept as it is defined in the template (including braces).

For example, the dynamic template can define a unit placeholder.

{
  "dynamic_templates": [
    {
      "gauge_long": {
        "mapping": {
          "type": "long",
          "time_series_metric": "gauge",
          "meta": {
            "unit": "{{unit}}"
          }
        }
      }
    }
  ]
}

Clients can then set provide a value for the unit in the bulk request header like so:

{"create": {"dynamic_templates":{"metrics.system.memory.usage":"gauge_double"},"dynamic_template_params":{"metrics.system.memory.usage":{"unit": "By"}}}}
{"metrics": {"system.memory.usage": 42}}

Placeholders for which no parameters are specified will evaluate to an empty string.

---

I chose a {{placeholder}} syntax over {placeholder} to avoid ambiguity as {percent} is actually a literal value that we expect to use which is not meant to be interpreted as a placeholder. This is also consistent with the syntax we use in other places like ingest pipelines (mustache and reroute processor placeholders). However, at the moment, dynamic templates support some parameters with only a single pair of braces: {name} and {dynamic_type}. I've added support for specifying these in double braces as well to maintain consistency (while still supporting the single brace version). Interestingly, we've documented that we already support this syntax: https://www.elastic.co/docs/manage-data/data-store/mapping/dynamic-templates

Use the {{name}} and {{dynamic_type}} template variables in the mapping specification as placeholders.

However, it's not actually true (yet).

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[elasticsearchmachine]

Hi @felixbarny, I've created a changelog YAML for you.

[felixbarny]

We could use a similar mechanism to store the metric description.
However, the meta field imposes limits on the number and size of the entries:

Field metadata enforces at most 5 entries, that keys have a length that is less than or equal to 20, and that values are strings whose length is less than or equal to 50.

For units, this shouldn't be a concern. For descriptions, we could just truncate the description if it is larger than 50. But I heard there's desire to drop or increase the limit for meta. I'd be glad to get pointers for this if anyone has more information on that.

[kkrik-es]

It looks reasonable to me. Do we have any performance numbers, wrt impact to ingest throughput? It's noisy, but may be worth an adhoc run to verify that it's not overly slow.

[felixbarny]

Not yet, but it's on my list.

[felixbarny]

Based on the results of an ad-hoc run (environment ci-comp-bench-all-bahkm), there's no regression for the ingestion throughput.

[kkrik-es]

@martijnvg do you know who owns this? Do we need another team to review dynamic template changes?

[romseygeek]

LGTM!