[feature] Implement Iperf3 check #385

[Aryamanz29]

• Added initial code for Iperf3 check class.
• Added tests for check class.
• Added device connection logic.
• Added charts & metric (TCP & UDP mode).

Steps to test

1. Make sure your client (openwrt-device) and server both have Iperf3, Openwrt Iperf3 package installed.
2. Do check the credential section of the device (It must be enabled and working with the right update strategy, i.e., ssh).

3. In tests/openwisp2/settings.py configure:

OPENWISP_MONITORING_IPERF3_SERVERS = {
    # Running on my local
    # Some Public Iperf3 Servers : https://iperf.fr/iperf-servers.php#public-servers
    # 'be63c4e5-a68a-4650-bfe8-733837edb8be': ['iperf.biznetnetworks.com'],
    'a9734710-db30-46b0-a2fc-01f01046fe4f': ['speedtest.uztelecom.uz'],
    # '<org-pk>': ['<ORG_IPERF3_SERVER>']
}

NOTE : The host can be specified by hostname, IPv4 literal, or IPv6 literal

# for ex
              iperf3 -c iperf.biznetnetworks.com

              iperf3 -c 192.168.5.109

              iperf3 -c 2001:db8::1

4. Run python3 manage.py run_checks (To run all checks manually).

Demo

iperf_demo.mp4

TCP Charts

UDP Charts

Closes #385

[coveralls]

Coverage remained the same at 98.709% when pulling 9213aaf on issue-385/iperf-check into e563520 on gsoc22-iperf.

[nemesifier]

I changed the target branch to gsoc22-iperf. Please let's use this from now on.

CC: @pandafy @okraits.

[pandafy]

Great work @Aryamanz29! 👏🏼 👏🏼

@nemesisdesign @okraits things that I have tested manually:

• The iperf check is created automatically when a new device registers
• The iperf check is not created if OPENWISP_MONITORING_AUTO_IPERF is set to False.
• The iperf check execute for a device having an active SSH connection.
• The iperf check does not execute for a device whose SSH connection is in not_working state
• The charts are shown for the gathered data.

Edge cases to handle

• The database reports that DeviceConnection is working, but the management tunnel goes down just before iperf check was executed. The code should be able to gracefully handle this and also notify users that SSH connection is not working. We already have a mechanism for sending notifications. @Aryamanz29 please check other checks for reference and ask us your doubts.

Things to discuss in next weekly meeting

• What parameter should trigger alert for iperf check?
• Which data should be shown to users with charts?

[Aryamanz29]

@pandafy In 8823581 I have fixed #399, Now you can see below that error is longer produced because earlier we're executing command without considering the device_connection working status just right after connect() method.

One more thing, do we really need to notify users for this event? I mean when I'm testing it locally, the "SSH not working" alert already popped out & it already fulfilled our purpose, what do you think? Although, I have added logger.warn() which is specific for the check.

[pandafy]

One more thing, do we really need to notify users for this event? I mean when I'm testing it locally, the "SSH not working" alert already popped out & it already fulfilled our purpose, what do you think? Although, I have added logger.warn() which is specific for the check.

As the user is already getting one notification for SSH not working, we don't need to create another notification. Logging a warning is sufficient.

I will do manual testing later today.

[pandafy]

@Aryamanz29 I did a manual test of the changes and I don't see an error for #399. I will do an in-depth code review tomorrow.

Good work @Aryamanz29! 👏🏼

[pandafy]

@nemesisdesign @okraits I need some clarity on how we are planning to store the data in the InfluxDB. The current implementation ignores the bitrate from the UDP test, which seems wrong to me.

Thinking out loud
A good argument could be "because UDP bitrate would be similar to TCP bitrate so we can ignore that". If so, then why bother doing a UDP test? Is it only for getting jitter and packet loss?