[Fleet] added missing package field mappings

[juliaElastic]

Summary

Added field mappings for:

• doc_values: false value
• multi_fields: match_only_text type

Original issue: elastic/elastic-package#678

Related discussion: elastic/elastic-package#752 (comment)

Checklist

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

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[nchaulet]

Looks good to me 🚀

[kibana-ci]

💚 Build Succeeded

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

Metrics [docs]

✅ unchanged

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

cc @juliaElastic

[jsoriano]

LGTM, only wondering if we should also set ignore_above for match_only_text.

[joshdover]

@juliaElastic is there a way to test this yet with an existing package? If not, maybe we should remove the QA validation labels.

[juliaElastic]

@joshdover I saw here that Windows integration uses a multi_field, but I'm getting an error when trying to install it on latest master:

Error installing windows 1.10.0: mapper_parsing_exception: [mapper_parsing_exception] Reason: Failed to parse mapping: analyzer [powershell_script_analyzer] has not been configured in mappings

[joshdover]

@juliaElastic That error should have been fixed by #128498, have you pulled latest main?

[juliaElastic]

@joshdover you're right, I forgot to pull locally. Now I can successfully install Windows integration.
however, I'm not seeing match_only_text under command_line mapping here: http://localhost:5620/app/management/data/index_management/templates/logs-windows.sysmon_operational

[joshdover]

however, I'm not seeing match_only_text under command_line mapping here:

I believe the "Mappings" tab on that flyout only shows the mappings defined in the base index template. Since we've moved the mappings to the @package component template, you'll need to look there instead. Should be something like http://localhost:5601/app/management/data/index_management/component_templates/logs-windows.sysmon_operational%40package

[juliaElastic]

I'm checking in the Preview tab where all mappings are there.

EDIT: I checked what is actually coming from the package fields, and there is no multi_field specified, so that is why it is not there in mappings either.

 proc [kibana] {
 proc [kibana]   "name": "process",
 proc [kibana]   "type": "group",
 proc [kibana]   "fields": [
 proc [kibana]     {
 proc [kibana]       "description": "Full command line that started the process, including the absolute path to the executable, and all arguments.\nSome arguments may be filtered to protect sensitive information.",
 proc [kibana]       "name": "command_line",
 proc [kibana]       "type": "wildcard"
 proc [kibana]     },

@jsoriano do you know a package to test the new type of multi_fields with? I tried with Windows package, but it doesn't seem to have that field.

[jsoriano]

@jsoriano do you know a package to test the new type of multi_fields with? I tried with Windows package, but it doesn't seem to have that field.

elastic-package didn't support importing multi_fields from ECS till elastic/elastic-package#678, that is still not used in the integrations repo (coming in elastic/integrations#2916). So packages don't have multi-fields on ECS fields yet, this is probably the case of the Windows package.

There are though some packages that have multi_fields on their own fields, for example aws, mimecast, osquery_manager or synthetics. And some others have them too in their "agent" fields, but these fields may not be used as were added on bulk.

[juliaElastic]

@joshdover I think we can remove the QA labels, as there is no package with these specific fields (multi_fields/match_only_text type or doc_values)

[amolnater-qasource]

Hi @juliaElastic
As per your comment shared at #128391 (comment), could you please confirm if any testing is required on this from our end?

cc: @joshdover
Thanks

[juliaElastic]

@amolnater-qasource I think no testing is needed, thanks.

[amolnater-qasource]

Thanks @juliaElastic
We will be removing QA: Ready for testing label from this issue.