2

I am trying to create a simple anomaly alarm detection by looking at the KPI of my Linux servers. I was wondering when should I flag an alarm if see dropped packets ( both packet_in and/or packet_out). If I take a percentage total packets dropped/packets received ( and do the same for packets sent), and then alarm if i observe 20% or more packets getting dropped, does it make sense ?

I do understand dropping packets ( received ) may be normal and should not be seen as a issue with the server, but I believe it is worth flagging to report bigger issue with the local subnet or the connected switch. However, errors with packet sent can indicate problem with the NIC card, speed negotiation issue with the connected device. Therefore is fair to flag an dropped packet % >=20 ? would greatly appreciate experts response and some useful pointers to further fine-tune the reporting.

sunny
  • 121
  • 1

1 Answers1

0

If you want to condense your network functionality to a single metric (eg. for monitoring or graphing purposes), I'd recommend something called TCP retransmission percentage, which is pretty close to what you suggest in your question.

You get that number by dividing the number of tcp segment retransmissions by the total number of tcp segments sent, and multiplying by 100%, of course. Both of those metrics should be readily available via SNMP, sar, and what-have-you.

That percentage should be pretty close to 0 under normal conditions, anything over 2% is very likely a problem.

Bass
  • 601
  • 4
  • 8