전처리 상세

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

개요

이 섹션에서는 아이템 값 전처리에 대한 상세 내용을 설명합니다. 아이템 값 전처리를 사용하면 수신된 아이템 값에 대해 변환 규칙을 정의하고 실행할 수 있습니다.

전처리는 전처리 단계를 수행하는 전처리 워커와 함께 전처리 관리자 프로세스가 관리합니다. 전처리가 있는 모든 값(Zabbix 7.4.1 이전에는 모든 값)은 서로 다른 데이터 수집기로부터 수신되어 히스토리 캐시에 추가되기 전에 전처리 관리자를 거칩니다. 데이터 수집기(폴러, 트래퍼 등)와 전처리 프로세스 사이에는 소켓 기반 IPC 통신이 사용됩니다. Zabbix 서버 또는 (프록시가 모니터링하는 아이템의 경우) Zabbix 프록시가 전처리 단계를 수행합니다.

아이템 값 처리

데이터 소스에서 Zabbix 데이터베이스까지의 데이터 흐름을 시각화하기 위해 다음과 같은 간략화된 다이어그램을 사용할 수 있습니다.

위 다이어그램은 아이템 값 처리와 관련된 프로세스, 객체, 동작만을 간략화된 형태로 보여줍니다. 이 다이어그램은 조건에 따른 방향 전환, 오류 처리, 루프는 보여주지 않습니다. 전처리 관리자의 로컬 데이터 캐시 또한 데이터 흐름에 직접적인 영향을 주지 않기 때문에 표시되지 않습니다. 이 다이어그램의 목적은 아이템 값 처리에 관련된 프로세스와 이들의 상호작용 방식을 보여주는 것입니다.

  • 데이터 수집은 데이터 소스로부터 원시 데이터를 가져오는 것으로 시작됩니다. 이 시점에서 데이터는 ID, 타임스탬프, 값(여러 값일 수도 있음)만 포함합니다.
  • 어떤 유형의 데이터 수집기를 사용하든, 능동 또는 수동 체크, 트래퍼 아이템 등에 대해 아이디어는 동일합니다. 다만 데이터 형식과 통신 시작 주체(데이터 수집기가 연결과 데이터를 기다리는지, 아니면 데이터 수집기가 통신을 시작하여 데이터를 요청하는지)만 달라집니다. 원시 데이터는 검증되고, 아이템 설정은 설정 캐시에서 가져옵니다 (데이터가 설정 데이터로 보강됩니다).
  • 데이터 수집기에서 전처리 관리자로 데이터를 전달하는 데 소켓 기반 IPC 메커니즘이 사용됩니다. 이 시점에서 데이터 수집기는 전처리 관리자의 응답을 기다리지 않고 계속해서 데이터를 수집합니다.
  • 데이터 전처리가 수행됩니다. 여기에는 전처리 단계 실행과 종속 아이템 처리가 포함됩니다.

전처리 단계 중 하나라도 실패하면 전처리가 수행되는 동안 아이템 상태가 NOT SUPPORTED로 바뀔 수 있습니다.

  • 전처리 관리자의 로컬 데이터 캐시에 있는 히스토리 데이터는 히스토리 캐시로 플러시됩니다.
  • 이 시점에서 데이터 흐름은 다음 히스토리 캐시 동기화(히스토리 동기화 프로세스가 데이터 동기화를 수행할 때)까지 멈춥니다.
  • 동기화 프로세스는 Zabbix 데이터베이스에 데이터를 저장하기 전에 데이터 정규화로 시작됩니다. 데이터 정규화는 아이템 설정에 정의된 원하는 아이템 유형으로 변환을 수행하며, 여기에는 해당 유형에 허용되는 사전 정의된 크기에 기반한 텍스트 데이터 절삭도 포함됩니다 (문자열의 경우 HISTORY_STR_VALUE_LEN, 텍스트의 경우 HISTORY_TEXT_VALUE_LEN, 로그 값의 경우 HISTORY_LOG_VALUE_LEN). 정규화가 완료된 후 데이터는 Zabbix 데이터베이스로 전송됩니다.

데이터 정규화가 실패하면(예를 들어 텍스트 값을 숫자로 변환할 수 없는 경우) 아이템 상태가 NOT SUPPORTED로 바뀔 수 있습니다.

  • 수집된 데이터가 처리됩니다 - 트리거가 체크되고, 아이템이 NOT SUPPORTED가 되면 아이템 설정이 업데이트되는 등의 작업이 이루어집니다.
  • 이는 아이템 값 처리 관점에서 데이터 흐름의 끝으로 간주됩니다.

아이템 값 전처리

데이터 전처리는 다음과 같은 단계로 수행됩니다.

  • 아이템에 전처리도 없고 종속 아이템도 없는 경우, 값은 히스토리 캐시에 추가되거나 LLD 관리자로 전송됩니다. 그렇지 않으면 아이템 값은 UNIX 소켓 기반 IPC 메커니즘을 사용하여 전처리 관리자로 전달됩니다(Zabbix 7.4.1 이전에는 모든 값이 히스토리 캐시에 추가되거나 LLD 관리자로 전송되기 전에 전처리 관리자를 거쳤습니다).
  • 전처리 작업이 생성되어 큐에 추가되고, 전처리 워커들에게 새 작업에 대한 알림이 전달됩니다.
  • 이 시점에서 데이터 흐름은 사용 가능한(즉, 작업을 실행 중이 아닌) 전처리 워커가 최소 하나 생길 때까지 멈춥니다.
  • 전처리 워커가 사용 가능해지면 큐에서 다음 작업을 가져옵니다.
  • 전처리가 완료되면(전처리 단계의 성공/실패 실행 모두 해당), 전처리된 값은 완료된 작업 큐에 추가되고 관리자에게 새로 완료된 작업이 있다는 알림이 전달됩니다.
  • 전처리 관리자는 결과를 원하는 형식(아이템 값 유형으로 정의됨)으로 변환한 다음 히스토리 캐시에 추가하거나 LLD 관리자로 전송합니다.
  • 처리된 아이템에 종속 아이템이 있는 경우, 전처리된 마스터 아이템 값과 함께 종속 아이템이 전처리 큐에 추가됩니다. 종속 아이템은 일반적인 값 전처리 요청을 우회하여 큐에 추가되지만, 이는 값이 설정되어 있고 NOT SUPPORTED 상태가 아닌 마스터 아이템에 대해서만 해당됩니다.

다이어그램에서는 전처리 캐싱을 생략하여 마스터 아이템 전처리를 약간 단순화했다는 점에 유의하세요.

전처리 큐

전처리 큐는 다음과 같이 구성됩니다.

  • 대기 중인 작업 목록:

    • 값 전처리 요청으로부터 직접 생성된 작업이며 수신된 순서대로 배치됩니다
  • 즉시 처리 작업 목록(대기 중인 작업보다 먼저 처리됨):

    • 테스트 작업(프론트엔드의 아이템/전처리 테스트 요청에 대한 응답으로 생성됨)
    • 종속 아이템 작업
    • 순서 작업(반드시 엄격한 순서로 실행되어야 하는 작업):
      • 마지막 값을 사용하는 전처리 단계를 가진 작업:
        • 변경(change)
        • 스로틀링(throttling)
        • JavaScript(바이트코드 캐싱)
      • 종속 아이템 전처리 캐싱
  • 완료된 작업 목록

전처리 캐싱

전처리 캐싱은 유사한 전처리 단계를 가진 여러 종속 아이템(LLD의 일반적인 결과물)에 대한 전처리 성능을 개선하기 위해 도입되었습니다.

캐싱은 하나의 종속 아이템을 전처리하고 나머지 종속 아이템에 대해 일부 내부 전처리 데이터를 재사용하는 방식으로 이루어집니다. 전처리 캐시는 다음 유형의 첫 번째 전처리 단계에 대해서만 지원됩니다.

  • Prometheus 패턴(메트릭 기준으로 입력을 인덱싱함)
  • JSONPath(데이터를 객체 트리로 파싱하고 첫 번째 표현식 [?(@.path == "value")]를 인덱싱함)

전처리 워커

Zabbix 서버 설정 파일에서는 사용자가 전처리 워커 스레드 수를 설정할 수 있습니다. 전처리 워커의 사전 시작 인스턴스 수를 설정하려면 StartPreprocessors 설정 매개변수를 사용해야 하며, 이는 최소한 사용 가능한 CPU 코어 수와 일치해야 합니다.

전처리 작업이 CPU 바운드가 아니고 빈번한 네트워크 요청을 포함하는 경우, 워커를 추가로 설정하는 것이 권장됩니다. 최적의 전처리 워커 수는 "전처리 가능한" 아이템(전처리 단계 실행이 필요한 아이템) 수, 데이터 수집 프로세스 수, 아이템 전처리의 평균 단계 수 등 여러 요인에 의해 결정될 수 있습니다. 워커가 부족하면 메모리 사용량이 높아질 수 있습니다. Zabbix 설치 환경에서 과도한 메모리 사용량을 문제 해결하려면 tcmalloc을 이용한 과도한 메모리 사용량 프로파일링을 참조하세요.

하지만 대용량 XML/JSON 청크 파싱과 같은 무거운 전처리 작업이 없다고 가정하면, 전처리 워커 수는 데이터 수집기의 총 수와 일치시킬 수 있습니다. 이렇게 하면 (수집기로부터 데이터가 대량으로 들어오는 경우를 제외하고) 대체로 수집된 데이터를 처리할 사용 가능한 전처리 워커가 최소 하나는 있게 됩니다.

너무 많은 데이터 수집 프로세스(폴러, 도달 불가 폴러, ODBC 폴러, HTTP 폴러, Java 폴러, 핑거, 트래퍼, 프록시폴러)와 IPMI 관리자, SNMP 트래퍼, 전처리 워커가 함께 있으면 전처리 관리자의 프로세스당 파일 디스크립터 한도를 초과할 수 있습니다.

프로세스당 파일 디스크립터 한도를 초과하면 Zabbix 서버가 중지되며, 일반적으로 시작 직후 얼마 지나지 않아 발생하지만 때로는 더 오래 걸릴 수도 있습니다. 이러한 문제를 방지하려면 Zabbix 서버 설정 파일을 검토하여 동시 체크 및 프로세스 수를 최적화하세요. 또한 필요한 경우 시스템 한도를 확인하고 조정하여 파일 디스크립터 한도가 충분히 높게 설정되어 있는지 확인하세요.

값 처리 파이프라인

아이템 값 처리는 여러 프로세스에 의해 여러 단계(또는 페이즈)에 걸쳐 실행됩니다. 이로 인해 다음과 같은 상황이 발생할 수 있습니다.

  • 마스터 값은 받지 못했는데 종속 아이템은 값을 받을 수 있습니다. 이는 다음과 같은 사용 사례로 재현될 수 있습니다.
    • 마스터 아이템은 값 유형이 UINT(트래퍼 아이템 사용 가능)이고, 종속 아이템은 값 유형이 TEXT입니다.
    • 마스터와 종속 아이템 모두 전처리 단계가 필요하지 않습니다.
    • 텍스트 값(예: "abc")이 마스터 아이템에 전달됩니다.
    • 실행할 전처리 단계가 없으므로 전처리 관리자는 마스터 아이템이 NOT SUPPORTED 상태가 아닌지와 값이 설정되어 있는지를 확인하고(둘 다 참인 경우) 마스터 아이템과 동일한 값으로 종속 아이템을 큐에 추가합니다(전처리 단계가 없으므로).
    • 마스터 아이템과 종속 아이템 모두 히스토리 동기화 단계에 도달하면, 값 변환 오류(텍스트 데이터를 부호 없는 정수로 변환할 수 없음)로 인해 마스터 아이템이 NOT SUPPORTED 상태가 됩니다.

결과적으로 종속 아이템은 값을 받게 되지만, 마스터 아이템은 NOT SUPPORTED 상태로 바뀝니다.

  • 종속 아이템이 마스터 아이템 히스토리에 존재하지 않는 값을 받는 경우입니다. 이 사용 사례는 마스터 아이템 유형을 제외하면 앞의 경우와 매우 유사합니다. 예를 들어, 마스터 아이템에 CHAR 유형을 사용하는 경우, 마스터 아이템 값은 히스토리 동기화 단계에서 절삭되지만, 종속 아이템은 마스터 아이템의 초기(절삭되지 않은) 값으로부터 값을 받게 됩니다.