Ich habe vor kurzem installiertNetzdatenauf einer Amazon EC2-Debian-Instanz, die ich habe. Netdata ist ziemlich cool, schöne Diagramme/Grafiken, mühelos einfach zu installieren (im Vergleich zu anderen).
Mehrmals am Tag erhalte ich eine Nachricht wie
1m ipv4 udp receive buffer errors = 9 errors
number of UDP receive buffer errors during the last minute
und ein paar Minuten später eine Wiederherstellungsmeldung. Wahrscheinlich werden im Laufe des Tages Hunderte von Fehlern bei UDP/TCP angezeigt. Ich sehe auch ein ähnliches Muster auf einem Server, den ich zu Hause betreibe.
Ich habe im Laufe der Jahre andere Überwachungspakete verwendet und noch nie Fehler dieser Art gesehen. Ich vermute, dass ein gewisses Maß an Fehlern, insbesondere bei UDP, normal ist, stimmt das? Ist das das erwartete Verhalten? Kann ich die Überwachung dieser Alarme deaktivieren?
Ich bin auf dem Rechner zu Hause auf eine zweite Netzwerkkarte umgestiegen, ohne dass sich das Verhalten wesentlich geändert hat.
DasAkzeptable Anzahl von Ethernet-Fehlern in einer mittelgroßen Umgebung?deutet darauf hin, dass ich möglicherweise ein ernstes Problem habe, und ich kann sicherlich andere Netzwerkkarten zu Hause ausprobieren. Aber wie würde ich das auf meiner EC2-Instanz lösen?
Es ist möglicherweise auch erwähnenswert, dass Logwatch überhaupt keine Probleme meldet, es ist jedoch möglicherweise nicht dafür konfiguriert.
Danke für die Anleitung.
Antwort1
netdataverwendet statsdals System zur Erfassung von Metriken. Dies ist ein UDP-basiertes Protokoll, das unglaublich schnell und effizient ist, aber bei hohen Raten den Empfangspuffer des Eingangsknotens überlaufen lassen kann. Der Standard-Empfangspuffer beträgt etwa 1 MB. Wenn der Statsd-Agent also nicht schnell genug verbrauchen kann, damit der Puffer nicht voll wird, verwirft der Kernel Datagramme.
Die einfache Lösung besteht darin, Ihren Empfangspuffer zu vergrößern, um Spitzen zu bewältigen. Dies löst normalerweise Probleme mit UDP-Pufferüberläufen. Wenn das obige Protokoll immer noch durchgehend angezeigt wird, müssen Sie die CPU-Kapazität des Computers erhöhen oder auf eine leistungsfähigere Statsd-Implementierung umsteigen (wir mussten vom standardmäßigen, auf Node.js basierenden Statsd-Client auf einen auf C++ basierenden Client umsteigen).
Um die Puffergrößen zu erhöhen, verwenden Sie die folgenden Befehle:
# echo "net.core.rmem_default=8388608" >> /etc/sysctl.conf
# echo "net.core.rmem_max=16777216" >> /etc/sysctl.conf
# sysctl -p
Die oben genannten Parameter sind sehr aggressiv und erhöhen den Speicherverbrauch des Kernel-Stacks. Sie sollten mit kleineren Werten beginnen und diese dann von dort aus erhöhen – das traditionelle Verhältnis ist max = default * 2.
Weitere Informationen finden Sie hier:https://www.ibm.com/support/knowledgecenter/en/SSQPD3_2.6.0/com.ibm.wllm.doc/UDPSocketBuffers.html