-
Notifications
You must be signed in to change notification settings - Fork 0
Features
This document lists feature ideas, their descriptions and implementation status.
Status: implemented
A user can specify one or more interfaces and the program should capture the traffic and perform the analysis of the traffic using available auditors. It generates the metrics in different formats.
Status: implemented
A user can optionally enable saving the listened traffic into the .pcap files. The .pcap files can be subsequently analyzed and the relevant metrics should be returned in the CSV or JSON formats.
Status: new
The tool may get very busy when monitoring high traffic systems. Therefore, it should have an option to enable the power conservation mode. In this mode it should reduce work cycles to an acceptable minimum. The tool in the PC mode should be smart enough to catch the most important data and performance regressions, however some loss of precision is unavoidable. For example, it may keep tracking the changing trends but spend less computing cycles on the metrics that have been stable or are less important.
Status: implemented
The tool should output collected metrics in the CSV format into the console or a file.
Status: implemented
The tool should expose the REST API endpoint for metrics and return the metrics in the JSON format via this endpoint.
Status: implemented
The tool should periodically generate the metrics reports and return them over the SSE mechanism to the subscribers.
Status: implemented
The tool should return the metrics to the Prometheus.
Status: new
The tool should provide a stream gRPC endpoint to return the metrics to the subscribers periodically.
Status: implemented
The metrics should include the number of received BootRequest, BootReply and unknown message types and the percentage of each message type in the received packets stream.
Status: implemented
The metrics should include the data about the retransmissions. It includes the number of retransmissions (i.e., packets with non-zero secs value), the average retransmission time, and the MAC address of the client who has the longest retransmission time.
Status: implemented
The metrics should include the time between receiving the messages from the client and respective responses from the server. That is a time between Discover and Offer, a time beteween Request and Ack, and finally the time between Discover and Ack.
© Marcin Siodelski 2023-2024