Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
ph opened this issue Apr 27, 2020 · 3 comments · Fixed by #18973
Closed

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

ph opened this issue Apr 27, 2020 · 3 comments · Fixed by #18973
Assignees
Labels
Ingest Management:beta1 Group issues for ingest management beta1 refactoring

Comments

@ph
Copy link
Contributor

ph commented Apr 27, 2020

The process should connect to the Elastic Agent and will periodically check the gRPC endpoint to receive actions to executes and will also report ACK to the Agent.

@ph ph added refactoring elastic-agent Ingest Management:beta1 Group issues for ingest management beta1 labels Apr 27, 2020
@elasticmachine
Copy link
Collaborator

Pinging @elastic/ingest-management (Team:Ingest Management)

@blakerouse
Copy link
Contributor

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.

@ruflin
Copy link
Contributor

ruflin commented May 12, 2020

+1 on getting the config through GRPC instead of file. But I assume we can split this up in two parts: First flip the GRCP connection and then introduce the config reading?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Ingest Management:beta1 Group issues for ingest management beta1 refactoring
Projects
None yet
4 participants