collector

What Collector does

Collector is a component of StackRox responsible for gathering runtime data. In a few words it is an agent that runs on every node under strict performance limitations and gathers the data via kernel modules or eBPF probes, which the project describes as the default collection mode nowadays. To implement eBPF probes and collect data, the project leverages the Falco libraries via a custom fork of falcosecurity-libs. The README frames Collector as the part of StackRox that watches what runs on a cluster and reports it back under tight resource budgets. That constraint matters because a security sensor that consumes too much CPU or memory would be rejected by cluster operators who prioritize workload stability. The documentation presents Collector as a long running node agent rather than a periodic scanner, which shapes both its performance goals and its failure modes. The text also makes clear that eBPF is the preferred path going forward while kernel modules remain a supported collection mechanism. For someone evaluating the project, the practical takeaway is that Collector is a focused data gathering daemon, not a full security platform on its own. Its value comes from feeding the rest of StackRox, and the design choices around eBPF and strict limits reflect that single responsibility.

Build and contribution setup

The project documentation organizes its guidance into a small set of pages meant to help different readers. A how to start page is positioned as the best entry point for anyone who wants to contribute, and it covers building and troubleshooting the project from scratch. A design overview page is aimed at readers whose goal is to understand how Collector works and where it sits in the broader StackRox system. A troubleshooting page collects common startup errors together with ways of identifying and fixing them, which is useful because a node agent that fails to start can be hard to diagnose without guidance. A release process page offers tips for people who run into trouble while cutting a release. A references page contains a comprehensive list of configuration options for the project, which is the kind of index that operators consult when tuning behavior. The README also links out to these docs from a single useful links section so that a new reader is not left guessing where to begin. Taken together these pages show a project that expects outside contributions and tries to lower the cost of getting a working build. The tone is practical rather than promotional, and the emphasis on troubleshooting reflects the reality that low level eBPF and kernel module code is sensitive to the host kernel.

Upstream and downstream pipelines

The README leads with a branch table that maps each supported line to its upstream and downstream continuous integration status. The master branch shows a nightly upstream workflow plus a downstream Konflux workflow, while the maintenance branches such as 3.24, 3.23 and 3.22 each carry their own pair of upstream and downstream badges. Each maintenance row also links upward to a corresponding StackRox release, for example 3.24 points at StackRox release 4.10, 3.23 at 4.9, and 3.22 at 4.8. This structure tells a clear story about how the collector code flows: changes land on master, get validated by the nightly upstream pipeline, and are then carried into downstream builds through Konflux, while older lines continue to receive maintenance tied to specific platform releases. For a reader, the badges are a quick health signal, and the upward links make it possible to trace exactly which collector version ships inside which StackRox version. The presence of multiple concurrent maintenance branches also signals that the project supports several live releases at once rather than only the latest. Both the upstream and downstream pipelines run on GitHub Actions, and the cadence differs by branch, with master validated on a schedule and the maintenance lines validated on push. The repository is published under the Apache-2.0 license and its most recent commit was on 2026-08-26.

Editorial conclusion

Collector is a component of StackRox responsible for gathering runtime data. In a few words it is an agent that runs on every node under strict performance limitations and gathers data via kernel modules or eBPF probes, which is the default collection mode nowadays. To implement eBPF probes and collect data the project leverages the Falco libraries through a custom fork of falcosecurity-libs. The README frames Collector as the part of StackRox that watches what runs on a cluster and reports it back under tight resource budgets, which matters because a security sensor that consumes too much CPU or memory would be rejected by cluster operators. The documentation points new contributors to a how to start guide that covers building and troubleshooting the project from scratch, a design overview for understanding how Collector fits into the wider system, a troubleshooting page for common startup errors, a release process page, and a references page that lists configuration options. The repository tracks several release branches at once, including master plus maintenance lines such as 3.24, 3.23 and 3.22, each paired with a corresponding StackRox release. The repository is published under the Apache-2.0 license and its most recent commit was on 2026-08-26.