Metrics

[arriven]

It'd be good to have more informative indicators on the tool progress.
Potential metrics:

• Amount of traffic sent per job/job type/overall
• Statuses of targets (at least http)
• CPU/RAM/Network usage
  The most important metric would be the overall amount of traffic.
  To avoid impact on performance and stability please implement it so that worker threads populate some thread safe structures with metrics that are regularly read and logged by a background thread.

Sub issues to split and plan work:

• Define and implement global metrics storage with thread-safe read-write operations to be used by other parts #4
• Implement background thread to read and output these metrics into logs on regular interval #5
• Integrate write hooks to metrics storage into actual worker code #6
• (improve metrics) track traffic generated by protocol headers and utility messages not exposed to go runtime #12

[arriven]

This is needed in order for coordinators to understand how many resources they have to better choose attack targets according to that

[kurlyk-dev]

We have a big farm of instances on AWS but it's really difficult to understand the efficiency of this staff without metrics.

[arriven]

@kurlyk-dev you can enable Prometheus via the commandline, it's not a lot but could be useful for your use case