Should I prefer beats or Elastic Agent for monitoring application deployed using docker stack and not kubernetes?

Question

I have an application up and running in set of docker containers (deployed using docker stack and not kubernetes). I want to do performance monitoring for this application. I am confused about whether I should go for beats or Elastic Agent.

This page says:

When Elastic Agent runs inside of a container, it cannot be upgraded through Fleet as it expects that the container itself is upgraded.

This page says:

Standalone mode  — All policies are applied to the Elastic Agent manually as a YAML file.

Q1. Does this mean that in standalone mode Elastic Agent is not "at all" managed by Fleet? Or some part of management

This page says:

Standalone Elastic Agents are manually configured and managed locally on the systems where they are installed. They are useful when you are not interested in centrally managing agents in Fleet, either due to your company’s security requirements, or because you prefer to use another configuration management system.

This page says:

To run an Elastic Agent in standalone mode, install the agent on each host you want to monitor and manually configure the agent locally on the system where it’s installed. You are responsible for managing and upgrading the agents.

Q2. Does this mean that for monitoring docker containers (deployed using docker stack and not kubernetes), there is no difference between between beats and Elastic agents in terms of "central" management? Only difference would be that I have to configure different beats separately, which is avoided with Elastic Agent?

Q3. What is preferrable in this case? Beats or Elastic Agent?

Answer 1

1. Standalone is not managed by fleet, the "it cannot be upgraded through Fleet" refers to upgrading the actual version of the elastic-agent, you can still update the agent polices.
2. Yes you would need to configure beats via a config file on the container where elastic agent can be setup with some env variables to enroll it in a policy, then that policy is centrally managed and updated via Kibana.
3. Both are valid but elastic agent allows updating the policy after the container is running via a central location and therefore would be my choice.