[Fleet] added time_series_metric mapping for metric_type package field

[juliaElastic]

Summary

Closes #115621

Moved metric_type to time_series_metric mapping, removed from meta.

Example:

- name: total.norm.pct
  type: scaled_float
  metric_type: gauge
  unit: percent
  format: percent

Resulting mapping:

  "properties": {
    "total": {
      "properties": {
        "norm": {
          "properties": {
            "pct": {
              "scaling_factor": 1000,
              "type": "scaled_float",
              "meta": {
                "unit": "percent"
              },
              "time_series_metric": {
                "type": "gauge"
              }
            }
          }
        }
      }
    }

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[juliaElastic]

question: can metric_type just be removed from meta or does it need to be kept/migrated for BWC?

it looks like the change of adding time_series_metric causes errors when installing system or apm package:

 │ proc [kibana] [2022-02-24T13:30:17.599+01:00][ERROR][plugins.fleet] Error: Error installing system 1.11.0: illegal_argument_exception: [illegal_argument_exception] Reason: composable template [metrics-system.filesystem] template after composition with component templates [metrics-system.filesystem@settings, metrics-system.filesystem@custom, .fleet_component_template-1] is invalid
   │ proc [kibana]     at ensureInstalledPackage (/Users/juliabardi/kibana/kibana/x-pack/plugins/fleet/server/services/epm/packages/install.ts:129:11)

[jsoriano]

question: can metric_type just be removed from meta or does it need to be kept/migrated for BWC?

I don't know of anything using the meta field, but maybe we can keep it for some time just in case? On this comment #82273 (comment) @ruflin also seemed to prefer keeping both approaches during some time.

it looks like the change of adding time_series_metric causes errors when installing system or apm package:

Regarding the error, could it be that aggregations is mandatory when using the "object" format? In the examples in elastic/elasticsearch#74014, this format is only used when aggregations is also present.

Maybe we have to use this format when there are no aggregations as is the case now:

              "time_series_metric": "gauge"

@csoulios is it ok to set only the metric type without aggregations?

[juliaElastic]

Thanks, it works if I change to string like "time_series_metric": "gauge". If later we need to support aggregations, is it going to be possible to change from string to object?

[csoulios]

Currently, the time_series_metric field only supports a string value that can be any of the gauge, counter, histogram, summary. The object format is not currently supported.

I would like to ask which of the above values do you plan to use.

See elastic/elasticsearch#76766

[juliaElastic]

I'm not sure what are all the possible values of metric_type/time_series_metric, maybe @jsoriano knows?
It looks like the string format works, so we can go ahead with that, let me know if any concerns.

[jsoriano]

By now we only allow counter and gauge in packages.

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: f68d086
• Storybooks Preview
• Webpack Bundle Analyzer

Metrics [docs]

✅ unchanged

History

• 💔 Build #26132 failed 3679b56

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @juliaElastic

[nchaulet]

Code looks good 🚀

[juliaElastic]

manual test case here: #115621 (comment)