SNMP 에이전트

Zabbix v7.4번역일: 2026-09-09원본 보기

개요

프린터, 네트워크 스위치, 라우터, 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회까지 재시도합니다. 재시도 메커니즘은 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 '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" 등으로 표시될 수도 있습니다.

2단계

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

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

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

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

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

SNMPv3

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가 잘못된 경우에는 net-snmp로부터 TIMEOUT 오류를 수신합니다.
SNMP 인터페이스 가용성이 빨간색(사용 불가)으로 바뀝니다.

Security name을 변경하지 않고 Authentication protocol, Authentication passphrase, Privacy protocol, Privacy passphrase를 변경하면, 해당 SNMPv3 인터페이스가 Zabbix에서 업데이트될 때 일반적으로 자동으로 적용됩니다. 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 서버를 재컴파일하세요.

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-PDU)을 비동기적으로 사용합니다. 이 항목의 타임아웃 설정은 항목 구성 양식에서 설정할 수 있습니다. 장치에 접근할 수 없을 때 긴 지연을 피하려면 낮은 타임아웃 값을 설정하는 것을 고려하세요. 이전 시도가 타임아웃되거나 실패하면 최대 5회까지 재시도되기 때문입니다(예: 3초 타임아웃은 15초 대기 시간을 초래할 수 있음). 이 항목을 마스터 항목으로 사용하고, 전처리를 사용해 마스터에서 데이터를 추출하는 종속 항목을 둘 수 있습니다. 단일 snmp walk에서 여러 OID를 지정하는 것이 가능합니다. 예: `walk[OID1,OID2,...]`는 한 번에 하나씩 OID를 비동기적으로 처리합니다. 벌크 요청이 결과를 반환하지 않으면 벌크 요청 없이 단일 레코드를 가져오려고 시도합니다. MIB 이름도 파라미터로 지원됩니다. 따라서 `walk[1.3.6.1.2.1.2.2.1.2]`와 `walk[ifDescr]`는 동일한 출력을 반환합니다. `walk[ifDescr,ifType,ifPhysAddress]`처럼 여러 OID/MIB를 지정하면 출력은 연결된 목록이 됩니다. 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회까지 재시도되기 때문입니다(예: 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로 이동합니다.

예제 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

가동 시간(uptime) 모니터링:

파라미터	설명
OID	MIB::sysUpTime.0
Key	router.uptime
Value type	Float
Units	uptime
Preprocessing step: Custom multiplier	0.01

네이티브 SNMP 벌크 요청

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

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

SNMP walk[OID1,OID2,...] 항목은 한 번의 요청으로 데이터를 수집하는 마스터 항목으로 사용될 수 있으며, 종속 항목은 필요에 따라 전처리를 사용해 응답을 파싱합니다.

네이티브 SNMP 벌크 요청 사용은 SNMP 요청을 결합하는 옵션(Zabbix 자체의 여러 SNMP 요청 결합 방식, 다음 섹션 참고)과는 무관함에 유의하세요.

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

결합 처리의 내부 동작

Zabbix 서버와 프록시는 단일 요청으로 SNMP 장치에서 여러 값을 조회할 수 있습니다. 이는 다음과 같은 여러 유형의 SNMP 항목에 영향을 미칩니다.

동일한 파라미터를 가진 단일 인터페이스상의 모든 SNMP 항목은 동시에 조회되도록 예약됩니다. 앞의 두 항목 유형은 폴러가 최대 128개 항목 단위의 배치로 처리하며, 로우레벨 디스커버리 규칙은 이전과 마찬가지로 개별적으로 처리됩니다.

하위 수준에서는 값을 조회하기 위해 수행되는 작업이 두 가지 있습니다: 지정된 여러 객체를 가져오는 것과 OID 트리를 walk하는 것입니다.

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

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

일반 SNMP 항목은 "getting" 개선의 혜택을 받습니다.
동적 인덱스가 있는 SNMP 항목은 "getting"과 "walking" 개선 모두의 혜택을 받습니다: "getting"은 인덱스 검증에 사용되고 "walking"은 캐시 구축에 사용됩니다.
SNMP 로우레벨 디스커버리 규칙은 "walking" 개선의 혜택을 받습니다.

다만, 모든 장치가 요청당 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 패킷 손실 때문이라고 가정하기 때문입니다.

그러나 장치가 다른 이유로 결합 요청을 제대로 처리하지 못하고 위에서 설명한 휴리스틱이 작동하지 않는 경우, 각 인터페이스마다 해당 장치에 대한 결합 요청을 비활성화할 수 있는 "Use combined requests" 설정이 있습니다.

결합 요청이 부분적이거나 형식이 잘못된 응답을 유발하여 초당(델타) 계산이 잘못되는 경우(예: 인터페이스 카운터에서 겉으로 보이는 급증), 영향을 받는 인터페이스에 대해 Use combined requests를 비활성화하여 항목별로 별도 조회를 강제하세요. 이렇게 하면 대개 잘못된 급증을 방지할 수 있습니다. 또는 비동기적으로 실행되고 인터페이스별 Use combined requests 일괄 처리의 영향을 받지 않는 비동기 get[] 또는 walk[] 항목 사용을 고려하세요. 이를 레거시 동기식 OID 확인 대신 사용하면 결합 요청 관련 문제를 피할 수 있습니다. 영향을 받는 장치를 식별하는 데 도움이 되도록 개요 섹션에 표시된 것과 유사한 서버/프록시 로그 항목을 확인하세요.

추가로, 인터페이스가 자주 사용 불가 상태가 되는 경우 요청 빈도를 줄이기 위해 Zabbix 서버 또는 Zabbix 프록시 구성 파일에서 UnavailableDelay 파라미터를 늘려야 할 수 있습니다. 디스커버리나 OID walk 중에 부분 데이터가 수신되면 항목이 지원되지 않음으로 표시될 수 있습니다.