2 전처리 세부 사항

개요

이 섹션은 아이템 값 전처리 세부사항을 제공합니다. 아이템 값 전처리를 통해 수신된 아이템 값에 대한 변환 규칙을 정의하고 실행할 수 있습니다.

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

아이템 값 처리

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

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

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

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

• 수집된 데이터가 처리됩니다 - 트리거가 확인되고, 아이템이 NOT SUPPORTED가 되면 아이템 구성이 업데이트됩니다.
• 이는 아이템 값 처리 관점에서 데이터 흐름의 끝으로 간주됩니다.

아이템 값 전처리

데이터 전처리는 다음 단계로 수행됩니다:

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

다이어그램에서 마스터 아이템 전처리는 전처리 캐싱을 건너뛰어 약간 단순화되어 있습니다.

전처리 큐

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

• 대기 중인 작업 목록:

  • 값 전처리 요청에서 직접 생성된 작업들을 수신된 순서대로 처리

• 즉시 처리 작업 목록 (대기 작업보다 먼저 처리됨):

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

• 완료된 작업 목록

전처리 캐싱

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

캐싱은 하나의 종속 항목을 전처리한 후 나머지 종속 항목들에 대해 일부 내부 전처리 데이터를 재사용하는 방식으로 수행됩니다. 전처리 캐시는 다음 유형들의 첫 번째 전처리 단계에서만 지원됩니다:

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

전처리 워커

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

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

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

값 처리 파이프라인

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

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

결과적으로 의존 아이템은 값을 받지만, 마스터 아이템은 상태가 NOT SUPPORTED로 변경됩니다.

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