Extend local_meta information for elastic agent

[shahzad31]

Each registered agent in the fleet contains information about it's local meta

For synthetics, we ask user to use elastic-agent-complete variant which also contains browser dependencies. From synthetics plugin in kibana, we would like to determine if the agent registered is complete or not and hence warn user if they are trying to run browser monitor on simple elastic agent.

For that we need that information in the local_meta of the agent. So when user installs an agent and if its an elastic-agent-complete docker image https://hub.docker.com/r/elastic/elastic-agent-complete, we should add a flag saying. Its an es agent complete. So that we can consume that info in kibana.

[ph]

This seems really close to what we added #1350, I think all the necessary plumbing logic is present in fleet-server and elastic-agent to populate the data. it's a matter of exposing it to the enroll cli. This would benefit from having @nimarezainia looking at it.

We could use a flag, but I think it's more powerful to allow users to set arbitrarykey=value

See the discussion in elastic/elastic-agent#149

[shahzad31]

so this will not a user action, we want this boolean to auto added based on the docker image being used.

[ph]

I see in this case, it could be added automatically when the elastic agent is run with the container subcommand.

[shahzad31]

@ph any updates on prioritising this issue?

[cmacknz]

We don't have this on our priority list, you'll want to get in touch with @pierrehilbert about getting this prioritized.

[nimarezainia]

@shahzad31 @cmacknz I am wondering whether it serves us better in the future if we have some sort of a capabilities list? instead of a boolean? a list that can be parsed, for example synthetics can parse for some value they have an interest in etc

I can't immediately think of other use cases but feel that it would serve us better in the future to allow platform users to utilize these advertised capabilities.

[shahzad31]

@nimarezainia that will work as well.

[shahzad31]

@nimarezainia any update on this?

[nimarezainia]

@shahzad31 I'm sorry we are currently completely drained for capacity and are mainly concentrating our efforts on stability of software and only some of the highest priority features. Feel free to create a PR that @pierrehilbert or @cmacknz could review for you if it's a small change.

[emilioalvap]

Hi @cmacknz,

We are looking into contributing to this ourselves, would adding the contents of capabilities.yml to the agent metadata be an appropriate compromise here?

[cmacknz]

Capabilities.yml isn't widely used enough that it would be worth including by default in the agent metadata. We use it in our own cloud to lock down the agent that runs Fleet Server, but that is pretty much the only major use of it that I know of.

This feels like something that can just be a boolean flag under local_metadata.elastic.agent, possibly as simple as local_metadata.elastic.agent.complete: true for example.

We are considering building a lighter weight version of the non-containerized agent, the current default would effectively be the complete version with all binaries included. So this flag would work there too to allow us to distinguish the builds.

[cmacknz]

The current contents of local_metadata.elastic.agent for reference:

  "local_metadata": {
    "elastic": {
      "agent": {
        "build.original": "8.8.2 (build: cdc5ba9b1d2c90fdfd0e998e3e744e46a225c313 at 2023-06-26 16:18:13 +0000 UTC)",
        "id": "a65dd572-d5bb-4b91-b1ac-6781e5e840f5",
        "log_level": "info",
        "snapshot": false,
        "upgradeable": true,
        "version": "8.8.2"
      }
    },

[awahab07]

Post FF Testing

Tested 8.10.0-Snapshot and it LGTM!

docker.elastic.co/beats/elastic-agent:8.10.0-SNAPSHOT	docker.elastic.co/beats/elastic-agent-complete:8.10.0-SNAPSHOT