Overhaul stats: Refactor metrics (part 2)

[josecelano]

Depends on: #1445

The API exposes the "old" metrics (/stats) and the new ones (/metrics)

Internally, we use only one repository to store both:

For example, in packages/http-tracker-core/src/statistics/metrics.rs:

pub struct Metrics {
    /// Total number of TCP (HTTP tracker) `announce` requests from IPv4 peers.
    pub tcp4_announces_handled: u64,

    /// Total number of TCP (HTTP tracker) `scrape` requests from IPv4 peers.
    pub tcp4_scrapes_handled: u64,

    /// Total number of TCP (HTTP tracker) `announce` requests from IPv6 peers.
    pub tcp6_announces_handled: u64,

    /// Total number of TCP (HTTP tracker) `scrape` requests from IPv6 peers.
    pub tcp6_scrapes_handled: u64,

    /// A collection of metrics.
    pub metric_collection: MetricCollection,
}

impl Metrics {
    pub fn increase_counter(&mut self, metric_name: &MetricName, labels: &LabelSet, now: DurationSinceUnixEpoch) {
        self.metric_collection.increase_counter(metric_name, labels, now);
    }

    pub fn set_gauge(&mut self, metric_name: &MetricName, labels: &LabelSet, value: f64, now: DurationSinceUnixEpoch) {
        self.metric_collection.set_gauge(metric_name, labels, value, now);
    }
}

I kept global and new metrics because I didn't want to make breaking changes in the API. However, we can remove the old ones internally and calculate them from the new ones only when the API replies to a /stats request.

That would have these benefits:

• Simplify the bittorrent_http_tracker_core::statistics::event::handler
• Improve performance; the tracker does not have to maintain both metrics.

The cons are:

• The old /stats endpoint will be slower
• We must implement new methods in the MetricColelction type to calculate aggregate data. These methods could be helpful for other tasks in the future.

[josecelano]

I've been considering keeping both endpoints:

stats (simple predefined metrics)

• http://localhost:1212/api/v1/stats?token=MyAccessToken&format=json
• http://localhost:1212/api/v1/stats?token=MyAccessToken&format=prometheus

metrics (extendable-labelled metrics)

• http://localhost:1212/api/v1/metrics?token=MyAccessToken&format=json
• http://localhost:1212/api/v1/metrics?token=MyAccessToken&format=prometheus

The second one can be too complex for consumers with basic needs. Since they use labels, you need to aggregate measurements if you want the total for a given metric.

Besides, I'm planning to implement functions on the MetricCollection type to sum samples for a metric. They can be useful for third-party users consuming Torrust tracker metrics.

If we keep both, we should calculate the stats from the new labeled metrics to avoid duplicate code.

[josecelano]

Implementation plan

We now have two Grafana dashboards for the demo tracker:

• On the left: the one that uses data from stats endpoint (global stats)
• On the right: the one that uses data from the metrics endpoint (labeled metrics)

1. Add new methods to MetricCollection to sum all samples from the same metric.
2. Use the new methods to calculate the "old" metrics in the stats endpoint. Use metric collection in https://github.com/torrust/torrust-tracker/blob/develop/packages/rest-tracker-api-core/src/statistics/services.rs#L41-L100
3. Deploy the new version to the demo tracker and verify that the "stats" and "metrics" dashboards appear identical.
4. Delete unused code for global metrics from repositories. For example: https://github.com/torrust/torrust-tracker/blob/develop/packages/udp-tracker-server/src/statistics/metrics.rs#L10-L65. Do it for all packages using global metrics. We have to keep only the labeled metrics. This will imply deletion of repository calls in the event handlers. These metrics are not kept anymore directly from events, but indirectly from labeled metrics.
5. Deploy again to the demo tracker and verify again.

cc @da2ce7