최근에 설치했어요순데이터내가 가지고 있는 Amazon EC2 Debian 인스턴스에서. Netdata는 매우 멋지고 멋진 차트/그래프이며 설치가 매우 쉽습니다(다른 제품에 비해).
나는 매일 여러 번 다음과 같은 메시지를 받습니다.
1m ipv4 udp receive buffer errors = 9 errors
number of UDP receive buffer errors during the last minute
그리고 몇 분 후에 복구 메시지가 옵니다. 하루 종일 UDP/TCP에 수백 개의 오류가 표시될 수 있습니다. 집에서 실행 중인 서버에서도 비슷한 패턴이 나타납니다.
나는 수년 동안 다른 모니터링 패키지를 사용해 왔지만 이런 유형의 오류를 본 적이 없습니다. 특히 UDP에서 어느 정도의 오류는 정상적인 것으로 생각됩니다. 맞습니까? 이것이 예상되는 동작입니까? 이러한 알람의 모니터링을 끌 수 있나요?
나는 동작에 근본적인 변화 없이 집에 있는 컴퓨터의 두 번째 NIC로 옮겼습니다.
이것중간 규모 환경에서 허용되는 이더넷 오류 수는 무엇입니까?심각한 문제가 있을 수 있다는 뜻이므로 집에서 다른 NIC를 사용해 볼 수도 있습니다. 하지만 EC2 인스턴스에서 이 문제를 해결할 수 있을까요?
Logwatch가 전혀 문제가 없다고 보고하지만 이에 대해 구성되지 않을 수도 있다는 점도 주목할 가치가 있습니다.
안내해주셔서 감사합니다.
답변1
netdatastatsd측정항목 수집 시스템으로 사용됩니다 . 이는 매우 빠르고 효율적인 UDP 기반 프로토콜이지만 높은 속도에서는 수신 노드의 recv_buffer가 오버플로될 수 있습니다. 기본 수신 버퍼는 약 1M입니다. 따라서 statsd 에이전트가 버퍼가 가득 차는 것을 방지할 만큼 빠르게 소비할 수 없는 경우 커널은 데이터그램을 삭제합니다.
간단한 해결책은 스파이크를 처리하기 위해 Recv 버퍼를 더 큰 크기로 늘리는 것입니다. 이는 일반적으로 UDP 버퍼 오버런 문제를 해결합니다. 위의 로그가 계속해서 표시된다면 머신의 CPU 용량을 늘리거나 성능이 더 뛰어난 statsd 구현으로 이동해야 합니다(표준 nodejs 기반 statsd 클라이언트에서 C++ 기반 클라이언트로 이동해야 했습니다).
버퍼 크기를 늘리려면 다음 명령을 사용하십시오.
# echo "net.core.rmem_default=8388608" >> /etc/sysctl.conf
# echo "net.core.rmem_max=16777216" >> /etc/sysctl.conf
# sysctl -p
위의 매개변수는 매우 공격적이며 커널 스택의 메모리 사용량을 증가시킵니다. 더 작은 값에서 시작하여 거기에서 증가할 수 있습니다. 일반적인 비율은 입니다 max = default * 2.
자세한 내용은 여기에서 확인할 수 있습니다.https://www.ibm.com/support/knowledgecenter/en/SSQPD3_2.6.0/com.ibm.wllm.doc/UDPSocketBuffers.html