stackrox/collector

Log major Falco stages

Opened this issue · 0 comments

To help with troubleshooting make Falco more verbose if requested. This means:

  • Adding more logging with TRACE level when Falco combines information from
    various sources into one entity. Normally we could get quite a good picture
    about which events do we receive, but how those events are assembled is a
    black box. The obvious parts are:

    1. scap_linux_proc_get, where Falco reads information from procfs
    2. ContainerEnginer::resolve, where we match a process with a container id
    3. sinsp_threadinfo::add_child, where Falco establish dependencies between
      processes
    4. sinsp_threadinfo::set_user, where Falco matches a process with uid/gid
    5. set_ipv4/6_mapped_ipv6_addresses_and_ports, where Falco matches socket
      information with a file descriptor

    This is of course subject to the overhead evaluation.

  • Adding more logging with DEBUG level to initialization actions

    1. BPF program loading & attaching
    2. Preparing tail calling prog array
    3. Preparing & loading ringbuf, aux, settings and filter maps

    Usually it's easy to figure out the actual place of an issue, but we lack
    context and arguments, so add to the logging more details about maps & progs
    (e.g. a frequent error after messing around with maps is loading one with
    incorrect parameters, key size or such).

Part of #1320