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

Build-time feature configuration to reduce binary size #2267

Open
sysvinit opened this issue Dec 12, 2024 · 1 comment
Open

Build-time feature configuration to reduce binary size #2267

sysvinit opened this issue Dec 12, 2024 · 1 comment
Labels
enhancement New feature or request proposal A proposal for new functionality.

Comments

@sysvinit
Copy link

Request

The option to customise which integrations are included in Alloy at compile-time, so integrations which aren't needed (e.g. Prometheus exporters) can be excluded in order to reduce the binary size.

Use case

I would like to use Alloy as a log-shipping client as a drop-in replacement for promtail, as promtail has been declared feature complete and there are some log-shipping features which are only available in Alloy. I'm not currently interested in using any of the metrics or tracing features of Alloy, as I use other tools for metrics collection. However, my Alloy binary is 285MB in size, which is a significant commitment in disk space on the relatively small VMs I work with -- the Alloy binary alone is nearly a full percent of available disk space in the default 30GB VM disk image in my environment.

See also the Discourse post I made on this topic: https://community.grafana.com/t/disable-features-at-build-time-to-reduce-binary-size/138203

@sysvinit sysvinit added the enhancement New feature or request label Dec 12, 2024
@wildum wildum added the proposal A proposal for new functionality. label Dec 12, 2024
@jkroepke
Copy link
Contributor

In context of the binary size, I would recommend to take an look at UPX first. It's the de-facto tool for compress binaries and supported on from goreleaser as well.

That might be resolve the issue without refactor something.

A side from that, offer build-time features increases the complexity on mass. From maintainer point of you, you habe to ask always which build flags are set. On top, test various build time flag combination increases the support effort on grafana side to the max. The usage would be very low.

From my point of view, I feel a modularized approach would be a better one. Going away from a mono binary approach to plugin based approach where is communication is done via RPC. The concept is already used in the Grafana eco system, with Grafana Backend Plugins. Multiple OTel collectors could be sorted out to an plugin.

By offer a plugin interface, community driven plugins could enrich the alloy eco system. I personally like to core power of alloy, but sometimes it's lacking some features and integrate more and more exporter make the complete product more fat.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request proposal A proposal for new functionality.
Projects
Status: Incoming
Development

No branches or pull requests

3 participants