AltraMayor / AltraMayor/gatekeeper

Add more traffic statistics

Ouverte
#725 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
Operational demand
Langage dominant
C
Étoiles
1.6k
Forks
252
Métriques de merge des PR
Aucune PR mergée en 30 j

Description

Currently, Gatekeeper servers log basic statistics about the traffic. One of these log entries looks like this:
```
GK/6 2024-12-11 18:24:26 NOTICE Basic measurements [tot_pkts_num = 391822, tot_pkts_size = 210544477, pkts_num_granted = 378547, pkts_size_granted = 203208695, pkts_num_request = 9582, pkts_size_request = 1078775, pkts_num_declined = 3663, pkts_size_declined = 4972031, tot_pkts_num_dropped = 3663, tot_pkts_size_dropped = 4972031, tot_pkts_num_distributed = 30, tot_pkts_size_distributed = 2220, flow_table_occupancy = 55723/250000000=0.0%]
```
These basic statistics give a gist of what's going on in the network, but they lack enough depth to enable reports that show a more nuanced picture of the traffic and attacks. Adding log entries with raw information, such as logging information on all declined packets, is not a viable solution because too much disk I/O can degrade the forward performance of Gatekeeper servers, especially during attacks.

The following ideas are candidates for balancing more information and small overhead:
1. Grouping tuple information (i.e., source and destination IP addresses, protocol, and port numbers) of decline packets using a heavy-hitters algorithm and logging statistics on these heavy hitters. The old, never-merged pull request #94 offers an entry point for heavy-hitters algorithms since it implements the Space Saving Algorithm and RHHH algorithm. It is important to note that while heavy hitters provide a good summary of many attacks, it fails to describe highly distributed attacks that Gatekeeper can protect against.
2. Breaking the current statistics per destination IP address was suggested in [this discussion](https://github.com/AltraMayor/gatekeeper/discussions/720#discussion-7568698).
3. Logging packets per second and bytes per second for each priority in the request channel. The intention here is to understand abuses of the request channel since only aggregated data is available now.

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.