Error reporting for output channels

[leogr]

Motivation

Errors that may occur in output channels are not being reported. This behavior can lead users to wrong assumptions.

Feature

Add a comprehensive error reporting mechanism to the Falco outputs implementation.
For example, when an output channel cannot write to the configured file or cannot reach the configured HTTP endpoint, Falco should report the error to stderr at least.

Alternatives

Do nothing is always an alternative, but users have almost no chance to get what is going on without error reporting.

Additional context

There could be cases where Falco can't continue to run when one of such error occurs. For example, what to do if Falco cannot write to a file because there's no more space on the disk?

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[MINQ1NG]

evt.type = write is igored by low-level settings of falco, that's why it doesn't output any error reporting after run falco. So, the left issue is find out how remove the wirte type from ignored list.

[fntlnz]

@MINQ1NG you can do that by passing the -A flag when starting Falco, however that has a performance penalty depending on the environment's load.

[leodido]

To do not ignore a particular event type (eg. write) we can set its event mask (using the libsinsp interface, set_eventmask if I do not recall it wrong).

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[leogr]

/remove-lifecycle stale

[jasondellaluce]

I don't know if this is outdated, but we seem to cover this right now: 👇🏼

falco/userspace/falco/falco_outputs.cpp

Line 336 in b33fb60

falco_logger::log(LOG_ERR, o->get_name() + ": " + string(e.what()) + "\n");

Falco catches exceptions arising from output channels and logs them with LOG_ERR level.

[leogr]

I don't know if this is outdated, but we seem to cover this right now: 👇🏼

falco/userspace/falco/falco_outputs.cpp

Line 336 in b33fb60

falco_logger::log(LOG_ERR, o->get_name() + ": " + string(e.what()) + "\n");

Falco catches exceptions arising from output channels and logs them with LOG_ERR level.

You are right, this issue was fixed by #1451. Thank you for noticing that!

/close

[poiana]

@leogr: Closing this issue.

In response to this:

I don't know if this is outdated, but we seem to cover this right now: 👇🏼

falco/userspace/falco/falco_outputs.cpp

Line 336 in b33fb60

falco_logger::log(LOG_ERR, o->get_name() + ": " + string(e.what()) + "\n");

Falco catches exceptions arising from output channels and logs them with LOG_ERR level.

You are right, this issue was fixed. Thank you for noticing that!

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.