search

perfsonar / maddash

The Monitoring and Debugging Dashboard (MaDDash) is a tool for collecting large amounts of inherently two-dimensional data and presenting it in visually useful ways.
Other
30 stars 8 forks source link

Incorrect behaviour on running perfsonar on VM #95

Closed micruzz82 closed 4 years ago

micruzz82 commented 4 years ago

Fully understand the document states that running perfsonar on a VM is not recommended however I have found 3 issues which should be detected and correctly displayed:

1) If I reboot the VM, the mesh status still shows green when running latency test. Where it should show a status of red. 2) If I disconnect a VM nic for an extended period, the mesh still shows as green but the tests do not update which is expected. Where it should show a status of red. 3) When I re-enable the nic back, the tests resume, but instead of marking a failure or even keeping the graph broken for the duration of the outage, instead maddash just displays a solid line or fills the gap as this is inaccurate depiction if there was a real outage.For the gap it should atleast display a red line or black line stating outage.

Would you be able to advise on the above?

micruzz82 commented 4 years ago

image

igarny commented 4 years ago

Dear MC,

First of all I would like to encourage you to use the perfSONAR user list. This issue tracker is for issues and we avoid using it for complaints. Meaning if there is a real issue we would prefer to have it split / focused on the specific issue and not as a cumulative complaint as it appears now.

Most of the reporting for this ticket is actually based on lack of understanding of the operation and components of perfSONAR framework. One thing are the graphs and completely different thing is the alerting and dashboard. Now directly on your points: on 1 + 2) This is an incorrect expectation! The applied snapshot has nothing to do with the matrix of the dashboard (for which I can only presume the complaint is about). In addition to that the matrix of statuses is not based on connectivity, but based on loss of packets. When the sender side is not present, then there are no packets being sent or lost.

on 3) The problem here is again, that no loss had been detected, which then leads to the expectation on the side of the system, that the received results without loss are actually consecutive results from a custom test.

Regards, Ivan

micruzz82 commented 4 years ago

Thanks Ivan. Apologies I was not aware. I will use the use list.