1 Network discovery

원본 보기

1 네트워크 디스커버리

개요

Zabbix는 효과적이고 매우 유연한 자동 네트워크 검색 기능을 제공합니다.

네트워크 검색을 적절히 설정하면 다음과 같은 이점을 얻을 수 있습니다:

  • Zabbix 배포 속도 향상
  • 관리 간소화
  • 과도한 관리 없이 빠르게 변하는 환경에서 Zabbix 사용

Zabbix 네트워크 검색은 다음 정보를 기반으로 합니다:

  • IP 범위
  • 외부 서비스 가용성 (FTP, SSH, WEB, POP3, IMAP, TCP 등)
  • Zabbix agent로부터 받은 정보 (암호화되지 않은 모드만 지원)
  • SNMP agent로부터 받은 정보

다음 기능은 제공하지 않습니다:

  • 네트워크 토폴로지 검색

네트워크 검색은 기본적으로 검색과 작업, 두 단계로 구성됩니다.

디스커버리

Zabbix는 네트워크 디스커버리 규칙에 정의된 IP 범위를 주기적으로 스캔합니다. 확인 빈도는 각 규칙별로 개별 설정이 가능합니다.

각 규칙에는 IP 범위에 대해 수행할 서비스 확인 세트가 정의되어 있습니다.

디스커버리 규칙은 디스커버리 매니저에 의해 처리됩니다. 디스커버리 매니저는 작업 목록(네트워크 확인)과 함께 각 규칙별로 작업을 생성합니다. 네트워크 확인은 사용 가능한 디스커버리 워커들에 의해 병렬로 수행됩니다 (워커 수는 각 규칙별로 프론트엔드에서 설정 가능합니다). 일부 장치는 동일한 포트에 병렬 연결을 허용하지 않기 때문에 동일한 IP와 포트를 가진 확인만 순차적으로 예약됩니다.

네트워크 확인의 큐 크기는 약 2000000개 또는 4GB 메모리로 제한됩니다. 큐가 가득 차면 디스커버리 규칙은 건너뛰어지고 로그에 경고 메시지가 출력됩니다. 큐에 있는 디스커버리 확인 수를 모니터링하려면 zabbix[discovery_queue] 내부 아이템을 사용할 수 있습니다.

디스커버리 확인은 다른 확인과 독립적으로 처리됩니다. 어떤 확인이 서비스를 찾지 못하거나 실패하더라도 다른 확인들은 여전히 처리됩니다.

실행 중에 디스커버리 규칙이 변경되면 현재 디스커버리 실행이 중단됩니다.

네트워크 디스커버리 모듈에 의해 수행되는 서비스와 호스트(IP)의 모든 확인은 디스커버리 이벤트를 생성합니다.

이벤트 서비스 확인 결과
Service Discovered 서비스가 'down' 상태였다가 'up' 상태가 되었거나 처음 발견된 경우
Service Up 서비스가 이미 'up' 상태였고 계속 'up' 상태인 경우
Service Lost 서비스가 'up' 상태였다가 'down' 상태가 된 경우
Service Down 서비스가 이미 'down' 상태였고 계속 'down' 상태인 경우
Host Discovered 호스트의 모든 서비스가 'down' 상태였다가 최소 하나의 서비스가 'up' 상태가 되었거나, 등록되지 않은 호스트에 속한 서비스가 발견된 경우
Host Up 이미 최소 하나의 서비스가 'up' 상태였고, 계속해서 최소 하나의 서비스가 'up' 상태인 경우
Host Lost 최소 하나의 서비스가 'up' 상태였다가 호스트의 모든 서비스가 'down' 상태가 된 경우
Host Down 호스트의 모든 서비스가 이미 'down' 상태였고 계속 'down' 상태인 경우

액션

디스커버리 이벤트는 다음과 같은 관련 액션의 기반이 될 수 있습니다:

  • 알림 발송
  • 호스트 추가/제거
  • 호스트 활성화/비활성화
  • 그룹에 호스트 추가
  • 그룹에서 호스트 제거
  • 호스트에 태그 추가
  • 호스트에서 태그 제거
  • 호스트에 템플릿 연결/호스트에서 템플릿 연결 해제
  • 원격 스크립트 실행

이러한 액션들은 디바이스 유형, IP, 상태, 가동시간/중단시간 등과 관련하여 구성할 수 있습니다. 네트워크 디스커버리 기반 이벤트에 대한 액션 구성의 자세한 내용은 액션 operationconditions 페이지를 참조하세요.

네트워크 디스커버리 액션은 이벤트 기반이므로, 발견된 호스트가 온라인일 때와 오프라인일 때 모두 트리거됩니다. Service Lost/Service Down 이벤트 시 Add host와 같은 액션이 트리거되는 것을 방지하기 위해 액션 조건 Discovery status: up을 추가하는 것을 강력히 권장합니다. 그렇지 않으면, 발견된 호스트가 수동으로 제거되더라도 여전히 Service Lost/Service Down 이벤트가 생성되고 다음 디스커버리 주기 동안 재생성됩니다.

발견된 호스트에 템플릿을 연결하는 것은 연결 가능한 템플릿 중 하나가 호스트나 다른 연결 가능한 템플릿에 이미 존재하는 고유 엔티티(예: item key)와 동일한 고유 엔티티(예: item key)를 가지고 있는 경우 전체적으로 실패합니다.

호스트 생성

호스트 추가 작업이 선택되면 호스트가 추가됩니다. 호스트 추가 작업이 없더라도 호스트에서 수행되는 동작을 야기하는 작업을 선택하면 호스트가 추가됩니다. 이러한 작업들은 다음과 같습니다:

  • 호스트 활성화
  • 호스트 비활성화
  • 호스트 그룹에 호스트 추가
  • 호스트에 템플릿 연결

생성된 호스트는 발견된 호스트 그룹에 추가됩니다 (기본값, 관리 > 일반 > 기타에서 구성 가능). 호스트를 다른 그룹에 추가하려면 호스트 그룹에서 제거 작업("발견된 호스트" 지정)을 추가하고 호스트 그룹에 추가 작업(다른 호스트 그룹 지정)도 추가해야 합니다. 호스트는 반드시 호스트 그룹에 속해야 하기 때문입니다.

발견된 장치의 IP 주소는 발견 소스(Zabbix 서버, Zabbix 프록시, 또는 프록시 그룹) 및 인터페이스 유형과 함께 시스템에서 호스트를 찾는 기준으로 사용됩니다. 동일한 IP 주소, 인터페이스 유형 및 발견 소스를 가진 호스트가 이미 존재하면 해당 호스트가 작업을 수행할 대상이 됩니다. 발견 소스가 다르면 발견된 개체는 다른 호스트로 취급되며 새로운 호스트가 생성될 수 있습니다.

발견된 호스트의 IP 주소가 변경되거나 인터페이스가 삭제되면 다음 발견 시 새로운 호스트가 생성됩니다.

호스트 명명

호스트를 추가할 때, 호스트 이름은 역방향 DNS 조회의 결과이거나 역방향 조회에 실패할 경우 IP 주소입니다. 조회는 탐지를 수행하는 주체에 따라 Zabbix 서버 또는 Zabbix 프록시에서 수행됩니다. 프록시에서 조회에 실패하면, 서버에서 재시도하지 않습니다. 해당 이름의 호스트가 이미 존재하는 경우, 다음 호스트는 이름에 _2가 추가되고, 그 다음은 _3 등이 추가됩니다.

또한 DNS/IP 조회를 재정의하고 대신 호스트 이름에 아이템 값을 사용하는 것도 가능합니다. 예를 들어:

  • 탐지를 위해 Zabbix 에이전트 아이템을 사용하여 Zabbix 에이전트가 실행 중인 여러 서버를 발견하고, 이 아이템이 반환하는 문자열 값에 기반하여 자동으로 적절한 이름을 할당할 수 있습니다
  • 탐지를 위해 SNMP 에이전트 아이템을 사용하여 여러 SNMP 네트워크 장치를 발견하고, 이 아이템이 반환하는 문자열 값에 기반하여 자동으로 적절한 이름을 할당할 수 있습니다

호스트 이름이 아이템 값을 사용하여 설정된 경우, 이후 탐지 검사 중에는 업데이트되지 않습니다. 아이템 값을 사용하여 호스트 이름을 설정할 수 없는 경우, 기본값(DNS 이름)이 사용됩니다.

발견된 IP 주소와 탐지 소스(Zabbix 서버, 프록시 또는 프록시 그룹)가 변경되지 않은 호스트가 이미 존재하는 경우, 새 호스트가 생성되지 않습니다. 탐지 소스가 다른 경우, 발견된 엔티티는 별개로 취급되어 새 호스트가 생성될 수 있습니다. 그러나 탐지 액션에 작업(템플릿 연결, 호스트 그룹에 추가 등)이 포함된 경우, 이는 IP 주소, 인터페이스 유형 및 탐지 소스로 일치하는 기존 호스트에서 수행됩니다.

호스트 제거

네트워크 검색 규칙으로 발견된 호스트는 검색된 엔터티가 더 이상 규칙의 IP 범위에 없는 경우 Monitoring > Discovery에서 자동으로 제거됩니다. 호스트는 즉시 제거됩니다.

호스트 추가 시 인터페이스 생성

네트워크 검색의 결과로 호스트가 추가될 때, 다음 규칙에 따라 인터페이스가 생성됩니다:

  • 감지된 서비스 - 예를 들어, SNMP 확인이 성공하면 SNMP 인터페이스가 생성됩니다.
  • 호스트가 Zabbix 에이전트와 SNMP 요청 모두에 응답하면, 두 가지 유형의 인터페이스가 모두 생성됩니다.
  • 고유성 기준이 Zabbix 에이전트 또는 SNMP에서 반환된 데이터인 경우, 호스트에 대해 찾은 첫 번째 인터페이스가 기본 인터페이스로 생성됩니다. 다른 IP 주소들은 추가 인터페이스로 추가됩니다. 액션의 조건(예: 호스트 IP)은 인터페이스 추가에 영향을 주지 않습니다. 참고로 이것은 모든 인터페이스가 동일한 검색 규칙에 의해 발견되는 경우에만 작동합니다. 다른 검색 규칙이 동일한 호스트의 다른 인터페이스를 발견하면 추가 호스트가 추가됩니다.
  • 호스트가 에이전트 확인에만 응답하면, 에이전트 인터페이스만으로 생성됩니다. 나중에 SNMP에 응답하기 시작하면 추가 SNMP 인터페이스가 추가됩니다.
  • 3개의 별도 호스트가 처음에 "IP" 고유성 기준에 의해 발견되어 생성되었고, 그 후 검색 규칙이 수정되어 호스트 A, B, C가 동일한 고유성 기준 결과를 갖게 되면, B와 C는 첫 번째 호스트인 A의 추가 인터페이스로 생성됩니다. 개별 호스트 B와 C는 그대로 남아있습니다. 모니터링 > 검색에서 추가된 인터페이스는 "검색된 장치" 열에 검은색 글꼴로 들여쓰기되어 표시되지만, "모니터링 호스트" 열에는 첫 번째로 생성된 호스트인 A만 표시됩니다. 추가 인터페이스로 간주되는 IP의 경우 "가동시간/중단시간"은 측정되지 않습니다.

프록시 설정 변경

서로 다른 프록시에서 발견한 호스트가 항상 다른 호스트로 처리되는 것은 아닙니다. 검색 및 고유성 검사는 프록시 그룹 구조에 따라 달라집니다. 프록시가 검색 규칙을 실행하고 호스트를 생성하면, 해당 호스트는 프록시 자체에 할당되는 것이 아니라 프록시의 상위 프록시 그룹에 추가됩니다. Zabbix가 검색 중에 IP 고유성을 평가할 때, 상위 프록시 그룹에서 모니터링하는 호스트를 확인합니다. 해당 그룹 내의 개별 프록시에서 모니터링하는 호스트(검색을 실행한 프록시 포함)는 고유성 검사에서 무시되며, 이로 인해 여러 프록시가 겹치는 서브넷을 모니터링하는 경우 중복 호스트가 발생할 수 있습니다.

이러한 동작은 서로 다른 서브넷에서 사용하는 겹치는 IP 범위에서 검색이 작동할 수 있도록 하지만, 이미 모니터링 중인 서브넷에 할당된 프록시를 변경하는 것은 중복을 피하기 위해 발견된 호스트와 상위 프록시 그룹의 멤버십에 일관되게 프록시 변경을 적용해야 하므로 더 복잡합니다.

예를 들어 검색 규칙에서 프록시를 교체하는 단계는 다음과 같습니다:

  1. 검색 규칙 비활성화
  2. 프록시 구성 동기화
  3. 검색 규칙의 프록시 교체
  4. 이 규칙으로 발견된 모든 호스트의 프록시 교체 (중복을 피하기 위해 상위 프록시 그룹의 호스트와 해당 그룹 내 개별 프록시에서 모니터링하는 모든 호스트가 업데이트되도록 확인)
  5. 검색 규칙 활성화