[Usage collection] kibana config usage report arrays of objects

[Bamieh]

We have a very few configs schemas with arrays of objects. Such as:

map:
  regionmap:
    layers:
      - name: "Australian States"
        url: "http://localhost:8000/aus_state.geojson"
        attribution: "https://exploratory.io/maps"
        fields:
            - name: "STATE_NAME"
              description: "State Name"

Currently we are reporting [redacted] if the arrayOf<object> config is set by the user.

map.regionmap.layers: '[redacted]'

We opted in for this behavior as it is unclear how we'd be indexing/searching these arrays of objects. Kibana and ES do not make it easy to aggregate and visualize arrays of objects.

To improve the current status for these configs we have a few options:

1. Keep reporting as [redacted]. Advise teams to manually expose these configs in their collectors rather than relying on the automatic kibana_config_usage collector if they need extra intel.

2. report each property in the config as an array of keys

map.regionmap.layers.name: ['Australian States']
map.regionmap.layers.url: ['[redacted]']
map.regionmap.layers.attribution: ['[redacted]']
map.regionmap.layers.fields.name: ['STATE_NAME']
map.regionmap.layers.fields.description: ['State Name']

3. Report config as a flattened array

map.regionmap.layers.0.name: ['Australian States']
map.regionmap.layers.0.url: ['[redacted]']
map.regionmap.layers.0.attribution: ['[redacted]']
map.regionmap.layers.0.fields.0.name: ['STATE_NAME']
map.regionmap.layers.0.fields.0.description: ['State Name']

4. Report the config as is

map.regionmap.layers: [{
   name: 'Australian States',
   url: '[redacted]',
   attribution: '[redacted]',
   fields: [
      { name: 'STATE_NAME', description: 'State Name' },
   ]
}

For options 2-4 we need to check how these data shapes would affect aggregations and visualizations.

Teams affected by this (cc @elastic/kibana-security @elastic/kibana-gis )

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[elasticmachine]

Pinging @elastic/kibana-telemetry (Team:KibanaTelemetry)

[legrego]

@elastic/kibana-security is already providing a more understandable report of our array-based settings, so from our perspective it's safe to omit these altogether from the generic usage report (option 1 as outlined above)

[Bamieh]

@chrisronline can you please list the array of objects configurations you want to report the value of. Is it possible to add those to a usage collector for now similar to how kibana-security is doing?

[chrisronline]

Sure.

xpack.actions.customHostSettings.tls.rejectUnauthorized is deprecated in favor of xpack.actions.customHostSettings.tls.verificationMode. We need to collect telemetry on it's usage to know when we can remove it but since the field is an array, we can't automatically hook into the usage counter telemetry. We could tack it onto our normal telemetry but it'd be nice if all deprecated configs existed in the part of the telemetry document to make it easier to visualize