lo he instalado recientementedatos de reden una instancia debian de Amazon EC2 que tengo. Netdata es bastante bueno, buenos cuadros/gráficos, fácil de instalar (en comparación con otros).
Varias veces al día recibo un mensaje como
1m ipv4 udp receive buffer errors = 9 errors
number of UDP receive buffer errors during the last minute
y unos minutos después, un mensaje de recuperación. Probablemente haya cientos de errores indicados con UDP/TCP a lo largo del día. También veo un patrón similar en un servidor que ejecuto en casa.
He usado otros paquetes de monitoreo a lo largo de los años y nunca he visto errores de este tipo. Sospecho que cierto nivel de errores, especialmente en UDP, es normal, ¿verdad? ¿Es este el comportamiento esperado? ¿Puedo desactivar el monitoreo de estas alarmas?
Me mudé a una segunda NIC en la máquina de casa sin ningún cambio esencial en el comportamiento.
Este¿Número aceptable de errores de Ethernet en un entorno de tamaño mediano?sugiere que podría tener un problema grave y ciertamente puedo probar otras NIC en casa. Pero, ¿cómo solucionaría esto en mi instancia EC2?
También vale la pena señalar que logwatch no informa ningún problema, pero es posible que no esté configurado para esto.
Gracias por la orientación.
Respuesta1
netdatautiliza statsdcomo sistema de recopilación de métricas. Este es un protocolo basado en UDP que es increíblemente rápido y eficiente, pero a velocidades elevadas puede desbordar el recv_buffer del nodo de entrada. El búfer de recepción predeterminado es de alrededor de 1 M, por lo que si el agente statsd no puede consumir lo suficientemente rápido como para evitar que el búfer se llene, el núcleo descartará los datagramas.
La solución simple es aumentar su búfer de recepción a un tamaño mayor para manejar los picos; esto generalmente resuelve los problemas de desbordamiento del búfer UDP. Si aún ve constantemente el registro anterior, necesitará aumentar la capacidad de CPU de la máquina o pasar a una implementación de statsd con mayor rendimiento (tuvimos que pasar del cliente statsd estándar basado en nodejs a uno basado en C++).
Para aumentar el tamaño del búfer, utilice los siguientes comandos:
# echo "net.core.rmem_default=8388608" >> /etc/sysctl.conf
# echo "net.core.rmem_max=16777216" >> /etc/sysctl.conf
# sysctl -p
Los parámetros anteriores son muy agresivos y aumentarán el uso de memoria de la pila del kernel. Es posible que desees comenzar con valores más pequeños y aumentar a partir de ahí; la proporción tradicional es max = default * 2.
Más información está disponible aquí:https://www.ibm.com/support/knowledgecenter/en/SSQPD3_2.6.0/com.ibm.wllm.doc/UDPSocketBuffers.html