Description
Motivation
With the current Falco outputs implementation (i.e., the mechanism that provides Falco Alerts), when a rule is matched then the event processing blocks for the time needed to deliver the alert (e.g., the output processing is not offloaded in another thread). Consequently, when a Falco output is blocked for any reason (e.g., waiting for I/O), the whole Falco process slows down too.
Note that does not apply for the gRPC output, since it is already non-blocking (but unfortunately it's the only one).
Furthermore, the implementation uses LUA code (mostly as glue) without any real needs or benefits, IMHO.
Since I believe that's worth reducing the overall complexity of outputs before adding a new feature, I have opened a PR yet ( #1412 ) that re-implement the outputs in C++ only (removing the LUA code) and shows why that may be convenient.
Feature
- Reduce complexity by porting LUA implementation to C++ 👉 Falco outputs refactoring #1412
- Introduce a non-blocking mechanism for Falco outputs 👉 1451
Alternatives
A radical alternative could be to define an output API (or just saying the current gRPC interface is the output API) and implements all outputs mechanism outside Falco (so removing them from the Falco source code).
However, that does not seem to be convenient for simple outputs, such as stdout and syslog.
Additional context
When an output is blocking Falco to processes system calls, events drops may occur. This particular issue is well described in this
#1403 (comment).
Activity