Implement the new metrics Reporter

[jdoe7865623]

This is a work in progress for feedback, migration to the new reporter is not done yet.

The new console stats will tentatively look as follows:

 --- Traffic stats ---
 |            Target | Requests attempted | Requests sent | Responses received | Data sent | Data received |
 | http://foobar.com |               1100 |           110 |                 11 |  17.19 MB |       4.30 MB |
 |  tcp://foobar.com |               1100 |           110 |                 11 |   1.72 MB |       0.43 MB |
 |               --- |                --- |           --- |                --- |       --- |           --- |
 |             Total |               2200 |           220 |                 22 |  18.91 MB |       4.73 MB |

[roman-kruglov]

Hi! I thought about something similar too, to better inform the user about the results and thus efficiency. So I had one more thought - maybe it should somehow specify summarised response codes and something like closed / rejected connections. And maybe some efficiency coefficient. No idea how to calculate it, but it would be great - e.g. to try different VPNs / servers. What do you think? (yes, I'm willing to participate in coding, just trying to cooperate because I found your pr which seems close to something I would do, so I decided to write here first).

[roman-kruglov]

Also had an idea to replace those tons of duplicated repetitive messages about starting a thread for a target like

2022/04/06 17:07:48.414177 http.go:147: Attacking **sample**
2022/04/06 17:07:48.414892 http.go:147: Attacking **sample**
2022/04/06 17:07:48.415018 http.go:147: Attacking **sample**
2022/04/06 17:07:48.415130 http.go:147: Attacking **sample**
2022/04/06 17:07:48.415163 http.go:147: Attacking **sample**

with something more combined and shorter, like maybe

2022/04/06 17:07:48.414177 http.go:147: Attacking (30 threads) https://**sample**
2022/04/06 17:07:48.414892 http.go:147: Attacking (20 threads) https://**sample**
etc

would be much shorter and easier to follow

[jdoe7865623]

Hi! I thought about something similar too, to better inform the user about the results and thus efficiency. So I had one more thought - maybe it should somehow specify summarised response codes and something like closed / rejected connections. And maybe some efficiency coefficient. No idea how to calculate it, but it would be great - e.g. to try different VPNs / servers. What do you think? (yes, I'm willing to participate in coding, just trying to cooperate because I found your pr which seems close to something I would do, so I decided to write here first).

Fair enough; we can't summarize by response codes since there are different protocols involved - not only HTTP. This is why I thought of the five metrics you can see in the table as a common denominator of sorts. Collecting these metrics from all supported jobs is still a WIP.

You may define "efficiency" as a ratio between the responses received and requests attempted (or sent). But this is somewhat subjective (what if the target is down due to the swarm activity? :), so I decided to start with plain stats. I'm open to suggestions, though.

[jdoe7865623]

Also had an idea to replace those tons of duplicated repetitive messages about starting a thread for a target like

2022/04/06 17:07:48.414177 http.go:147: Attacking https://kupiprodai.ru
2022/04/06 17:07:48.414892 http.go:147: Attacking https://kupiprodai.ru
2022/04/06 17:07:48.415018 http.go:147: Attacking http://kupiprodai.ru
2022/04/06 17:07:48.415130 http.go:147: Attacking https://kupiprodai.ru
2022/04/06 17:07:48.415163 http.go:147: Attacking http://kupiprodai.ru

with something more combined and shorter, like maybe

2022/04/06 17:07:48.414177 http.go:147: Attacking (30 threads) https://kupiprodai.ru
2022/04/06 17:07:48.414892 http.go:147: Attacking (20 threads) https://rudos.ru
etc

would be much shorter and easier to follow

Yeah, those are not super-helpful at this point. The runner does not know much about the specific job config, though, thus we log this stuff from within the jobs in coroutines. That causes a barrage of identical messages. Feel free to submit a PR if you come up with a smart suggestion :)

[roman-kruglov]

ok, yep, I'll try. I have several small ideas to start from.