이 페이지에서

2 SNMP 에이전트

2 SNMP 에이전트

개요

프린터, 네트워크 스위치, 라우터 또는 UPS와 같은 장치에서 SNMP 모니터링을 사용하고 싶을 수 있습니다. 이러한 장치들은 일반적으로 SNMP가 활성화되어 있으며, 완전한 운영 체제와 Zabbix 에이전트를 설치하기에는 비실용적입니다.

이러한 장치의 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를 통해 장치 모니터링을 시작하려면 다음 단계를 수행해야 합니다:

단계 1

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

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

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

여기서 '2c'는 SNMP 버전을 나타내므로, 장치에서 SNMP 버전 1을 사용한다면 '1'로 바꿀 수도 있습니다.

이 명령어는 SNMP 문자열 목록과 해당하는 최신 값을 보여줍니다. 만약 결과가 나오지 않는다면 SNMP '커뮤니티'가 표준인 '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" 및 기타로도 표시될 수 있습니다.

2단계

디바이스에 해당하는 호스트를 생성합니다.

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

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

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

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

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

보안 이름을 변경하지 않고 인증 프로토콜, 인증 암호문, 개인 정보 보호 프로토콜 또는 개인 정보 보호 암호문을 변경한 경우, Zabbix에서 해당 SNMPv3 인터페이스가 업데이트될 때 일반적으로 자동으로 적용됩니다. 보안 이름도 변경된 경우에는 모든 매개변수가 즉시 업데이트됩니다.

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

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

프라이버시 프로토콜 지원

운영체제 및 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 서버를 다시 컴파일하세요.

3단계

모니터링을 위한 아이템을 생성합니다.

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

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

매개변수	설명
이름	아이템 이름을 입력하세요.
유형	여기서 SNMP agent를 선택하세요.
키	의미 있는 키를 입력하세요.
호스트 인터페이스	스위치/라우터의 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-PDU)을 비동기적으로 사용합니다. 이 아이템의 타임아웃 설정은 아이템 구성 양식에서 설정할 수 있습니다. 장치에 연결할 수 없을 때 긴 지연을 피하기 위해 낮은 타임아웃 값 설정을 고려하세요. 이전 시도가 타임아웃되거나 실패하면 최대 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 매개변수로 정의됩니다. 어떤 방법으로든 반환되는 네트워크 트래픽 통계의 경우, 전처리 탭에서 초당 변화량 단계를 추가해야 합니다. 그렇지 않으면 최신 변화량 대신 SNMP 장치의 누적 값을 얻게 됩니다.

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

이제 아이템을 저장하고 SNMP 데이터를 확인하기 위해 모니터링 > 최신 데이터로 이동하세요.

예제 1

일반적인 예제:

매개변수	설명
OID	1.2.3.45.6.7.8.0 (or .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

네이티브 SNMP 대량 요청

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

SNMP에서 GetBulk 요청은 여러 GetNext 요청을 실행하고 단일 응답으로 결과를 반환합니다. 이는 네트워크 왕복 횟수를 최소화하기 위해 일반 SNMP 아이템과 SNMP 검색에 모두 사용될 수 있습니다.

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

네이티브 SNMP 대량 요청 사용은 여러 SNMP 요청을 결합하는 Zabbix 고유의 방식인 SNMP 요청 결합 옵션과는 관련이 없다는 점에 주의하세요(다음 섹션 참조).

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

결합 처리의 내부 작동 방식

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

일반 SNMP 아이템
동적 인덱스를 가진 SNMP 아이템
SNMP 저수준 검색 규칙

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

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

"가져오기"의 경우, 최대 128개의 변수 바인딩을 가진 GetRequest-PDU가 사용됩니다. "탐색"의 경우, SNMPv1에는 GetNextRequest-PDU가 사용되고, SNMPv2와 SNMPv3에는 최대 128의 "max-repetitions" 필드를 가진 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 탐색 중에 부분 데이터가 수신되면 아이템이 지원되지 않을 수 있습니다.

다음 단계는?

1 동적 인덱스