[8.x](backport #41952) auditbeat: Add a cached file hasher for auditbeat #41992
+373
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![mergify[bot]](https://avatars.githubusercontent.com/in/10562?s=60&v=4){kind=small}
This implements a LRU cache on top of the FileHasher from hasher.go, it will be
used in the new backend for the system process module on linux.
The cache is indexed by file path and stores the metadata (what we get from
stat(2)/statx(2)) along with the hashes of each file.
When we want to hash a file: we stat() the file, then do cache lookup and
compare against the stored metadata, if it differs, we rehash, if not we use the
cached values.
The cache ignores access time (atime), it's only interested in write
modifications, if the machine doesn't support statx(2) it falls back to stat(2)
but uses the same Unix.Statx_t.
With this we end up with a stat() + lookup on the hotpath, and a stat() + stat()
+ insert on the cold path.
The motivation for this is that the new backend ends up fetching "all
processes", which in turn causes it to try to hash at every event, the
current/old hasher just can't cope with it:
1. Hashing for each event is simply to expensive, in the 100us-50ms range on the
default configuration, which puts us below 1000/s.
2. It has a scan rate throttling that on the default configuration ends easily
at 40ms per event (25/s).
With the cache things improve considerably, we stay below 5us (200k/s) in all
cases:
```
MISSES
"miss (/usr/sbin/sshd) took 2.571359ms"
"miss (/usr/bin/containerd) took 52.099386ms"
"miss (/usr/sbin/gssproxy) took 160us"
"miss (/usr/sbin/atd) took 50.032us"
HITS
"hit (/usr/sbin/sshd) took 2.163us"
"hit (/usr/lib/systemd/systemd) took 3.024us"
"hit (/usr/lib/systemd/systemd) took 859ns"
"hit (/usr/sbin/sshd) took 805ns"
```
(cherry picked from commit 8ec2e31)
botelastic
bot
added
the
needs_team
haesbaert
added
the
Team:Security-Linux Platform
|
Pinging @elastic/sec-linux-platform (Team:Security-Linux Platform) |
botelastic
bot
removed
the
needs_team
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed commit message
This implements a LRU cache on top of the FileHasher from hasher.go, it will be used in the new backend for the system process module on linux.
The cache is indexed by file path and stores the metadata (what we get from stat(2)/statx(2)) along with the hashes of each file.
When we want to hash a file: we stat() the file, then do cache lookup and compare against the stored metadata, if it differs, we rehash, if not we use the cached values.
The cache ignores access time (atime), it's only interested in write modifications, if the machine doesn't support statx(2) it falls back to stat(2) but uses the same Unix.Statx_t.
With this we end up with a stat() + lookup on the hotpath, and a stat() + stat() + insert on the cold path.
The motivation for this is that the new backend ends up fetching "all processes", which in turn causes it to try to hash at every event, the current/old hasher just can't cope with it:
With the cache things improve considerably, we stay below 5us (200k/s) in all cases:
Checklist
- [ ] I have made corresponding changes to the documentation- [ ] I have made corresponding change to the default configuration filesCHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.This is an automatic backport of pull request auditbeat: Add a cached file hasher for auditbeat #41952 done by Mergify.