psc: The ps utility, with an eBPF twist and container context

(github.com)

44 points | by tanelpoder 4 hours ago

8 comments

grantseltzer 12 minutes ago
I've played with bpf iterators and wrote a post about them [1]. The benefit of iterating over tasks instead of scanning procfs is a pretty astounding performance difference:
> I ran benchmarks on current code in the datadog-agent which reads the relevant data from procfs as described at the beginning of this post. I then implemented benchmarks for capturing the same data with bpf. The performance results were a major improvement.
> On a linux system with around 250 Procs it took the procfs implemention 5.45 ms vs 75.6 us for bpf (bpf is ~72x faster). On a linux system with around 10,000 Procs it took the procfs implemention ~296us vs 3ms for bpf (bpf is ~100x faster).
[1] https://www.grant.pizza/blog/bpf-iter/

  # Find processes connected to a specific port
  psc 'socket.dstPort == uint(443)'

  # Filter by PID range
  psc 'process.pid > 1000 && process.pid < 2000'

It seems weird to require the user to remember that ports have to be marked uint when it doesn't look like anything else does.

mrbluecoat 2 hours ago
Thanks for including so many examples! Perhaps include one example output. Other than mention of the optional '--tree' parameter, it's unclear if the default result would be a list, table, JSON, etc.
WD-42 2 hours ago
This is neat but the examples comparing the tool against piping grep seem to counter the argument to me. A couple of pipes to grep seems much easier to remember and type, especially with all the quotes needed for psc. For scripts where you need exact output this looks great.
[-]
- pstoll 1 hour ago
  I’m the opposite - I much prefer a structured query language (ahem) for this type of thing. If I’m looking at someone’s (ie my own 6 months later) script I much prefer to see the explicit structure being queried vs “why are we feeling for foo or grabbing the 5th field based on squashed spaces as the separater”.
  Nice use of CEL too. Neat all around.
mgaunard 1 hour ago
I'm not convinced with the need to embed CEL. You could just output json and pipe to jq.
[-]
- guerrilla 56 minutes ago
  Sounds less efficient in both space and time.
  [-]
  - pstuart 13 minutes ago
    I guess it's a matter of muscle memory and workflow. It's nice to have options.
fellowmartian 42 minutes ago
An unfortunate name that triggers everybody who’s ever worked at Meta :)
apopapo 2 hours ago
> psc uses eBPF iterators to read process and file descriptor information directly from kernel data structures. This bypasses the /proc filesystem entirely, providing visibility that cannot be subverted by userland rootkits or LD_PRELOAD tricks.
Is there a trade off here?
[-]
- mgaunard 1 hour ago
  I found this justification dubious. To me the main reason to use eBPF is that it gives more information and is lower overhead.
- tempay 2 hours ago
  It requires root
  [-]
  - mgaunard 1 hour ago
    Running eBPF programs doesn't strictly require root.
    [-]
    - cpuguy83 39 minutes ago
      It requires cap_bpf which is considered a high privileged capability.
      So yes, it requires root in the sense of what people mean by root.
foobarqux 1 hour ago
Their first example is bad:
```
    ps aux | grep nginx | grep root | grep -v grep
```
can be done instead (from memory, not at a Linux machine ATM):
```
    ps -u root -C nginx
```
which is arguably better than their solution:
```
    psc 'process.name == "nginx" && process.user == "root"'
```
[-]
- xorcist 1 hour ago
  The commands in their example are not equivalent. The ps | grep thing searches the full command line including argument while ps -C (and, presumably, the psc thing) just returns the process name.
  Should you for some reason want to do the former, this is easiest done using:
```
  pgrep -u root -f nginx
```
  which exists on almost all platforms, with the notable exception of AIX.
  Their other slightly convoluted example is:
```
  psc 'socket.state == established && socket.dstPort == uint(443)'
```
  which is much more succinct with:
```
  lsof -i :443 -s TCP:ESTABLISHED
```