I think with the flip of the GRPC connection we might want to tell beats that will run as services to connect to Agent to get their configuration instead of just reading the full configuration from disk.

Think of the case when agent is running inside of Kubernetes (going to use this is the primary example but really could be applied with Docker or any orchestration service) and agent needs to spawn a new container to start monitoring a new integration. At the moment with Kubernetes that means it needs to create a ConfigMap and then a Deployment using that ConfigMap. Then if the configuration needs to be updated then it has to update the ConfigMap and delete the Pod for the Deployment so a new one is created using the new ConfigMap.

But if we change it to where beats connects to agent on start using GRPC to fetch the configuration it wouldn't need to do that. Agent would create a Deployment without a ConfigMap using environment variables to tell it to talk back to Agent. Then the beats will request over GRPC the configuration and start running with that configuration. In the case that the configuration changes using GRPC the beat could be notified by Agent with the new configuration. No Pod needs to restart and no ConfigMap needs to be updated.

This is also useful with #18362 where each beat is ran through the service manager. This will ensure that a beat will not start without Agent up and running on a reboot. In the case of linux this is not a big deal because /run/systemd/system should be used to place the unit files, which do not persist on reboot. But on Mac and Windows, if a machine is off, and the Agent was removed from Fleet, then on reboot those services should not actually start anymore. Having this block on the beats that Agent spawns will allow this ability.

[Elastic Agent] Beats Connect to the Elastic Agent. #18024

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions