elastic/beats: Lightweight Shippers for the Elastic Stack

What problem Beats solves, and who ends up installing it

Beats exists for one job: put an agent on a host and get that host's operational data into Elasticsearch, directly or through Logstash, so Kibana can visualize it. The README describes the family as "lightweight data shippers, written in Go", and defines lightweight in three concrete ways: a small installation footprint, limited system resource use, and no runtime dependencies. That last property is the one that matters operationally. A shipper with no runtime dependencies does not need a JVM or an interpreter on the box it monitors, which is why Beats is often chosen for edge hosts and appliances where installing a runtime is unwelcome.

The audience is narrower than the project name suggests. The repository ships one framework, libbeat, plus seven officially supported Beats, each aimed at a different data source rather than a different kind of user. Filebeat tails and ships log files. Metricbeat fetches sets of metrics from the operating system and services. Packetbeat sniffs packets to monitor the network and applications. Heartbeat pings remote services for availability. Auditbeat collects Linux audit framework data and monitors file integrity. Winlogbeat fetches and ships Windows Event logs. Osquerybeat runs Osquery and manages interaction with it, and lives under x-pack rather than at the repository root.

So the decision is rarely "should we use Beats" in the abstract. It is "which Beat covers this data source, and is that Beat in the supported list". If your source is not one of those six data types, the README points to community Beats maintained outside this repository, and to libbeat for building your own. That is the real boundary of the project.

How libbeat, the module path and the build tree fit together

The architecture visible in the repository is a shared framework with per-Beat binaries on top. libbeat is the Go framework for creating Beats; the seven supported Beats are separate top-level directories that depend on it. The Go module path is github.com/elastic/beats/v7, and go.mod declares go 1.26.8, so the toolchain expectation is a recent Go release rather than the oldest one that compiles.

Each Beat carries its own configuration, and the data flow is the same shape in all of them: the Beat reads from a source (a file, a metrics endpoint, a network interface, a Windows event channel), applies processing, and publishes to a configured output. The README states the destination plainly: Beats send operational data to Elasticsearch, either directly or via Logstash. There is no third output family described in the README, which is the single most important architectural fact for anyone evaluating this against a multi-vendor pipeline.

The build system is worth understanding before you clone anything, because it is not a single `go build`. The Makefile sets BEATS to a list that includes both the open-source Beats and their x-pack counterparts (x-pack/filebeat, x-pack/metricbeat, x-pack/dockerlogbeat, x-pack/osquerybeat and others), and defines PROJECTS as libbeat plus x-pack/libbeat plus that list. Two variables in the Makefile explain the current state of the tree: PROJECTS_XPACK_PKG marks Beats with independent packaging support in x-pack, with a comment saying this will be removed once the transition completes, and PROJECTS_XPACK_MAGE marks Beats whose primary build logic is based in Mage, supporting only a subset of Makefile targets for CI compatibility. If you plan to build from source, expect a tree mid-migration between two build paths, not one clean entry point.

Installing Beats and shipping your first log file

The README does not give install commands. It points to the downloads page at elastic.co/downloads/beats for pre-compiled binaries and platform packages, and to the per-Beat getting started guides on the elastic.co site for each Beat. That is the supported path: download the package for your platform rather than build it, unless you are developing a Beat of your own.

Once a Beat is installed, the workflow is configuration plus run. The README does not reproduce a config file, so the exact keys for your Beat come from its getting started guide. What the repository does show is how the project itself is built from source, and the Makefile is the entry point for that:

make

The Makefile defines BEATS as the list of Beats the root-level build covers, including auditbeat, filebeat, heartbeat, metricbeat, packetbeat, winlogbeat and their x-pack counterparts. To build a single Beat rather than the whole set, the Makefile exposes BEATS as an overridable variable, so you pass the subset you want on the command line. Confirm the target name against the getting started guide for the Beat you installed before running anything in production.

For the x-pack Beats, the packaging note in the Makefile matters: x-pack/auditbeat, x-pack/dockerlogbeat, x-pack/filebeat, x-pack/heartbeat, x-pack/metricbeat, x-pack/packetbeat and x-pack/winlogbeat have independent packaging support, so their artifacts are not simply the open-source build with a flag flipped. If you are scripting an install, take the package from the downloads page for the edition you intend to run rather than assuming one artifact covers both.

Where Beats is the wrong tool

The clearest limitation is the output side. The README describes Elasticsearch and Logstash as the destinations, and nothing else. If your organization standardizes on a different backend, Beats is not a neutral shipper you can retarget with a config change; you would be adopting the Elastic Stack's ingestion path along with the agent. That is a fine decision if you have made it deliberately, and a costly one if you have not.

A second constraint is the data-source list. Seven supported Beats, each covering a specific category. If your telemetry does not fit logs, system and service metrics, network packets, endpoint availability, Linux audit and file integrity, Windows event logs, or Osquery, the README directs you to community Beats outside this repository or to libbeat. Community Beats are not covered by the support statement for the officially supported set, and the README does not describe their maintenance. Treat that as a real difference in support, not a formality.

There is also the question of what "lightweight" buys you. No runtime dependencies and a small footprint are properties of the agent, not of the pipeline behind it. The README makes no claim about throughput, backpressure behavior, or what happens when the output is unavailable, and it does not document rollback or version-skew handling. If your adoption decision depends on those behaviors, the README is silent and you need the per-Beat documentation to answer them. Do not read the word lightweight as a performance guarantee.

Beats compared with the Elastic Agent, and with a collector you already run

The README itself introduces the most relevant alternative. It has a separate section for the Elastic Agent, pointing to elastic.co/downloads/elastic-agent, alongside the per-Beat guides. That is the meaningful comparison inside the same ecosystem: Beats are individual shippers you install and configure per host, while the Agent is presented as its own product with its own getting started path. The README does not describe how the two relate operationally, so the honest reading is that the project documents both and leaves the choice to you. If you want one agent to manage, the Agent is the thing the README tells you to look at; if you want one process per data type with an explicit config file, that is the Beats model.

Outside Elastic, the usual comparison is a general-purpose collector that fans out to multiple backends. The difference is not quality, it is direction. Beats is built around a single ingestion path into Elasticsearch or Logstash, which is why the config surface is small and the agent has no runtime dependencies. A multi-backend collector is built around routing, which is why it carries more configuration and more moving parts. Choosing Beats and then bolting on a second pipeline to reach a non-Elastic destination gives you the costs of both approaches and the benefits of neither.

There is one more comparison worth naming: libbeat itself. If the existing Beats do not cover your source, the README offers libbeat as the framework for creating your own Beat. That is a real option, and it is also a commitment to maintaining a Go codebase against a module whose go.mod requires go 1.26.8. Weigh that against writing an exporter for a collector you already operate.

Maintenance, licensing and what a version upgrade costs

The repository is not archived, and its last push was on 2026-09-21. Releases are frequent and come in maintained lines: v9.5.4 and v9.4.7 were both published on 2026-09-15, with v9.5.3 on 2026-09-03. Two patch releases on the same day across a current and a previous minor line is the pattern you want to see if you are pinning versions, because it means a fix landing in 9.5 is also being carried back to 9.4.

Licensing needs care here. The repository's license field is NOASSERTION, and the tree contains a LICENSE.txt, a NOTICE.txt and a licenses/ directory, plus an x-pack/ directory holding Beats such as x-pack/filebeat and x-pack/osquerybeat. The README describes those as officially supported by Elastic, but it does not state license terms for any part of the tree. The practical implication is that you cannot infer the license from the repository metadata, and the split between the root Beats and x-pack means the answer may not be uniform across the components you deploy. Read LICENSE.txt and the licenses/ directory yourself, and get your own legal review; nothing in the README substitutes for that.

On upgrade cost, the repository supports one concrete observation and no more. The Makefile shows the build tree in transition, with PROJECTS_XPACK_MAGE described as a temporary compatibility list and PROJECTS_XPACK_PKG marked for removal once the transition completes. That affects people building from source, not people installing packages. The README does not document rollback, downgrade paths, or config compatibility between minor versions, so a version bump is something to plan against the per-Beat documentation rather than against this repository's README.

Editorial conclusion

Adopt Beats if your logs and metrics already land in Elasticsearch or Logstash and you want a small per-host agent with no runtime dependencies, built from the libbeat framework in this repository. Do not adopt it as a general-purpose telemetry pipeline for a non-Elastic backend, and do not treat it as a replacement for a collector that must fan out to many vendors. Before deploying, verify two things: which version the release notes cover (v9.5.4 and v9.4.7 were published on 2026-09-15) and whether the specific Beat you need is in the supported list in the README, since community Beats live outside this repository.

Frequently asked questions

Official sources

1. elastic/beats on GitHub
2. Issues
3. Project website
4. README
5. Releases