LoongCollector's benchmark table is the most useful and least believable part of the readme

The benchmark tables, read as claims rather than measurements

The readme publishes two tables comparing against three named log collectors, and the numbers are extraordinary enough to deserve scrutiny. On maximum throughput, single-line log handling is given at 546 megabytes per second for this agent against 36, 38 and 9 for the others. Multi-line handling is 238 against 24, 22 and 6. Regular expression parsing is 68 against 19 and 12, with the third listed as unsupported. The second table gives processor and memory cost at a fixed 10 megabytes per second of load, with this agent at just over three percent processor and about 29 megabytes of memory for simple lines, against figures between twelve and thirty-six percent for the others, and one listed as insufficient at that load. A footnote adds that the competitors saturate the processor at around 40 megabytes per second while this one scales linearly to the higher figure on a single processing thread. The methodology is not described. No hardware, no message size distribution, no configuration, no number of repetitions. A claim of ten times throughput is plausible for an agent written in a systems language with a zero-copy design against agents written in higher-level ones, and it is also exactly the kind of claim a competitor would dispute. Treat the tables as the author's characterisation of a design advantage and go measure it on your own logs.

Six architectural decisions, each naming a real bottleneck

Below the tables is a list of six performance and reliability features, and this is the more durable content because each one names a specific problem. The first is a shared memory pool that stores string data once per event group, with string-view references pointing at the original segments rather than copying. The second is a lock-free event pool with thread-aware allocation, using same-thread pools for direct reuse and double-buffered pools for cross-thread cases, which is aimed at lock contention between collection and processing threads. The third is serialization that bypasses intermediate structured objects and writes the network format directly, which removes an allocation and a copy per event. Those three are the classic zero-copy arguments and they are the reason a systems language helps. The fourth is multi-tenant pipeline isolation using high and low watermark feedback queues, with independent resource allocation per pipeline and automatic back-pressure, described as ensuring one pipeline's failure does not affect others. The fifth is fair resource allocation by priority, using round-robin scheduling that respects business priorities and yields automatically under constraint. The sixth is network resilience with per-destination concurrency limiting using additive increase and multiplicative decrease, for fast failure detection and gradual recovery, with a stated zero data loss guarantee backed by back-pressure. That last pair is the one an operator cares about most, because a collector that drops data under network trouble is worse than one that slows down.

One agent, five signal types, and eBPF in the box

The collection scope is broader than the log-agent category usually implies. The readme describes a unified agent for logs, metrics, traces, events and profiles, with native Kubernetes support and eBPF-powered network monitoring and security event collection. The eBPF part is the differentiator, because it moves the collector from reading files and exposing counters into observing the kernel, and the repository confirms the emphasis with an eBPF topic, a separate plugin directory, a configuration file listing plugins and a build system that has an option specifically for enabling an eBPF component that the makefile says the aggregate build targets require. The sibling agents in the same suite complete the picture: a Python process agent, a Go process agent with compile-time instrumentation, and a Java process agent. That division of labour is the architectural point. A node agent that handles host-level signals and a language agent that handles in-process signals solve different problems, and merging them is what makes some agents heavy. The readme also mentions community meetings held monthly with recordings, which is a maintenance signal of a different kind: a project that meets monthly and records it has an active contributor base rather than a single maintainer.

A C++ agent with Go plugins, and a hundred of them

The repository layout describes a build with more moving parts than a typical agent. There is a core directory, a package directory, a plugin manager, a plugin manifest listing plugins, a plugins directory, a main plugin directory, a protobuf definitions directory, a configuration server directory, Kubernetes templates, an example configuration, a docker directory, a test directory, a tools directory and a scripts directory, plus editor and formatting configuration for a C++ toolchain, a linter configuration for Go, a markdown linter configuration and a documentation site configuration. The plugin system is where the design commitment shows. The readme says there are more than a hundred built-in plugins, written in C++ or Go, and that a processing language engine handles transformation. So the core agent is a systems-language data plane and the extensibility is a mix of in-process plugins in two languages plus a language-agnostic pipeline definition. That is a reasonable structure and it has a known cost. A plugin running in the agent's process can crash the agent, and a hundred plugins means a hundred things to version and test together. The Go module file is the best available inventory of what the outputs are, and it is long: message queue clients, columnar and relational databases, a document store, a metrics database, two log stores, an export protocol client for host metrics, a structured-log client, an MQTT client, a syslog receiver, a database server protocol client, a network management client, a document store, a hashing library, several structured-data parsers and serialisers, and a regular expression engine that is not the standard library one. That breadth is the product, and it is also the compatibility surface.

Renamed, repackaged, and still carrying the old identity

The build files are where a rename shows through, and the details are worth reading for what they imply about maturity. The image repositories named in the build configuration are:

DOCKER_REPOSITORY ?= aliyun/loongcollector

The container image repository and the build repository are named for a different name, the copyright header in the makefile names a third, and the Go module file declares the old name as its module path. The static analysis badge points at a project under a different name again. So the code was originally published under one name, renamed, and the build infrastructure kept the original identifiers, which is what happens when a project is renamed late and nobody goes back to change every string. It is harmless and it is also a useful signal: this is a fifteen-year-old codebase, as the readme says, with a rename on top. The licence headers are present in the build file, and there is a separate licenses directory, which suggests the project tracks third-party attribution properly. Two more details from the build file are worth noting. The platform list is explicit, covering Linux, macOS and Windows, and the architecture detection has a branch for a processor family nobody outside that ecosystem uses, falling back to a fourth value, which is evidence about the deployment footprint as much as about the build. And the build version defaults to a placeholder that the release process overrides, so a build from a checkout without a tag produces a version string that means nothing.

Editorial conclusion

Adopt LoongCollector if you run a large fleet and are paying for per-node collectors, since the resource numbers in the readme suggest a large saving at scale and the multi-tenant isolation and back-pressure design is aimed squarely at the failure mode where one noisy pipeline starves the rest. Do not adopt it on the strength of the benchmark table, because the methodology is not described and the numbers are self-reported against named competitors. Four things to verify. Whether the throughput figures mean anything for your workload, since a single line of log and a line matching a regular expression differ by an order of magnitude in the same table, and your mix decides which row applies. Which destinations you need, since the Go module file lists output libraries for a wide range of databases, message queues and log stores, and that breadth is both the feature and the maintenance surface. How configuration reaches the agent, because the readme names a managed console, an SDK and a Kubernetes operator, which is three different operational models. And what the plugin model costs you, since plugins are written in two languages and a plugin is a dependency you now own. The licence is Apache-2.0, version 3.4.1 was released on 2026-09-20, and the last push was on 2026-09-21.

Frequently asked questions

Official sources

1. alibaba/loongcollector on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases