I'm really not sure if I'm a fan of this. Not because I don't see the value of being able to intercept and monitor the rest requests, but because we're mixing in a low-level event with all the high-level ones.

All events passed through Javacords event bus relate to actual state changes on discords side - granted, they may be caused by (bot) user actions but still, the events displayed comes from discord. This would be the first event that happens on our side and also the only one that's on a low technical level rather than representing a state change.

I like the idea, but I am not at all convinced just slapping it on the event dispatcher. Things that deal with the internals of Javacord should go a different way. The idea of specific modules (#356 and #805) has been brought up before and I feel a "Monitoring Module" that can be activated and deactivated on startup as needed and interacted with would be a far more robust and adequate solution.

I see what you mean. Usually I would agree on moving it into it's own module but isn't it a bit overkill? While the cache and rest module will be quiet large and encapsulate the code very good like it should be, I don't think there a lot of metrics that we can actually dispatch. We could for example in addition to the rest requests also expose the websocket events (there's already a PR that suggest to add an event for any gateway event #917) but I can't think of anything that might be worth exposing too for monitoring purposes. Even if there are 2 or 3 more possible metrics, it will most likely be just a few lines to actually expose them when doing it like in this PR.
Also what do you think how should the module look like and how should we interact with it to get the data if we do not dispatch it?