Skip to content

Add more metrics #1145

@josecelano

Description

@josecelano

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.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions