Open Andreagit97 opened 6 months ago
+1
Taking it one step further, make modern_ebpf
the default driver as it's a significant overhead for us maintainers to assist adopters in debugging when Falco is not starting up.
I think by now for the most part folks getting started with Falco are likely to try Falco on newer kernels. Folks who still need to support older kernels are probably more familiar with kernel dev etc and should be able to understand a clear error message stating that you need to use either the ebpf or kmod driver. More thoughts? We can move this to a dedicated discussion.
Also @Andreagit97 in fact we need more dedicated "debugging" guides:
Help
(located under Install and Operate)
metrics
better and index all supported metrics fields)How would you all like such an outline?
Taking it one step further, make modern_ebpf the default driver as it's a significant overhead for us maintainers to assist adopters in debugging when Falco is not starting up.
I think by now for the most part folks getting started with Falco are likely to try Falco on newer kernels. Folks who still need to support older kernels are probably more familiar with kernel dev etc and should be able to understand a clear error message stating that you need to use either the ebpf or kmod driver. More thoughts? We can move this to a dedicated discussion.
it makes sense to me! it would be great to have some stats on how many users are using the modern ebpf probe today, just to have an idea of the possible impact, but I'm not sure how to obtain this information, maybe we can try with a poll on the Falco channel...WDYT?
Also @Andreagit97 in fact we need more dedicated "debugging" guides:
I Like it very much!! Fully on board!
Awesome, yes a poll in the channel would be great!
Perhaps at first we can keep kmod
in the falco.yaml, but at least we enable Falco by default in the helm chart.
Another possibility could be to fallback to kmod
(the old default) when modern_ebpf is not supported by the system? kmod
seems the best fallback choice as it has the widest support range. Of course ebpf
could be the last attempt if conditions for kmod
are not met, e.g. DKMS and such.
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
/remove-lifecycle stale
/area documentation
What would you like to be added:
I'm noticing that the modern ebpf probe is still not widely known among users. There are cases in which using the modern probe could solve issues without any burden, but it seems users are not aware of its existence (e.g. https://github.com/falcosecurity/falco-website/issues/1135#issuecomment-1874236060). So I propose to put the modern ebpf engine as the preferred installation method all around the documentation so:
helm chart
,docker
,deb/rmp
,tag.gz
.Always in this direction, it could be useful to have a step-by-step tutorial on how to react to a Falco failure and change the running driver setting the
modern bpf
. This could be a simple example:This sort of tutorial could help in cases like this: https://github.com/falcosecurity/falco/issues/2982
More in general having a dedicated page in the doc where we explain what to do when users face certain errors would be amazing, for example it could avoid issues like this: https://github.com/falcosecurity/falco/issues/2989
TL:DR;