Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Counterpart of afl++'s rpc_statsd? #2895

Open
Evian-Zhang opened this issue Jan 27, 2025 · 3 comments
Open

Counterpart of afl++'s rpc_statsd? #2895

Evian-Zhang opened this issue Jan 27, 2025 · 3 comments

Comments

@Evian-Zhang
Copy link
Contributor

I wonder if there is a counterpart of afl++'s rpc_statsd in LibAFL? I noted there is a prometheus monitor, but as far as I understand, this is not what I want.

The afl++'s rpc statsd has the following abilities:

  • A TUI monitor and a statsd monitor at the same time.
  • The statsd monitor sends the metrics (to a statsd aggregator), instead of host the metrics

Currently, the prometheus monitor is not good for incremental fuzzing, i.e., there may be several new targets to be fuzzed every day, so I want to add those stats as well. However, in current solution, each fuzzing instance needs a separate port, and we need to aggregate stats from all ports to show a total information.

@domenukk
Copy link
Member

Interesting, I don't personally use either statsd nor prometheus.
I though they are roughly equivalent but looking at the code you're right.

TL;DR: I don't think we have that right now.
Should be rather easy to implement though, probably top of the prometheus monitor, or one of the OnDisk monitors.
(Personally I don't have time atm / no test setup)

@Evian-Zhang
Copy link
Contributor Author

Thank you for your reply:)

And yet there is another question: can we have two or more monitors at the same time? The tui monitor and the to-be-implemented statsd monitor should both be there in my experience.

We could look at the statsd monitor for the overall-information of all fuzzing instances we are running, and look at the individual tui monitor for detail information.

@domenukk
Copy link
Member

You could build a simple monitor that takes two child monitors and forwards every incoming message to both.
That would be very useful to have in any case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants