The size of elastic-agent continues to increase with every version:
8.8 1.7G
8.7 1.4G
8.6 1.2G
8.5 415M
1.7GB for this package size is way too big. We are looking at moving to elastic-agent but can't have over 2000 servers remade to support the increase in size needed? The beats are supposed to be lightweight. Currently Metricbeat and Filebeat installed together on a system only takes up 5.8M of space. Now that is lightweight, how can I explain to my customer that I need to expand from 5.8M to 1.7GB?
I thought the idea of elastic-agent is that what will be needed can be installed based on the policy assigned. Right now we are only using os-query with agent, wanted to eventually move our legacy beats over but in this basic configuration the size on disk is still 1.7G. I'm new to agent but I thought that was the reason for setting up a package registry and an artifact registry. These would be the places to hold all of the extras one may need, not including them in the base agent.
I want the smallest initial installation size possible. Then it should grow as I give more features to the agent.
Moving to Agent is moving away from a "lightweight" client to a bulky client. We want to move in this direction, but it seems elastic is going the wrong way here?
Just a small correction, this space is just for the /etc/filebeat and /etc/metricbeat, the binary for metricbeat is around 350 MB and the binary for filebeat is around 150 MB, so both would need 500 MB of disk space.
But I agree with you, Elastic Agent takes up too much space, I'm in a similar scenario and I'm already facing issues because of this.
Elastic choose to bundle everything in the Agent instead of download the components on demand if I understand correctly.
There is an issue about a lightweight Agent, but it doesn't seem that this will change much.
We are planning to use Elastic Agent to collect system logs and replace Wazuh, but Wazuh just needs 25 MB of space, and Elastic Agent needs 1.7 GB after install.
To be able to install it you may need more than twice of it because you need the tar.gz file, unpack it and the install will copy it to the /opt/Elastic path.
I have some VMs where the system disk is small by default because it is just for the OS, to be able to install it I will need to ask the infra team to increase the disk size, which can be a problem, it is very hard to justify that I may need 5 GB of free disk space on the root partition to install an agent.
Unfortunately Elastic Agent is not lightweight when we take the disk requirements in consideration
@leandrojmp You are correct, and I was actually just looking at our /etc/filebeat and /etc/metricbeat folders. Looking at what gets installed for version 8.9.0 in /usr/share (which includes the binaries) on our Linux boxes I do see larger sizes:
All together that takes up 361M. As you said us moving to Agent requires at least 5GB because you need double the space for upgrades. By default, our root partition which includes /usr/share is only 10GB. Elastic would need half.
The fact that we are required to setup a package repository for fleet to pull from should allow the created of a very lightweight agent that can be expanded by pulling what is needed by the desired configuration from the repository.
Yeah, I have the same case, hundreds of server where the root partition has only 10 GB because it is just for the OS, the Agent install itself on /opt/Elastic and you can't change it.
The solution in our case would be to expand the root partition, which will not be possible in many cases, or add another disk and mount just /opt/Elastic on it.
This will create a lot of attrition with the infra teams and block the use of the Elastic Agent in many cases.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.