Relates to:
Current metrics (http://0.0.0.0:1212/api/v1/stats?token=MyAccessToken):
{
"torrents": 0,
"seeders": 0,
"completed": 0,
"leechers": 0,
"tcp4_connections_handled": 0,
"tcp4_announces_handled": 0,
"tcp4_scrapes_handled": 0,
"tcp6_connections_handled": 0,
"tcp6_announces_handled": 0,
"tcp6_scrapes_handled": 0,
"udp_requests_aborted": 0,
"udp4_requests": 0,
"udp4_connections_handled": 0,
"udp4_announces_handled": 0,
"udp4_scrapes_handled": 0,
"udp4_responses": 0,
"udp4_errors_handled": 0,
"udp6_requests": 0,
"udp6_connections_handled": 0,
"udp6_announces_handled": 0,
"udp6_scrapes_handled": 0,
"udp6_responses": 0,
"udp6_errors_handled": 0
}We will add these new metrics:
upd_average_connect_latency: the average time processing a UDP connect request takes.upd_average_announce_latency: the average time processing a UDP announce request takes.upd_average_scrape_latency: the average time processing a UDP announce request takes.
And also, these:
udp_banned_ips_total: the total number of IPs that have been banned for sending wrong connection IDs.udp_requests_banned: the total number of UDP requests that have been banned.
NOTE: Counting the number of requests banned can decrease the effectiveness of the banned service because it implies minimal request processing (to increase the counter). I think it's worth knowing exactly what's happening.
We can add the generic udp_banned_ips_total; in the future, if we have more reasons to ban an IP, we can create sub-counters for each reason.
@da2ce7 Should these metrics also be split into IPv4 and IPV6 metrics? I think it's not relevant in this case.
Relates to:
Current metrics (http://0.0.0.0:1212/api/v1/stats?token=MyAccessToken):
{ "torrents": 0, "seeders": 0, "completed": 0, "leechers": 0, "tcp4_connections_handled": 0, "tcp4_announces_handled": 0, "tcp4_scrapes_handled": 0, "tcp6_connections_handled": 0, "tcp6_announces_handled": 0, "tcp6_scrapes_handled": 0, "udp_requests_aborted": 0, "udp4_requests": 0, "udp4_connections_handled": 0, "udp4_announces_handled": 0, "udp4_scrapes_handled": 0, "udp4_responses": 0, "udp4_errors_handled": 0, "udp6_requests": 0, "udp6_connections_handled": 0, "udp6_announces_handled": 0, "udp6_scrapes_handled": 0, "udp6_responses": 0, "udp6_errors_handled": 0 }We will add these new metrics:
upd_average_connect_latency: the average time processing a UDP connect request takes.upd_average_announce_latency: the average time processing a UDP announce request takes.upd_average_scrape_latency: the average time processing a UDP announce request takes.And also, these:
udp_banned_ips_total: the total number of IPs that have been banned for sending wrong connection IDs.udp_requests_banned: the total number of UDP requests that have been banned.NOTE: Counting the number of requests banned can decrease the effectiveness of the banned service because it implies minimal request processing (to increase the counter). I think it's worth knowing exactly what's happening.
We can add the generic
udp_banned_ips_total; in the future, if we have more reasons to ban an IP, we can create sub-counters for each reason.@da2ce7 Should these metrics also be split into IPv4 and IPV6 metrics? I think it's not relevant in this case.