[Agent][Discuss] Agent's binary size

[ph]

Is the size of the Agent too bigs or good enough? Looking at the current binaries they use the following resources on disk:

• Agent unstripped 21M
• Agent stripped debug symbols 15.4M

If we compare that to existing beats:

• Filebeat 58M
• Metricbeat 85M

Simple Golang hello world

• 2M

Tasks to make it smaller:

• We are bundling a few YAML files directly into the binaries but we don't actually compress the content, but that should not make a significant impact on the resulting binaries
• Inputs v2 and custom binaries for sidecars.

[ph]

@dferullo-elastic @scunningham I don't think its a big issue with these kinds of size. The only problematic part might be sidecars. We have a plan by @urso in motion to refactor the inputs used by both Metricbeat and Filebeat this will give us more flexibility at how we can generate binaries. We don't have a time when this will land but we we have a possible solution to investigate.

In short, this refactor will open the possibility of creating a custom version of the beats with only the minimum required library to works, if you look at the details of the size the majority of the increase with our beats comes with our bundled libraries (Docker and k8s) so removing them when not need will reduce the binary.

Something like this:

filebeat-sidecar: Only support the Log input and the Elasticsearch output.
Metricbeat-sidecar: Only support the Beat modules and the Elasticsearch output.

At the moment we can only build the whole kitchen instead of just repairing the sink.

[andrewkroh]

I tested out UPX in #12768 (comment) and it drastically lowered the binary sizes. So that might be something to consider applying.

[ph]

@andrewkroh Yes I was looking into that, but @urso said it might not work when the process need to be protected.

[andrewkroh]

With respect to Windows Anti-Malware protection for the service, I think the requirement is for the the user-mode binary to be signed. And I think that would still be possible.

But there are probably several other issues that upx would introduce and it probably is not be worth it for a small trade-off in size.

[ph]

@andrewkroh yes exactly, I would prefer to not introduce more unknown to the mix.

[scunningham]

The primary concern is on the wire size; Ie. how much bandwidth is required to distributed/upgrade the fleet agent. We should definitely provide a compressed (probably .zip) package that would mitigate much of the concern. Clearly, a smaller executable would be better, but .zip does pretty well.

The other issue is around mapping the executable in to RAM on the endpoint itself. A smaller footprint would boot faster and allocate fewer VM pages. At the end of the day, there's not much performance difference. It's largely a perception issue. We wouldn't want to use packers such as UPX because then we look like malware to other security tools.

[ph]

The primary concern is on the wire size; Ie. how much bandwidth is required to distributed/upgrade the fleet agent. We should definitely provide a compressed (probably .zip) package that would mitigate much of the concern. Clearly, a smaller executable would be better, but .zip does pretty well.

We already do that at the moment, I think we can keep what we have today and improve the situation for sidecars in short term release / update.

[ph]

Closing this one.