libs
libs copied to clipboard
falcosecurity
libsinsp: increase log-level of cri errors
What type of PR is this?
Uncomment one (or more)
/kind <>lines:
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
Any specific area of the project related to this PR?
Uncomment one (or more)
/area <>lines:
/area build
/area driver-kmod
/area driver-ebpf
/area libscap
/area libsinsp
/area tests
/area proposals
What this PR does / why we need it:
Sometimes the container metadata is missing. In order to figure out why the CRI does not return the container metadata, increase log-level.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
When using this patch in sysdig, you could take https://github.com/draios/sysdig/pull/1871
Does this PR introduce a user-facing change?:
NONE
Signed-off-by: Alban Crequy [email protected]
Hi @alban. Thanks for your PR.
I'm waiting for a falcosecurity member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.
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.
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: alban
To complete the pull request process, please assign fededp after the PR has been reviewed.
You can assign the PR to them by writing /assign @fededp in a comment when ready.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
Hi! Thanks for this PR! I think that the main issue is that increasing the log level would flood your log super quickly! I guess that's the reason why it was put as debug.
Hi @FedeDP, yes, that's indeed a concern. My goal is to make use of that in production, so I tried to only increase the log level of actual errors, so that it would not be flooded. I left other debugs untouched. Do you think it could still flood the logs?
I have a version of this patch rebased on commit e5c53d648f3c4694385bbe488e7d47eaa36c229a (see branch alban_e5c53d648f3c_cri_getstatususing) because that's what sysdig is using (see cmake/modules/falcosecurity-libs.cmake#L32). Sysdig can be compiled with that patch with something like the following:
$ cmake ../sysdig -DFALCOSECURITY_LIBS_SOURCE_DIR=$(realpath $PWD/../../falcosecurity/libs) && time make
Then, the error logs from this patch should be visible with the command sysdig -D --log-level=error.
@leogr: Closed this PR.
In response to this:
Closing and reopening to trigger the CI /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.
@leogr: Reopened this PR.
In response to this:
/reopen
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.
Hi, @alban thanks for that. I don't like too much the idea since maybe not all Falco users would have this severity enabled, maybe the best solution is to build it from sources changing only these lines and seeing what is not working correctly. Anyway, if this is not a viable solution for you, we may temporarily enable this severity, let's see what other maintainers think about it
This issue https://github.com/falcosecurity/falco/issues/2068 presents a possible solution to the problem addressed in this PR
@alban PTAL, this enables logs from libsinsp into Falco! 👉🏼 https://github.com/falcosecurity/falco/pull/2093
@alban can you try with Falco 0.32.1 that ships the PR linked by @jasondellaluce ? If it works for you, i think we can close this one :)
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
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://github.com/falcosecurity/community.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://github.com/falcosecurity/community. /close
@poiana: Closed this PR.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with
/reopen.Mark the issue as fresh with
/remove-lifecycle rotten.Provide feedback via https://github.com/falcosecurity/community. /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.