nfs를 사용하지 않으면cacti에서 snmp 데이터를 찾을 수 없습니다

      

어제 동료가 나에게 cacti가 갑자기 서버의 snmp 데이터를 잡을 수 없다고 말했는데, 내가 좀 보게 한 후에 급히 나갔다.서버에 로그인한 후 161 포트가 열려 있는 것을 간단히 보았습니다. 프로세스도 의심할 것이 없어서 snmpd 서비스를 재개했습니다.
snmpwalk -v 2c -c public localhost .1.3.6.1.2.1.1.3
명령, 이미 데이터를 잡을 수 있다는 것을 발견, 문제가 해결된 줄 알았는데, 10초가 지나자 또 같은 고장이 났다는 것을 누가 알았겠는가.netstat-an|grep-w'161'을 실행하면 Recv-Q의 데이터가 이상하다는 것을 발견합니다. 정상적인 상황은 0이어야 합니다. 지금은 86533입니다. 데이터가 수신되었지만 받기를 기다리는 버퍼에 있습니다.우리 회사가 사용하는 공동체가 기본적인public이기 때문에 snmp의 프로필을pub로 변경하고 서비스를 재개한 후에 정상이 된 것을 발견했습니다. 넷stat-an|grep-w'161', Recv-Q의 데이터도 다시 0으로 바뀌었고 테스트도 이상이 발생하지 않았습니다.
나중에 동료가 돌아왔는데 내가 그에게 무슨 수정을 했는지 물었더니 서버에 필요하지 않은 nfs 서비스가 실행되는 것을 발견하고 그를 멈추었다고 말했다.나는 문제를 해결하는 과정을 그에게 말했다. 그는 이 문제가 발생하는 것은 외부의 공격과 무관하고 내부의 충돌로 인한 것일 수도 있다고 말했다. 그래서 우리는 다시 공동체를public로 바꾸었다.문제를 발견하고 또 나타났어요...nfs를 사용하지 않아서 발생한 고장이기 때문에 nfs와 관계가 있는 것이 틀림없습니다. 나중에 nfs 서비스가 필요하지 않고 nfs 문제를 마운트 해제하는 것을 확인했습니다.
인터넷에서 자료를 찾아보니'인터넷 패키지 분할로 인한 과잉'일 수 있습니다. 다음은 인터넷에서 쓴 자료입니다.
rsize/wsize가 네트워크의 MTU보다 크면 (대부분의 네트워크는 1500입니다. 큰 패키지를 지원하지 않는 경우) IP 패키지는 UDP 프로토콜로 전송할 때 분할됩니다.대량의 IP 패키지 분할은 네트워크 양쪽 끝에 대량의 CPU 자원을 소모하고 네트워크 통신을 더욱 불안정하게 할 수 있다. 왜냐하면 완전한 RPC는 UDP 분할의 모든 패키지를 잃어버렸을 때 전체 RPC를 다시 전송해야 하기 때문이다.RPC의 재전송이 증가하면 시간 지연이 증가합니다.이것은 NFS over UDP 성능의 최대 병목입니다.

만약 당신의 네트워크 토폴로지가 매우 복잡하다면, UDP의 분할 패키지의 경로가 매우 다르고, 서버에 제때에 도착하지 않을 수도 있습니다.커널은 패키지의 캐시에 제한이 있습니다. 최대 값은 ipfrag/_high_thresh 지정.파일/proc/sys/net/ipv4/ipfrag_ 보기 가능high_thresh 및/proc/sys/net/ipv4/ipfrag_low_thresh.처리되지 않은 패키지 수가 ipfrag_를 초과하면high_thresh, 내부 핵은 ipfrag_low_thresh
또 다른 감시 방법은 파일/proc/net/snmp의 IP:ReasmFails입니다.이것은 분할 조합이 실패한 수량입니다. 만약 이 값이 대량의 파일 전송 과정에서 너무 빨리 상승한다면 상술한 문제가 있을 수 있습니다.
NFS 클라이언트를 사용하고 있다면 IP 재구성 실패의 수량을 감시하고 싶을 수도 있습니다. (내부 재구성은 네트워크 조각 데이터를 포함하는 패킷 실패) SNMP 변수 IP-MIB::ipreasmFails를 통해 실현할 수 있습니다. 다음은 간단한 명령입니다.

#snmpwalk localhost -c public IP-MIB::ipReasmFails.0

   
최종적으로 문제가 해결되었지만 또 하나의 의문은 왜 내가 기본적인public를 변경한 후에 정상이 되는지, 보아하니 자료를 다시 조사해야 할 것 같다.