문서

3 SNMP 에이전트

개요

프린터, 네트워크 스위치, 라우터 또는 UPS와 같이 일반적으로 SNMP가 지원되며 완전한 운영 체제와 Zabbix 에이전트를 설정하는 것이 비실용적인 장치에서 SNMP 모니터링을 사용하고자 할 수 있습니다.

이러한 장치의 SNMP 에이전트에서 제공하는 데이터를 검색할 수 있으려면, Zabbix 서버가 --with-net-snmp 플래그를 지정하여 SNMP 지원으로 초기 구성되어야 합니다. 또한 아이템 값이 올바른 형식으로 표시되도록 MIB 파일을 설치하는 것이 권장됩니다. MIB 파일이 없으면 UTF-8 대신 HEX로 값이 표시되거나 그 반대와 같은 형식 문제가 발생할 수 있습니다.

SNMP 검사는 UDP 프로토콜을 통해서만 수행됩니다.

Zabbix 서버와 프록시 데몬은 잘못된 SNMP 응답을 받으면 다음과 유사한 로그 라인을 기록합니다:

SNMP response from host "gateway" does not contain all of the requested variable bindings

모든 문제 사례를 다루지는 않지만, 결합된 요청을 비활성화해야 하는 개별 SNMP 장치를 식별하는 데 유용합니다.

Zabbix 서버/프록시는 SNMP walk 및 get 아이템에 대해 최대 5회까지 재시도합니다 (Zabbix 7.0.14 이후). 재시도 메커니즘은 DNS 해석 실패에는 적용되지 않습니다.

기존 SNMP 검사(단일 OID 번호 또는 문자열)의 경우 Zabbix 서버/프록시는 실패한 쿼리 시도 후 최소 한 번은 재시도합니다: SNMP 라이브러리의 재시도 메커니즘 또는 내부 결합 처리 메커니즘을 통해.

SNMPv3 장치를 모니터링하는 경우, msgAuthoritativeEngineID(snmpEngineID 또는 "Engine ID"라고도 함)가 두 장치에서 공유되지 않도록 해야 합니다. RFC 2571 (섹션 3.1.1.1)에 따르면 각 장치에 대해 고유해야 합니다.

RFC3414는 SNMPv3 장치가 engineBoots를 지속해야 한다고 요구합니다. 일부 장치는 이를 수행하지 않아 재시작 후 SNMP 메시지가 오래된 것으로 간주되어 폐기되는 결과를 초래합니다. 이러한 상황에서는 서버/프록시에서 SNMP 캐시를 수동으로 지워야 하거나 (-R snmp_cache_reload 사용) 서버/프록시를 재시작해야 합니다.

SNMP 모니터링 구성

SNMP를 통해 장치 모니터링을 시작하려면 다음 단계를 수행해야 합니다:

Step 1

모니터링하려는 항목의 SNMP 문자열(또는 OID)을 찾아보세요.

SNMP 문자열 목록을 가져오려면 snmpwalk 명령어(Zabbix 설치 과정에서 함께 설치해야 하는 net-snmp 소프트웨어의 일부)나 동등한 도구를 사용하세요:

snmpwalk -v 2c -c public <host IP> .

여기서 '2c'는 SNMP 버전을 의미하므로, 장치에서 SNMP 버전 1을 사용하는 경우 '1'로 대체할 수 있습니다.

이렇게 하면 SNMP 문자열과 해당 값의 목록이 표시됩니다. 만약 표시되지 않는다면 SNMP 'community'가 표준 'public'과 다를 가능성이 있으므로 올바른 값을 찾아야 합니다.

그런 다음 목록을 살펴보며 모니터링하려는 문자열을 찾을 수 있습니다. 예를 들어, 스위치의 포트 3으로 들어오는 바이트를 모니터링하려는 경우 다음 줄에서 IF-MIB::ifHCInOctets.3 문자열을 사용합니다:

IF-MIB::ifHCInOctets.3 = Counter64: 3409739121

이제 snmpget 명령어를 사용하여 'IF-MIB::ifHCInOctets.3'에 대한 숫자 OID를 찾을 수 있습니다:

snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3

문자열의 마지막 숫자는 모니터링하려는 포트 번호입니다. 참조: 동적 인덱스.

이렇게 하면 다음과 같은 결과를 얻을 수 있습니다:

.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941

마찬가지로 OID의 마지막 숫자는 포트 번호입니다.

가장 많이 사용되는 SNMP OID 중 일부는 Zabbix에 의해 자동으로 숫자 표현으로 변환됩니다.

위의 마지막 예시에서 값 유형은 "Counter64"로, 내부적으로는 ASN_COUNTER64 유형에 해당합니다. 지원되는 유형의 전체 목록은 ASN_COUNTER, ASN_COUNTER64, ASN_UINTEGER, ASN_UNSIGNED64, ASN_INTEGER, ASN_INTEGER64, ASN_FLOAT, ASN_DOUBLE, ASN_TIMETICKS, ASN_GAUGE, ASN_IPADDRESS, ASN_OCTET_STR 및 ASN_OBJECT_ID입니다. 이러한 유형은 snmpget 출력에서 대략적으로 "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER"에 해당하지만, 표시 힌트의 존재 여부에 따라 "STRING", "Hex-STRING", "OID" 등으로 표시될 수도 있습니다.

Step 2

장치에 해당하는 호스트를 생성합니다.

호스트에 SNMP 인터페이스를 추가합니다:

IP 주소/DNS 이름과 포트 번호를 입력합니다.
드롭다운에서 SNMP version을 선택합니다.
선택한 SNMP 버전에 따라 인터페이스 자격 증명을 추가합니다:
- SNMPv1, v2는 커뮤니티(일반적으로 'public')만 필요합니다.
- SNMPv3는 더 구체적인 옵션이 필요합니다(아래 참조).
네이티브 SNMP 대량 요청(GetBulkRequest-PDU)에 대한 최대 반복 값(기본값: 10)을 지정합니다. SNMPv2 및 v3의 discovery[] 및 walk[] 항목에서만 사용됩니다. 이 값을 너무 높게 설정하면 SNMP 에이전트 확인 타임아웃이 발생할 수 있습니다.
SNMP 요청의 결합 처리를 허용하려면 Use combined requests 체크박스를 선택합니다(네이티브 SNMP 대량 요청 "walk" 및 "get"과는 관련 없음).

SNMPv3 매개변수	설명
Context name	SNMP 서브넷에서 항목을 식별할 컨텍스트 이름을 입력합니다. 이 필드에서는 사용자 매크로가 해석됩니다.
Security name	보안 이름을 입력합니다. 이 필드에서는 사용자 매크로가 해석됩니다.
Security level	보안 수준을 선택합니다: noAuthNoPriv - 인증 및 프라이버시 프로토콜을 사용하지 않음 AuthNoPriv - 인증 프로토콜을 사용하지만 프라이버시 프로토콜은 사용하지 않음 AuthPriv - 인증 및 프라이버시 프로토콜을 모두 사용
Authentication protocol	인증 프로토콜을 선택합니다 - MD5, SHA1; net-snmp 5.8 이상에서는 SHA224, SHA256, SHA384 또는 SHA512.
Authentication passphrase	인증 암호를 입력합니다. 이 필드에서는 사용자 매크로가 해석됩니다.
Privacy protocol	프라이버시 프로토콜을 선택합니다 - DES, AES128, AES192, AES256, AES192C (Cisco) 또는 AES256C (Cisco). 프라이버시 프로토콜 지원에 대한 참고사항을 참조하세요
Privacy passphrase	프라이버시 암호를 입력합니다. 이 필드에서는 사용자 매크로가 해석됩니다.

잘못된 SNMPv3 자격 증명(보안 이름, 인증 프로토콜/암호, 프라이버시 프로토콜)의 경우:

Zabbix는 net-snmp로부터 ERROR를 받습니다. 단, 잘못된 Privacy passphrase의 경우 Zabbix는 net-snmp로부터 TIMEOUT 오류를 받습니다.
SNMP 인터페이스 가용성이 빨간색(사용 불가)으로 전환됩니다.

Security name을 변경하지 않고 Authentication protocol, Authentication passphrase, Privacy protocol 또는 Privacy passphrase를 변경하면, Zabbix에서 해당 SNMPv3 인터페이스가 업데이트될 때 일반적으로 자동으로 적용됩니다. Security name도 변경된 경우, 모든 매개변수가 즉시 업데이트됩니다.

제공된 SNMP 템플릿 중 하나를 사용하여 항목 집합을 자동으로 추가할 수 있습니다. 템플릿을 사용하기 전에 해당 호스트와 호환되는지 확인하세요.

호스트를 저장하려면 Add를 클릭합니다.

개인정보 보호 프로토콜 지원

운영 체제 및 net-snmp 구성에 따라 일부 개인정보 보호 프로토콜을 사용할 수 없을 수 있습니다:

일부 최신 운영 체제(예: RHEL9)에서는 net-snmp 패키지에 대한 DES 지원이 제거되었습니다.
AES192 및 더 강력한 암호화 프로토콜은 RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04, openSUSE Leap 15.5보다 오래된 운영 체제에서는 기본적으로 지원되지 않습니다.

net-snmp 라이브러리가 AES192+를 지원하는지 확인하려면 다음 옵션 중 하나를 사용하십시오:

net-snmp-config:

net-snmp-config --configure-options

출력에 --enable-blumenthal-aes가 포함되어 있으면 AES192+가 지원됩니다.

net-snmp-config는 SNMP용 개발 패키지(Debian/Ubuntu의 경우 libsnmp-dev, CentOS/RHEL/OL/SUSE의 경우 net-snmp-devel)의 일부이며 기본적으로 설치되어 있지 않을 수 있습니다.

snmpget:

snmpget -v 3 -x AES-256

출력에 Invalid privacy protocol specified after -3x flag: AES-256이 포함되어 있으면 AES192+가 지원되지 않습니다. 출력에 No hostname specified.가 포함되어 있으면 AES192+가 지원되지 않습니다.

net-snmp 라이브러리가 AES192 및 더 높은 프로토콜을 지원하지 않는 경우, --enable-blumenthal-aes 옵션으로 net-snmp를 다시 컴파일한 다음 --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config 옵션을 지정하여 Zabbix 서버를 다시 컴파일하십시오.

Step 3

모니터링을 위한 아이템을 생성하세요.

이제 Zabbix로 돌아가서 이전에 생성한 SNMP 호스트에 대한 Items를 클릭하세요. 호스트를 생성할 때 템플릿을 사용했는지 여부에 따라, 호스트와 연결된 SNMP 아이템 목록이 있거나 빈 목록이 표시됩니다. snmpwalk 및 snmpget을 사용하여 방금 수집한 정보를 사용하여 직접 아이템을 생성한다고 가정하고, Create item을 클릭하세요.

새 아이템 폼에서 필수 매개변수를 입력하세요:

매개변수	설명
Name	아이템 이름을 입력하세요.
Type	여기에서 SNMP agent를 선택하세요.
Key	의미 있는 키를 입력하세요.
Host interface	스위치/라우터의 SNMP 인터페이스를 선택했는지 확인하세요.
SNMP OID	지원되는 형식 중 하나를 사용하여 OID 값을 입력하세요: walk[OID1,OID2,...] - 값의 하위 트리를 검색합니다. 예: `walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3]`. 이 옵션은 네이티브 SNMP 벌크 요청 (GetBulkRequest-PDUs)을 비동기적으로 사용합니다. 이 아이템의 타임아웃 설정은 아이템 구성 폼에서 설정할 수 있습니다. 장치에 연결할 수 없는 경우 긴 지연을 피하기 위해 낮은 타임아웃 값 설정을 고려하세요. 이전 시도가 타임아웃되거나 실패할 경우 최대 5번까지 재시도합니다 (Zabbix 7.0.14부터) (예: 3초 타임아웃은 15초 대기 시간을 초래할 수 있습니다). 이를 마스터 아이템으로 사용하고, 전처리를 사용하여 마스터에서 데이터를 추출하는 종속 아이템을 사용할 수 있습니다. 단일 snmp walk에서 여러 OID를 지정하는 것이 가능합니다. 예를 들어 `walk[OID1,OID2,...]`와 같이 한 번에 하나의 OID를 비동기적으로 처리할 수 있습니다. 벌크 요청이 결과를 반환하지 않으면 벌크 요청 없이 단일 레코드를 검색하려고 시도합니다. MIB 이름이 매개변수로 지원되므로 `walk[1.3.6.1.2.1.2.2.1.2]`와 `walk[ifDescr]`은 동일한 출력을 반환합니다. 여러 OID/MIB가 지정된 경우, 즉 `walk[ifDescr,ifType,ifPhysAddress]`인 경우 출력은 연결된 목록입니다. GetBulk 요청은 SNMPv2 및 v3 인터페이스에 사용되고 GetNext는 SNMPv1 인터페이스에 사용됩니다. 벌크 요청의 최대 반복은 인터페이스 수준에서 구성됩니다. 최대 반복 매개변수는 단일 벌크 응답에서 반환되는 최대 OID 수를 결정하여 벌크 요청에 영향을 줍니다. 더 높은 값은 더 큰 벌크 응답을 생성하여 필요한 전송 횟수를 줄입니다. 그러나 모든 장치가 매우 높은 값을 지원하지 않을 수 있으며, 이는 문제를 일으킬 수 있습니다. 이 아이템은 -Oe -Ot -On 매개변수와 함께 snmpwalk 유틸리티의 출력을 반환합니다. 이 아이템을 SNMP 발견의 마스터 아이템으로 사용할 수 있습니다. get[OID] - 단일 값을 비동기적으로 검색합니다. 예: `get[1.3.6.1.2.1.31.1.1.1.6.3]` 이 아이템의 타임아웃 설정은 아이템 구성 폼에서 설정할 수 있습니다. 장치에 연결할 수 없는 경우 긴 지연을 피하기 위해 낮은 타임아웃 값 설정을 고려하세요. 이전 시도가 타임아웃되거나 실패할 경우 최대 5번까지 재시도합니다 (Zabbix 7.0.14부터) (예: 3초 타임아웃은 15초 대기 시간을 초래할 수 있습니다). OID - (레거시) 단일 텍스트 또는 숫자 OID를 입력하여 단일 값을 동기적으로 검색하며, 선택적으로 다른 값과 결합할 수 있습니다. 예: `1.3.6.1.2.1.31.1.1.1.6.3`. 이 옵션의 경우 아이템 확인 타임아웃은 서버 구성 파일에 설정된 값과 같습니다. 더 나은 성능을 위해 `walk[OID]` 및 `get[OID]` 아이템 사용을 권장합니다. 모든 `walk[OID]` 및 `get[OID]` 아이템은 비동기적으로 실행됩니다 - 다른 확인이 시작되기 전에 하나의 요청에 대한 응답을 받을 필요가 없습니다. DNS 해석도 비동기적입니다. 비동기 확인의 최대 동시성은 1000개입니다 (MaxConcurrentChecksPerPoller로 정의). 비동기 SNMP 폴러의 수는 StartSNMPPollers 매개변수로 정의됩니다. 모든 방법에서 반환되는 네트워크 트래픽 통계의 경우, Preprocessing 탭에서 Change per second 단계를 추가해야 합니다. 그렇지 않으면 최신 변경 사항 대신 SNMP 장치에서 누적 값을 얻게 됩니다.

모든 필수 입력 필드는 빨간 별표로 표시됩니다.

이제 아이템을 저장하고 SNMP 데이터에 대한 Monitoring > Latest data로 이동하세요.

Example 1

일반 예시:

매개변수	설명
OID	1.2.3.45.6.7.8.0 (또는 .1.2.3.45.6.7.8.0)
Key	<트리거에 대한 참조로 사용할 고유 문자열> 예를 들어, "my_param".

OID는 숫자 형태나 문자열 형태로 제공될 수 있습니다. 하지만 일부 경우에는 문자열 OID를 숫자 표현으로 변환해야 합니다. 이 목적을 위해 snmpget 유틸리티를 사용할 수 있습니다:

snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0

예제 2

업타임 모니터링:

매개변수	설명
OID	MIB::sysUpTime.0
Key	router.uptime
Value type	Float
Units	uptime
전처리 단계: 사용자 정의 승수	0.01

Native SNMP bulk requests

walk[OID1,OID2,...] 아이템은 SNMP 버전 2/3에서 사용할 수 있는 대량 요청(GetBulkRequest-PDUs)을 위한 네이티브 SNMP 기능을 사용할 수 있게 해줍니다.

SNMP의 GetBulk 요청은 여러 GetNext 요청을 실행하고 결과를 단일 응답으로 반환합니다. 이는 네트워크 왕복을 최소화하기 위해 일반 SNMP 아이템뿐만 아니라 SNMP 디스커버리에도 사용할 수 있습니다.

SNMP walk[OID1,OID2,...] 아이템은 하나의 요청으로 데이터를 수집하는 마스터 아이템으로 사용될 수 있으며, 종속 아이템이 전처리를 사용하여 필요에 따라 응답을 파싱할 수 있습니다.

네이티브 SNMP 대량 요청 사용은 SNMP 요청을 결합하는 옵션과는 관련이 없으며, 후자는 여러 SNMP 요청을 결합하는 Zabbix만의 방법입니다(다음 섹션 참조).

패킷 중 하나가 손실될 경우 실패를 방지하기 위해 SNMP 대량 아이템에 대해 최대 5회 재시도(Zabbix 7.0.14부터)가 발생합니다. get 및 walk을 사용하는 SNMP 아이템의 타임아웃(아이템 구성 양식에서 설정)은 전체 세션에 대해 설정됩니다. 데이터가 완전히 검색되었는지 여부에 관계없이 타임아웃이 적용되며, 데이터가 부분적으로 수신된 경우(예: 여러 OID 중 하나에 대해서만 데이터가 성공적으로 수집된 경우) 아이템은 "Only partial data received" 메시지와 함께 지원되지 않음으로 변경됩니다. 타임아웃에 도달하면 재시도가 발생하고, 타임아웃이 재설정되며, 마지막 요청이 다시 전송되어 단일 패킷이 손실되거나 너무 늦게 도착한 경우 마지막 요청부터 세션을 계속할 수 있습니다. 이전 시도가 타임아웃되거나 실패할 경우 최대 5회 재시도가 이루어지므로, 장치에 접근할 수 없는 경우 긴 지연을 방지하기 위해 낮은 타임아웃 값을 설정하는 것을 고려하십시오(예: 3초 타임아웃은 15초 대기 시간을 초래할 수 있습니다).

결합 처리의 내부 작동 원리

Zabbix 서버와 프록시는 단일 요청으로 SNMP 장치에서 여러 값을 조회할 수 있습니다. 이는 여러 유형의 SNMP 아이템에 영향을 줍니다:

일반 SNMP 아이템
동적 인덱스를 사용하는 SNMP 아이템
SNMP 저수준 탐지 규칙

동일한 인터페이스에서 동일한 매개변수를 가진 모든 SNMP 아이템은 동시에 조회되도록 예약됩니다. 처음 두 유형의 아이템은 최대 128개 아이템 배치로 폴러에 의해 처리되는 반면, 저수준 탐지 규칙은 이전과 같이 개별적으로 처리됩니다.

하위 수준에서는 값을 조회하기 위해 두 가지 종류의 작업이 수행됩니다: 지정된 여러 객체 가져오기와 OID 트리 탐색입니다.

"가져오기"의 경우, 최대 128개의 변수 바인딩을 가진 GetRequest-PDU가 사용됩니다. "탐색"의 경우, SNMPv1에는 GetNextRequest-PDU가 사용되고, SNMPv2와 SNMPv3에는 "max-repetitions" 필드가 최대 128인 GetBulkRequest가 사용됩니다.

따라서 각 SNMP 아이템 유형에 대한 결합 처리의 이점은 다음과 같습니다:

일반 SNMP 아이템은 "가져오기" 개선 사항의 이점을 얻습니다;
동적 인덱스를 사용하는 SNMP 아이템은 "가져오기"와 "탐색" 개선 사항 모두의 이점을 얻습니다: "가져오기"는 인덱스 검증에 사용되고 "탐색"은 캐시 구축에 사용됩니다;
SNMP 저수준 탐지 규칙은 "탐색" 개선 사항의 이점을 얻습니다.

하지만 모든 장치가 요청당 128개 값을 반환할 수 있는 것은 아니라는 기술적 문제가 있습니다. 일부는 항상 적절한 응답을 반환하지만, 다른 장치들은 잠재적 응답이 특정 한계를 초과하면 "tooBig(1)" 오류로 응답하거나 전혀 응답하지 않습니다.

주어진 장치에 대해 조회할 객체의 최적 수를 찾기 위해 Zabbix는 다음 전략을 사용합니다. 요청에서 1개 값을 조회하는 것부터 신중하게 시작합니다. 성공하면 요청에서 2개 값을 조회합니다. 다시 성공하면 요청에서 3개 값을 조회하고, 조회되는 객체 수를 1.5배씩 곱하여 비슷하게 계속하여 다음과 같은 요청 크기 순서가 됩니다: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

하지만 장치가 적절한 응답을 거부하면(예를 들어, 42개 변수에 대해) Zabbix는 두 가지를 수행합니다.

먼저 현재 아이템 배치에 대해 단일 요청의 객체 수를 절반으로 줄이고 21개 변수를 조회합니다. 장치가 작동 중이라면, 28개 변수가 작동하는 것으로 알려져 있고 21개는 그보다 훨씬 적기 때문에 대부분의 경우 조회가 작동해야 합니다. 하지만 그것도 실패하면 Zabbix는 값을 하나씩 조회하는 방식으로 돌아갑니다. 이 시점에서도 여전히 실패한다면 장치가 확실히 응답하지 않는 것이며 요청 크기는 문제가 아닙니다.

Zabbix가 후속 아이템 배치에 대해 수행하는 두 번째 작업은 마지막으로 성공한 변수 수(우리 예에서는 28)부터 시작하여 한계에 도달할 때까지 요청 크기를 1씩 증가시키는 것입니다. 예를 들어, 가장 큰 응답 크기가 32개 변수라고 가정하면 후속 요청의 크기는 29, 30, 31, 32, 33이 됩니다. 마지막 요청은 실패하고 Zabbix는 크기 33의 요청을 다시는 발행하지 않습니다. 그 시점부터 Zabbix는 이 장치에 대해 최대 32개 변수만 조회합니다.

이 변수 수로 대용량 조회가 실패한다면 두 가지 중 하나를 의미할 수 있습니다. 장치가 응답 크기를 제한하는 데 사용하는 정확한 기준은 알 수 없지만, 변수 수를 사용하여 이를 근사화하려고 합니다. 따라서 첫 번째 가능성은 이 변수 수가 일반적인 경우 장치의 실제 응답 크기 한계 근처에 있다는 것입니다: 때로는 응답이 한계보다 작고, 때로는 그보다 클 수 있습니다. 두 번째 가능성은 양방향의 UDP 패킷이 단순히 손실되었다는 것입니다. 이러한 이유로 Zabbix가 실패한 조회를 받으면 장치의 안전한 범위를 더 깊이 들어가려고 최대 변수 수를 줄이지만, 최대 두 번까지만 합니다.

위 예에서 32개 변수를 사용한 조회가 실패하면 Zabbix는 개수를 31개로 줄입니다. 그것도 실패하면 Zabbix는 개수를 30개로 줄입니다. 하지만 Zabbix는 개수를 30개 아래로 줄이지 않습니다. 추가 실패는 장치의 한계가 아닌 UDP 패킷 손실 때문이라고 가정하기 때문입니다.

하지만 장치가 다른 이유로 결합 요청을 제대로 처리할 수 없고 위에서 설명한 휴리스틱이 작동하지 않는다면, 각 인터페이스에 대해 해당 장치의 결합 요청을 비활성화할 수 있는 "결합 요청 사용" 설정이 있습니다.

결합 요청이 부분적이거나 잘못된 형식의 응답을 일으켜 잘못된 초당(델타) 계산(예: 인터페이스 카운터의 명백한 스파이크)을 초래한다면, 영향받은 인터페이스에 대해 결합 요청 사용을 비활성화하여 아이템별 개별 조회를 강제하십시오. 이렇게 하면 종종 거짓 스파이크를 방지할 수 있습니다. 또는 비동기적으로 실행되고 인터페이스별 결합 요청 사용 배치의 영향을 받지 않는 비동기 get[] 또는 walk[] 아이템을 사용하는 것을 고려해보십시오. 이들은 결합 요청 관련 문제를 피하기 위해 레거시 동기식 OID 확인 대신 사용할 수 있습니다. 영향받은 장치를 식별하는 데 도움이 되도록 개요 섹션에 표시된 것과 유사한 서버/프록시 로그 항목을 찾아보십시오.

또한 인터페이스가 자주 사용할 수 없게 되는 경우, 요청 빈도를 줄이기 위해 Zabbix 서버 또는 Zabbix 프록시 구성 파일에서 UnavailableDelay 매개변수를 증가시킬 필요가 있을 수 있습니다. 탐지 또는 OID 탐색 중에 부분 데이터가 수신되면 아이템이 지원되지 않을 수 있습니다.