Elastic Agent - State persistence in Docker

Elastic Stack Beats
,
1

Hi, I am looking for best practice guidance when running the Elastic Agent and integrations in Docker containers. I have no issues getting them running (the documentation needs a bit of love as there are some inconsistencies around available environment variables etc), but I want to know what is the recommendation for persisting state, particularly with Fleet Server. Currently every time the container is destroyed and recreated an agent/fleet server registers. What paths within the container should I be looking to bind mount out to ensure state is persisted across container recreation / restart?

My current thought based on poking around the container is /usr/share/elastic-agent/state. From what I can tell this should give me the state information, as well as the logs. However I can see that when integrations are added, they are added under /usr/share/elastic-agent/data...

I have been unable to find any documentation regarding this. If the recommendation is NOT to persist state and treat them like a stateless agent, that is OK, but it is something that we will need to be aware of as every time we restart the agent we will end up with orphan agents listed in Fleet which will need to be cleaned up.

Thanks.

2

A while ago I asked this, and the answer was:

For the persistence: Both ways should work. There is one issue we are currently working on for the fresh enrollment each time: The list of Elastic Agent in Fleet keeps getting longer and is not automatically cleaned up. The concept we have in mind to solve this is ephemeral agents which is agent which automatically are unenrolled after some time of inactivity.

Not sure if anything has changed since.

3

There is an unenroll_timeout which now can be set per policy: Set enrollment timeout for ephemeral hosts | Fleet and Elastic Agent Guide [7.17] | Elastic This should help in this scenario.