Metrics would definitely be a useful addition, and is something I've thought about in the past, but never got around to implementing anything.

The only issue I see with your proposal is, how are messages defined?
TCP operates as a continuous data stream, and both the network, or certain toxics like slicer, will end up breaking that stream differently each time.
Bytes transmitted / received is something we could measure instead, though I'm not sure if that works for your use-case.

For storing / reporting stats, the concept of stateful toxics was implemented for scenarios similar to this.
Toxics themselves are just a function definition, and are re-used for each connection, so to get around this, a separate state object is created per-link.
You can look at some of the code for this in link.go, and read the docs on stateful toxics.
Some modification of link.go will still be required to get at the metrics out of the state object though.

Thank you.

I have been thinking about the idea of making a stateful toxic (I didn't know it exists already), my struggle with it is how to bring the context data to the toxic in the first place. It means either to make link.go, toxic_collection.go and toxic.go aware of this special toxic implementation (as they are aware of noop) or find another way to initiate it.

The other option is to go more in the path I took and monitor all the links through noop. I would prefer to do it through the link or the proxy instead of hacking noop, but since in the creation they just pass the channel directly to the toxic chain they are not aware of data passing through.

About the definition of message, you are right - I guess what I'm measuring is actually packets. I feel fine with that for the sake of keeping toxiproxy unaware of protocols above tcp. The idea of bytes received is good. I did a fork of toxiproxy-frontend and added a graph that shows the metrics in real time, while grouping close events if there are too many. Using bytes received as group size instead of num of packets will be more meaningful.

Any idea how can I know which client sent a specific packet? Also could be useful to show which toxics were active in a specific packet, especially where there is a probability they work. Any idea how can I know that?

Any more comments, anyone? Before I open a PR?