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: Reduce Binary Size by excluding Plugins #9556

Closed
theatischbein opened this issue Jul 29, 2021 · 7 comments · Fixed by #11524
Closed

Build: Reduce Binary Size by excluding Plugins #9556

theatischbein opened this issue Jul 29, 2021 · 7 comments · Fixed by #11524
Labels
feature request Requests for new plugin and for new features to existing plugins

Comments

@theatischbein
Copy link

Hi,
I'm trying to build small telegraf binary versions for using them on embeded systems like routers with only less memory.

Because I didn't found a way in the Makefile to exclude plugins, I uncomment them in plugins/{input,output}/all/all.go.
I managed to reduce size to 75MB.
Than I started to look at plugins/processors/all/all.go but wasn't sure what is safe to exclude here.

My questions are:

  • Is that desired way to exlcude plugins or is there another (better) one ?
  • Do you know any other things that can be left out safely ?

Thanks in advance!

@theatischbein theatischbein added the support Telegraf questions, may be directed to community site or slack label Jul 29, 2021
@telegraf-tiger
Copy link
Contributor

Hello! I recommend posting this question in our Community Slack or Community Page, we have a lot of talented community members there who could help answer your question more quickly.
Heads up, this issue will be automatically closed after 7 days of inactivity. Thank you!

@sspaink sspaink added feature request Requests for new plugin and for new features to existing plugins and removed support Telegraf questions, may be directed to community site or slack labels Jul 29, 2021
@sspaink sspaink self-assigned this Jul 29, 2021
@sspaink
Copy link
Contributor

sspaink commented Jul 29, 2021

As you noticed, there isn't a way to build Telegraf with a subset of plugins with the makefile at the moment. I do think this would be a good feature to have so I've added the feature request label to this issue to research how we'd want to do this.

Commenting out the plugins as you did in the all.go files seems like a good approach in the meantime. Be sure to build without the debug symbols as well by passing the following flag -ldflags "-s -w", should help reduce the size if you haven't already. I don't have any other suggestions what could be excluded safely at the moment.

@theatischbein
Copy link
Author

Thanks for your reply! I managed to further reduce the size to 34M and 16M without any plugins. It is still too much but I guess there is nothing else I can do now.

@russorat
Copy link
Contributor

do you mind sharing what device you are trying to load telegraf on?

@theatischbein
Copy link
Author

I'm developing currently on the raspberry pi 3 model B, where I do not have any memory restrictions, but I would love to run telegraf on our other routers, which are mostly TP-Link Archer C7 AC1750 v2 with about 16M flash memory.
I guess we still have some TP-Link WDR3600 with only 8M, but I guess that will never be possible.

Btw. I found the tool upx and could achieve a 6M binary (with excluded debug symbols and plugins), but it might not be possible with the compressed squashfs. I will need to test that. I linked some sources in the openwrt forum if you are interessted.

zexi added a commit to yunionio/telegraf that referenced this issue Aug 12, 2021
@phemmer
Copy link
Contributor

phemmer commented Aug 19, 2021

#9615 is similar to this one

See also #9649, which is a proposal for a new external plugin API which would allow externalizing all these built-in plugins.

@wz2b
Copy link

wz2b commented Sep 3, 2021

In addition to code space they also contribute to more stuff in the sample configuration file. That's lines of text 99% of people don't need so IMO it's just noise. I think that's another reason to migrate these out by externalizing them over time. If you decide that it isn't worth doing this right now that's probably fine, but if there are any changes to these seldom-used plugins then encouraging them to go external is something I definitely support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Requests for new plugin and for new features to existing plugins
Projects
None yet
5 participants