Add more metrics to the stats

[josecelano]

The tracker collects these metrics:

{
  "torrents": 171983,
  "seeders": 41739,
  "completed": 19352,
  "leechers": 130658,
  "tcp4_connections_handled": 43,
  "tcp4_announces_handled": 43,
  "tcp4_scrapes_handled": 0,
  "tcp6_connections_handled": 0,
  "tcp6_announces_handled": 0,
  "tcp6_scrapes_handled": 0,
  "udp4_connections_handled": 13970767,
  "udp4_announces_handled": 36213856,
  "udp4_scrapes_handled": 819566,
  "udp4_errors_handled": 11157054,
  "udp6_connections_handled": 0,
  "udp6_announces_handled": 0,
  "udp6_scrapes_handled": 0,
  "udp6_errors_handled": 0
}

that are exposed via an API endpoint (https://127.0.0.1/api/v1/stats?token=MyAccessToken).

I've been working on the integration with Prometheus and Grafana, and I have realized there are critical missing metrics that could help identify problems.

For example, regarding udp4_announces_handled, what we are actually doing is increasing the counter after calling the core tracker but before sending the response to the client. That means the requests could not have been handled at all. In the current implementation, "handled" means the requests have reached the core tracker at least.

We use a ring buffer for the active requests, and requests being processed can be aborted. I would like to know:

1. The number of requests that have been received (with the receiver). At this point, we don't even know the type.
2. The number of requests that have been aborted (force push in the ring buffer). We could know the type, but that would require some changes, and it can decrease performance because we nned to ask the processor about the current state of processing.
3. The number of responses successfully sent to the client.

NOTE: we have to check the impact on performance after adding these new metrics.

Proposal for names:

• udp4_requests
• udp4_requests_aborted
• udp4_responses_sent

Same for udp6.

What do you think @da2ce7? This will allow us to quickly detect problems. If it affects performance, we can enable/disable it with a configuration option.

[josecelano]

Hi @da2ce7, after running the demo tracker for 6 hours aprox with the new metrics, I'm getting this data:

With 880 req/sec, we have ~3 requests aborted in the ring buffer (active requests).