Has there been any discussion regarding adding official arm64 support for Beats? I feel like this just makes sense since with IoT / sensor data collection you'd want some sort of "lightweight data shipper" to Elasticsearch. Currently, from what I understand, we would have to compile each Beat program ourselves for that architecture though, which makes it a pain to update sensors, especially with how often Elasticsearch updates.
Currently, we don't officially support arm as all the testing infrastructure is not in place (yet).
But is trivial to build Beats for this platform, something like this should work:
git checkout 6.4
PLATFORMS='+all linux/arm64' make release
You can find builds for arm64 and other platforms here:
The snapshot builds at https://s3-us-west-2.amazonaws.com/beats-package-snapshots/index.html?prefix= do not normally include linux/arm64, but I just started a special one-off build that will publish snapshot packages for arm64 in case you want to try them before investing time to build them from a release tag yourself. They will automatically be purged from S3 after two weeks.
Is there any plan to officially support it? My company is producing IoT sensors and would love to use Beats and Elasticsearch to monitor them, and our sensors (like many/most of them) are ARM.
I can tell you that Arch Linux ARM builds and provides Beats packages to users. You can see them at https://archlinuxarm.org/packages with a search term of "beat"
On my Espressobin:
$ uname -a Linux ns1 4.17.10-1-ARCH #1 SMP Thu Jul 26 19:21:20 MDT 2018 aarch64 GNU/Linux $ pacman -Ss | grep beat community/auditbeat 6.3.2-1 community/filebeat 6.3.2-1 [installed: 6.3.1-1] community/heartbeat-elastic 6.3.2-1 community/metricbeat 6.3.2-1 [installed: 6.3.1-1] community/packetbeat 6.3.2-1 [installed: 6.3.1-1]
You can see I haven't updated to the latest yet.
I'm trying to build it myself but I'm getting an error saying make failed when ruunning "make update". I can't find anything about this on Google though. Any ideas?
@adrisr We've been building beats using this method, but there are a ton of dependencies that we had to get through since it was not as simple as running these commands. We had to install docker, python-pip, mage, python-env, etc. Shouldn't the Makefile do this itself?
Yes, I overlooked all the dependencies in my post, sorry about that
I don't think installing those fits in the Makefile as the process is somewhat system dependent and probably requires admin credentials. Maybe mage should be installed automatically, but is not that easy for the rest.
mage is automatically installed from the
vendor/ dir by any of the targets that depend on it. You do need to have your
$GOPATH/bin included in your
PATH in order for the installed
mage to be found.
The admin creds isn't an issue. What is causing me problems is I'm trying to set up a CI pipeline in GitLab to build binaries we use, one of which is Beats. GitLab uses Docker for its CI, so I got to the point in my pipeline where it says it needs to run Docker, but it's already in a Docker container.
Any reason this is being built with some Docker and some non-Docker stuff? I would think (and I could be wrong) that either you'd want a full Docker build process where everything is containerized, or else something without Docker. It just makes it complicated for anyone else building this using CI since Docker-in-Docker doesn't seem ideal from a security perspective:
Docker-in-Docker works well, and is the recommended configuration, but it is not without its own challenges:
- By enabling
--docker-privileged, you are effectively disabling all of the security mechanisms of containers and exposing your host to privilege escalation which can lead to container breakout.
I'm still able to build Beats manually on my own machine, but can't figure out a way to do it in a CI job without running into issues trying to run Docker in Docker.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.