elastic / elastic/package-spec

[Change Proposal] Introduce an "Agent Common Schema"

Open
#441 4 comments 0 reactions 0 assignees View on GitHub
discuss Team:Ecosystem
Dominant language
Go
Stars
20
Forks
93
Avg merge
15h 10m
Merged PRs (30d)
12

Description

_This issue is a follow up of the discussions in https://github.com/elastic/integrations/issues/4236 and https://github.com/elastic/package-spec/issues/199_

We need a source of truth for the mappings of the fields added by data providers, mainly for Elastic Agent and the processors it includes. These mappings will be used by any feature that gets these fields populated. It could be mappings in package definitions, or Fleet when installing index templates for specific policies.

The proposal would be to **create a new repository**, called `elastic-agent-common-schema`, that includes the mappings in paths like `//fields.yml`. So for example the mappings for the `add_host_metadata` processor of beats can be defined in `beats/add_host_metadata/fields.yml`.

Each one of these fields definitions would use the format of ECS flat fields (such as [these files](https://github.com/elastic/ecs/blob/8.4/generated/ecs/ecs_flat.yml)), and could be generated from other smaller files if needed, using ECS tooling. Alternatively, the format for fields in the package spec could be used, that is similar.

Its versioning should be aligned with Elastic Agent versioning.

Use cases
---

* Allow `elastic-package` to import definitions in packages in build time, similar to the `external` fields, but for groups of packages.
* Allow Fleet to add mappings for fields of custom processors.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.