stats: Create a stat exporter port for monitoring purposes
The Control Port does basically export a lot of data that tor holds but this new Stat Port (we'll call that for now) differs in a couple of ways.
The idea is that it would be a pull mechanism so tools connect to the port, request a series of stats, tor sends it and then disconnects. This follows the Prometheus model which is to expose your stats through an HTTP interface and the monitoring server just comes in regularly and get the data.
Tor has already everything to support that that is listener port and HTTP interface we can hook on (with a bit of work :).
We can export all sorts of stats useful for monitoring relays and onion services. For example, for onion service monitoring, exporting these would be game changer for service operators:
- Amount of traffic the .onion is getting
- Amount of introduction requests
- Amount of rendezvous requests and how many succeeds vs fails.
- Descriptor status with HSDir ...
The reason it differs from the Control Port is that most public relays or onion services would prefer not having that port open especially on a public address. But also, this follows the concept of providing a REST interface which would be very little amount of work for the tor daemon where with the control port, is often a mixed of poking at our internal state instead of a pre-populated memory with stats.
There is of course the question of data safety here. If we build nice interface that in couple clicks allows operators to have beautiful Grafana graphs, then some says it is an incentive to export it and sometimes publicly.
However, this is really not different from the Control Port or Nyx monitoring interface. The problem shows up when the third part tool gathering the data actually archives. That today, is doable. This would yes be lowering the bar for this to happen but I think the ability to properly monitor a relay or an onion service outweigh the cons.
We could see that at first it is only for onion services and on a non public port. We could think of security checks like this but in the end, this is would just be another tool in the service operator belt to properly monitor tor if they choose to with of course risks associated with it like anything tor opens.
This is one example that @ahf worked on but with a push model: https://github.com/ahf/tor/tree/ahf/feature/stats_reporter