로그 파일 모니터링

개요

Zabbix는 로그 로테이션 지원 여부와 관계없이 로그 파일을 중앙에서 모니터링하고 분석하는 데 사용할 수 있습니다.

로그 파일에 특정 문자열이나 문자열 패턴이 포함되어 있을 때 알림을 통해 사용자에게 경고할 수 있습니다.

로그 파일을 모니터링하려면 다음이 필요합니다:

• 호스트에서 실행 중인 Zabbix agent
• 설정된 로그 모니터링 아이템

구성

에이전트 매개변수 확인

에이전트 구성 파일에서 다음 사항을 확인하십시오:

• Hostname 매개변수가 프런트엔드의 호스트 이름과 일치합니다.
• ServerActive 매개변수에 활성 검사를 처리할 서버가 지정되어 있습니다.

아이템 구성

로그 모니터링 아이템을 구성합니다.

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

로그 모니터링 아이템에는 다음을 입력합니다:

중요 참고 사항

• 서버와 에이전트는 모니터링되는 로그의 크기와 마지막 수정 시간(logrt의 경우)을 두 개의 카운터에 기록합니다. 또한:
  • 에이전트는 로그 파일이 잘리거나 로테이션될 때 더 정확하게 판단하기 위해 내부적으로 inode 번호(UNIX/GNU/Linux), 파일 인덱스(Microsoft Windows), 로그 파일의 처음 512바이트에 대한 MD5 합계도 사용합니다.
  • UNIX/GNU/Linux 시스템에서는 로그 파일이 저장된 파일 시스템이 파일 추적에 사용할 수 있는 inode 번호를 보고한다고 가정합니다.
  • Microsoft Windows에서 Zabbix agent는 로그 파일이 있는 파일 시스템 유형을 확인하고 다음을 사용합니다:
    • NTFS 파일 시스템에서는 64비트 파일 인덱스.
    • ReFS 파일 시스템에서는(Microsoft Windows Server 2012부터만) 128비트 파일 ID.
    • 파일 인덱스가 변경되는 파일 시스템(예: FAT32, exFAT)에서는 로그 파일 로테이션으로 인해 마지막 수정 시간이 같은 로그 파일이 여러 개 생기는 불확실한 상황을 합리적으로 처리하기 위해 대체 알고리즘을 사용합니다.
  • inode 번호, 파일 인덱스 및 MD5 합계는 Zabbix agent가 내부적으로 수집합니다. 이 정보는 Zabbix server로 전송되지 않으며 Zabbix agent가 중지되면 손실됩니다.
  • 로그 파일의 마지막 수정 시간을 변경하지 말고(예: touch 사용), 파일을 원래 이름으로 다시 복사하여 모니터링되는 로그 파일을 교체하지 마십시오(새 inode가 생성됨). 두 경우 모두 Zabbix가 해당 파일을 다른 파일로 간주하여 처음부터 다시 읽을 수 있으며, 이로 인해 중복 경고가 발생할 수 있습니다.
  • logrt[] 아이템과 일치하는 로그 파일이 여러 개이고 Zabbix agent가 그중 가장 최근 파일을 추적하는 중에 해당 파일이 삭제되면 "there are no files matching "<regexp mask>" in "<directory>" 경고 메시지가 기록됩니다. Zabbix agent는 확인 중인 logrt[] 아이템에 대해 에이전트가 확인한 가장 최근 수정 시간보다 수정 시간이 이전인 로그 파일을 무시합니다.
• 에이전트는 이전에 읽기를 중단한 지점부터 로그 파일을 읽기 시작합니다.
• 이미 분석된 바이트 수(크기 카운터)와 마지막 수정 시간(시간 카운터)은 Zabbix 데이터베이스에 저장되고 에이전트로 전송됩니다. 이를 통해 에이전트가 방금 시작되었거나 이전에 비활성화되었거나 지원되지 않던 아이템을 받은 경우에도 해당 지점부터 로그 파일을 읽기 시작합니다. 하지만 에이전트가 서버로부터 0이 아닌 크기 카운터를 받았으나 logrt[] 또는 logrt.count[] 아이템이 일치하는 파일을 찾지 못하면, 나중에 파일이 나타날 때 처음부터 분석하도록 크기 카운터가 0으로 재설정됩니다.
• 로그 파일이 에이전트가 알고 있는 로그 크기 카운터보다 작아질 때마다 카운터가 0으로 재설정되고 에이전트는 시간 카운터를 고려하여 로그 파일을 처음부터 읽기 시작합니다.
• 디렉터리에 마지막 수정 시간이 같은 일치 파일이 여러 개 있으면 에이전트는 데이터 누락이나 동일한 데이터의 중복 분석을 피하면서 수정 시간이 같은 모든 로그 파일을 올바르게 분석하려고 하지만, 모든 상황에서 이를 보장할 수는 없습니다. 에이전트는 특정 로그 파일 로테이션 방식을 가정하거나 이를 판별하지 않습니다. 마지막 수정 시간이 같은 로그 파일이 여러 개 주어지면 에이전트는 사전식 내림차순으로 처리합니다. 따라서 일부 로테이션 방식에서는 로그 파일이 원래 순서대로 분석되고 보고됩니다. 다른 로테이션 방식에서는 로그 파일의 원래 순서가 유지되지 않아 일치한 로그 파일 레코드가 변경된 순서로 보고될 수 있습니다(로그 파일의 마지막 수정 시간이 서로 다르면 이 문제는 발생하지 않음).
• Zabbix agent는 업데이트 간격초마다 한 번씩 로그 파일의 새 레코드를 처리합니다.
• Zabbix agent는 초당 로그 파일의 maxlines보다 많은 줄을 전송하지 않습니다. 이 제한은 네트워크와 CPU 리소스의 과부하를 방지하며 MaxLinesPerSecond 매개변수가 에이전트 구성 파일에서 제공하는 기본값보다 우선합니다.
• 필요한 문자열을 찾기 위해 Zabbix는 MaxLinesPerSecond에 설정된 값보다 10배 많은 새 줄을 처리합니다. 따라서 예를 들어 log[] 또는 logrt[] 아이템의 업데이트 간격이 1초인 경우, 기본적으로 에이전트는 한 번의 검사에서 로그 파일 레코드를 최대 200개까지 분석하고 일치하는 레코드를 최대 20개까지 Zabbix server로 전송합니다. 에이전트 구성 파일에서 MaxLinesPerSecond를 늘리거나 아이템 키에 maxlines 매개변수를 설정하면 한 번의 검사에서 분석하는 로그 파일 레코드는 최대 10000개, Zabbix server로 전송하는 일치 레코드는 최대 1000개까지 제한을 늘릴 수 있습니다. 업데이트 간격을 2초로 설정하면 한 번의 검사에 대한 제한이 업데이트 간격이 1초일 때보다 2배 높게 설정됩니다.
• 또한 log 및 log.count 값은 버퍼에 로그 이외의 값이 없더라도 항상 에이전트 전송 버퍼 크기의 50%로 제한됩니다. 따라서 maxlines 값을 여러 연결이 아닌 한 연결로 전송하려면 에이전트의 BufferSize 매개변수가 maxlines x 2 이상이어야 합니다. Zabbix agent는 로그를 수집하는 동안 데이터를 업로드하여 버퍼를 비울 수 있지만, Zabbix agent 2는 데이터가 업로드되고 비동기적으로 버퍼가 비워질 때까지 로그 수집을 중지합니다.
• 로그 아이템이 없으면 에이전트 버퍼 크기 전체가 로그 이외의 값에 사용됩니다. 로그 값이 들어오면 필요에 따라 지정된 50%까지 오래된 비로그 값을 대체합니다.
• 256kB보다 긴 로그 파일 레코드는 처음 256kB만 정규 표현식과 일치 여부를 확인하고 레코드의 나머지 부분은 무시합니다. 하지만 Zabbix agent가 긴 레코드를 처리하는 중에 중지되면 에이전트 내부 상태가 손실되어, 에이전트를 다시 시작한 후 긴 레코드가 다시 분석되거나 다르게 분석될 수 있습니다.
• \ 경로 구분자에 대한 특별 참고 사항: file_format이 file\.log이면 file 디렉터리가 없어야 합니다. "."이 이스케이프되었는지 아니면 파일 이름의 첫 번째 기호인지 명확하게 정의할 수 없기 때문입니다.
• logrt의 정규 표현식은 파일 이름에서만 지원되며, 디렉터리 정규 표현식 일치는 지원되지 않습니다.
• UNIX 플랫폼에서 로그 파일이 있을 것으로 예상되는 디렉터리가 존재하지 않으면 logrt[] 아이템이 NOTSUPPORTED 상태가 됩니다.
• Microsoft Windows에서는 디렉터리가 존재하지 않아도 아이템이 NOTSUPPORTED 상태가 되지 않습니다(예: 아이템 키에서 디렉터리 이름을 잘못 입력한 경우).
• logrt[] 아이템에 대한 로그 파일이 없어도 NOTSUPPORTED 상태가 되지 않습니다. logrt[] 아이템의 로그 파일 읽기 오류는 Zabbix agent 로그 파일에 경고로 기록되지만 아이템을 NOTSUPPORTED 상태로 만들지는 않습니다.
• Zabbix agent 로그 파일은 log[] 또는 logrt[] 아이템이 NOTSUPPORTED 상태가 된 이유를 파악하는 데 유용할 수 있습니다. Zabbix는 DebugLevel=4 또는 DebugLevel=5인 경우를 제외하고 자체 에이전트 로그 파일을 모니터링할 수 있습니다.
• 정규 표현식으로 물음표를 검색할 때(예: \?), 텍스트 파일에 NUL 기호가 포함되어 있으면 오탐이 발생할 수 있습니다. Zabbix가 줄 바꿈 문자까지 줄 처리를 계속하기 위해 해당 기호를 ?로 바꾸기 때문입니다.

정규 표현식에서 일치하는 부분 추출

정규 표현식과 일치하는 항목을 찾았을 때 전체 줄을 반환하는 대신 대상 파일에서 원하는 값만 추출해야 할 때가 있습니다.

로그 아이템은 일치한 줄에서 원하는 값을 추출할 수 있습니다. 이는 추가 output 매개변수를 통해 log 및 logrt 아이템에서 수행됩니다.

'output' 매개변수를 사용하면 관심 있는 일치 항목의 "캡처 그룹"을 지정할 수 있습니다.

예를 들면 다음과 같습니다:

log[/path/to/the/file,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1]

다음 콘텐츠에서 찾은 항목 수를 반환할 수 있습니다:

Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) large result
buffer allocation - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC
ID: 41726453/User: AUser/Form: CFG:ServiceLevelAgreement

\1이 첫 번째이자 유일한 캡처 그룹인 ([0-9]+)을 참조하므로 숫자만 반환됩니다.

숫자를 추출하고 반환할 수 있으므로 이 값을 트리거 정의에 사용할 수 있습니다.

maxdelay 매개변수 사용

로그 아이템의 maxdelay 매개변수를 사용하면 로그 파일에서 일부 오래된 줄을 무시하여 maxdelay초 이내에 가장 최근 줄을 분석할 수 있습니다.

기본적으로 로그 모니터링 아이템은 로그 파일에 나타나는 모든 새 줄을 추적합니다. 하지만 일부 애플리케이션은 특정 상황에서 로그 파일에 엄청난 수의 메시지를 쓰기 시작합니다. 예를 들어 데이터베이스나 DNS 서버를 사용할 수 없으면 이러한 애플리케이션은 정상 작동이 복구될 때까지 거의 동일한 오류 메시지 수천 개로 로그 파일을 채웁니다. 기본적으로 이러한 모든 메시지는 성실하게 분석되며 일치하는 줄은 log 및 logrt 아이템의 구성에 따라 서버로 전송됩니다.

기본 제공되는 과부하 방지 기능은 구성 가능한 maxlines 매개변수(너무 많은 일치 로그 줄이 수신되어 서버가 과부하되는 것을 방지)와 10*'maxlines' 제한(한 번의 검사에서 에이전트로 인해 호스트 CPU 및 I/O가 과부하되는 것을 방지)으로 구성됩니다. 하지만 기본 제공 보호 기능에는 두 가지 문제가 있습니다. 첫째, 유용한 정보가 아닐 가능성이 큰 메시지가 다량으로 서버에 보고되어 데이터베이스 공간을 차지합니다. 둘째, 초당 분석되는 줄 수가 제한되므로 에이전트가 최신 로그 레코드보다 몇 시간 뒤처질 수 있습니다. 오래된 레코드를 몇 시간 동안 처리하기보다는 로그 파일의 현재 상황을 더 빨리 파악하는 편을 선호할 가능성이 큽니다.

두 문제의 해결책은 maxdelay 매개변수를 사용하는 것입니다. maxdelay > 0을 지정하면 검사할 때마다 처리된 바이트 수, 남은 바이트 수 및 처리 시간을 측정합니다. 에이전트는 이 수치를 바탕으로 로그 파일의 남은 레코드를 모두 분석하는 데 걸리는 예상 시간(초)을 계산합니다.

지연 시간이 maxdelay를 초과하지 않으면 에이전트는 평소와 같이 로그 파일 분석을 계속합니다.

지연 시간이 maxdelay보다 크면 에이전트는 새로운 예상 위치로 "점프"하여 로그 파일의 일부를 무시하므로 남은 줄을 maxdelay초 이내에 분석할 수 있습니다.

에이전트는 무시할 줄을 버퍼로 읽지도 않으며, 파일에서 이동할 대략적인 위치를 계산합니다.

로그 파일 줄을 건너뛴 사실은 에이전트 로그 파일에 다음과 같이 기록됩니다:

14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
logfile:"/home/zabbix32/test1.log" skipping 679858 bytes
(from byte 75653115 to byte 76332973) to meet maxdelay

"점프"한 후 에이전트가 파일에서 더 뒤나 앞에 있을 수 있는 로그 줄의 시작 위치에 맞춰 위치를 조정하므로 "to byte" 숫자는 근사값입니다.

로그 파일의 증가 속도와 분석 속도에 따라 "점프"가 없거나, 드물거나 자주 발생하거나, 크거나 작게 발생하거나, 심지어 검사할 때마다 작은 "점프"가 발생할 수도 있습니다. 시스템 부하 및 네트워크 지연 시간의 변동도 지연 계산에 영향을 미치므로 maxdelay 매개변수를 준수하기 위한 앞으로의 "점프"에도 영향을 줍니다.

maxdelay < update interval로 설정하는 것은 권장하지 않습니다(작은 "점프"가 자주 발생할 수 있음).

'copytruncate' 로그 파일 로테이션 처리 참고 사항

logrt에서 copytruncate 옵션을 사용하면 서로 다른 로그 파일에 서로 다른 레코드가 있다고 가정하므로(적어도 타임스탬프가 다름), 초기 블록(처음 512바이트까지)의 MD5 합계가 서로 다릅니다. 초기 블록의 MD5 합계가 같은 파일 두 개가 있으면 하나는 원본이고 다른 하나는 복사본입니다.

logrt에서 copytruncate 옵션을 사용하면 중복을 보고하지 않고 로그 파일 복사본을 올바르게 처리하려고 합니다. 하지만 타임스탬프가 같은 로그 파일 복사본을 여러 개 생성하거나, logrt[] 아이템의 업데이트 간격보다 자주 로그 파일을 로테이션하거나, 에이전트를 자주 다시 시작하는 것은 권장하지 않습니다. 에이전트는 이러한 모든 상황을 합리적으로 처리하려고 하지만 모든 상황에서 좋은 결과를 보장할 수는 없습니다.

log*[] 아이템의 영구 파일 참고 사항

영구 파일의 목적

Zabbix agent가 시작되면 Zabbix server 또는 proxy로부터 활성 검사 목록을 받습니다. log*[] 메트릭의 경우 로그 파일 모니터링을 시작할 위치를 찾기 위해 처리된 로그 크기와 수정 시간을 받습니다. 파일 시스템에서 보고한 실제 로그 파일 크기와 수정 시간에 따라 에이전트는 처리된 로그 크기부터 로그 파일 모니터링을 계속할지, 로그 파일을 처음부터 다시 분석할지 결정합니다.

실행 중인 에이전트는 검사 사이에 모니터링되는 모든 로그 파일을 추적하기 위해 더 많은 속성 집합을 유지합니다. 이 메모리 내 상태는 에이전트가 중지되면 손실됩니다.

새로운 선택적 매개변수 persistent_dir은 log[], log.count[], logrt[] 또는 logrt.count[] 아이템의 상태를 파일에 저장할 디렉터리를 지정합니다. Zabbix agent를 다시 시작하면 영구 파일에서 로그 아이템의 상태가 복원됩니다.

주요 사용 사례는 미러링된 파일 시스템에 있는 로그 파일을 모니터링하는 것입니다. 특정 시점까지 로그 파일은 두 미러 모두에 기록됩니다. 그런 다음 미러가 분리됩니다. 활성 복사본에서는 로그 파일이 계속 증가하면서 새 레코드를 받습니다. Zabbix agent는 이를 분석하고 처리된 로그 크기와 수정 시간을 서버로 전송합니다. 수동 복사본의 로그 파일은 변경되지 않은 채 활성 복사본보다 크게 뒤처집니다. 나중에 수동 복사본에서 운영 체제와 Zabbix agent가 재부팅됩니다. Zabbix agent가 서버에서 받은 처리된 로그 크기와 수정 시간은 수동 복사본의 상황에 유효하지 않을 수 있습니다. 파일 시스템 미러가 분리될 때 에이전트가 중단한 지점부터 로그 파일 모니터링을 계속하기 위해 에이전트는 영구 파일에서 상태를 복원합니다.

영구 파일을 사용하는 에이전트 작업

시작할 때 Zabbix agent는 영구 파일에 대해 아무것도 알지 못합니다. Zabbix server(proxy)로부터 활성 검사 목록을 받은 후에야 에이전트는 일부 로그 아이템이 지정된 디렉터리 아래의 영구 파일로 백업되어야 함을 알게 됩니다.

에이전트 작동 중에 영구 파일은 쓰기용으로 열리고(fopen(filename, "w") 사용) 최신 데이터로 덮어쓰입니다. 덮어쓰기와 파일 시스템 미러 분리가 동시에 일어날 경우 영구 파일 데이터가 손실될 가능성은 매우 낮으며 이를 위한 별도의 처리는 없습니다. 영구 파일에 쓴 후 저장 매체에 강제로 동기화하지 않습니다(fsync()를 호출하지 않음).

일치하는 로그 파일 레코드 또는 메타데이터(처리된 로그 크기 및 수정 시간)가 Zabbix server에 성공적으로 보고된 후 최신 데이터로 덮어씁니다. 로그 파일이 계속 변경되면 아이템을 검사할 때마다 이 작업이 발생할 수 있습니다.

에이전트 종료 중에는 특별한 작업을 수행하지 않습니다.

활성 검사 목록을 받은 후 에이전트는 오래된 영구 파일을 제거 대상으로 표시합니다. 다음과 같은 경우 영구 파일이 오래된 것으로 간주됩니다:

1. 해당 로그 아이템이 더 이상 모니터링되지 않습니다.
2. 로그 아이템이 이전과 다른 persistent_dir 위치로 재구성됩니다.

NOTSUPPORTED 상태의 로그 파일은 활성 검사 목록에 포함되지 않지만 나중에 SUPPORTED 상태가 되어 영구 파일이 유용할 수 있으므로 24시간 후에 제거됩니다.

24시간이 지나기 전에 에이전트가 중지되면 Zabbix agent가 더 이상 Zabbix server로부터 해당 위치에 대한 정보를 받지 못하므로 오래된 파일은 삭제되지 않습니다.

영구 파일의 이름 및 위치

Zabbix agent는 키를 기준으로 활성 검사를 구분합니다. 예를 들어 logrt[/home/zabbix/test.log]와 logrt[/home/zabbix/test.log,]는 서로 다른 아이템입니다. 프런트엔드에서 logrt[/home/zabbix/test.log,,,10] 아이템을 logrt[/home/zabbix/test.log,,,20]으로 수정하면 에이전트의 활성 검사 목록에서 logrt[/home/zabbix/test.log,,,10] 아이템이 삭제되고 logrt[/home/zabbix/test.log,,,20] 아이템이 생성됩니다(일부 속성은 프런트엔드/서버에서 수정할 때 승계되지만 에이전트에서는 승계되지 않음).

파일 이름은 충돌 가능성을 줄이기 위해 아이템 키의 MD5 합계에 아이템 키 길이를 덧붙여 구성합니다. 예를 들어 logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] 아이템의 상태는 영구 파일 c963ade4008054813bbc0a650bb8e09266에 보관됩니다.

여러 로그 아이템이 동일한 persistent_dir 값을 사용할 수 있습니다.

persistent_dir은 특정 파일 시스템 레이아웃, 마운트 지점, 마운트 옵션 및 스토리지 미러링 구성을 고려하여 지정합니다. 영구 파일은 모니터링되는 로그 파일과 동일한 미러링된 파일 시스템에 있어야 합니다.

persistent_dir 디렉터리를 만들 수 없거나 디렉터리가 존재하지 않거나, Zabbix agent의 접근 권한으로 파일을 생성/쓰기/읽기/삭제할 수 없으면 로그 아이템이 NOTSUPPORTED 상태가 됩니다.

에이전트 작동 중에 영구 스토리지 파일에 대한 접근 권한이 제거되거나 다른 오류가 발생하면(예: 디스크 가득 참) 오류가 에이전트 로그 파일에 기록되지만 로그 아이템은 NOTSUPPORTED 상태가 되지 않습니다.

I/O 부하

아이템의 영구 파일은 모든 데이터 배치(아이템 데이터 포함)가 서버로 성공적으로 전송된 후 업데이트됩니다. 예를 들어 기본 BufferSize는 100입니다. 로그 아이템에서 일치하는 레코드 70개를 찾은 경우 처음 50개 레코드는 하나의 배치로 전송되고 영구 파일이 업데이트된 다음, 나머지 20개 레코드가 전송되고(더 많은 데이터가 누적되는 동안 약간 지연될 수 있음) 두 번째 배치에서 영구 파일이 다시 업데이트됩니다.

에이전트와 서버 간 통신 실패 시 동작

log[] 및 logrt[] 아이템에서 일치하는 각 줄과 log.count[] 및 logrt.count[] 아이템의 각 검사 결과에는 에이전트 전송 버퍼에서 지정된 50% 영역의 빈 슬롯 하나가 필요합니다. 버퍼 요소는 정기적으로 서버(또는 proxy)로 전송되어 버퍼 슬롯이 다시 비게 됩니다.

에이전트 전송 버퍼의 지정된 로그 영역에 빈 슬롯이 있는 동안 에이전트와 서버(또는 proxy) 간 통신이 실패하면 로그 모니터링 결과가 전송 버퍼에 누적됩니다. 이는 짧은 통신 장애의 영향을 완화하는 데 도움이 됩니다.

통신 장애가 길어지면 모든 로그 슬롯이 사용되며 다음 동작이 수행됩니다:

• log[] 및 logrt[] 아이템 검사가 중지됩니다. 통신이 복구되고 버퍼에 빈 슬롯이 생기면 이전 위치부터 검사가 재개됩니다. 일치하는 줄은 손실되지 않고 나중에 보고됩니다.
• log.count[] 및 logrt.count[] 검사는 maxdelay = 0(기본값)이면 중지됩니다. 동작은 위에서 설명한 log[] 및 logrt[] 아이템과 유사합니다. 이로 인해 log.count[] 및 logrt.count[] 결과가 영향을 받을 수 있습니다. 예를 들어 한 검사에서 로그 파일의 일치하는 줄 100개를 계산했지만 버퍼에 빈 슬롯이 없어 검사가 중지됩니다. 통신이 복구되면 에이전트는 동일한 일치 줄 100개와 새 일치 줄 70개를 계산합니다. 이제 에이전트는 한 번의 검사에서 발견된 것처럼 count = 170을 전송합니다.
• log.count[] 및 logrt.count[] 검사에서 maxdelay > 0인 경우: 검사 중 "점프"가 없었다면 동작은 위에서 설명한 것과 유사합니다. 로그 파일 줄을 건너뛰는 "점프"가 발생했다면 "점프" 이후의 위치가 유지되고 계산 결과는 폐기됩니다. 따라서 에이전트는 통신 장애가 발생해도 증가하는 로그 파일을 따라잡으려고 합니다.

정규 표현식 컴파일 및 런타임 오류 처리

log[], logrt[], log.count[] 또는 logrt.count[] 아이템에서 사용된 정규 표현식을 PCRE 또는 PCRE2 라이브러리가 컴파일할 수 없으면 해당 아이템은 오류 메시지와 함께 NOTSUPPORTED 상태가 됩니다. 로그 아이템 모니터링을 계속하려면 정규 표현식을 수정해야 합니다.

정규 표현식이 성공적으로 컴파일되지만 런타임에 실패하면(일부 또는 모든 로그 레코드에서) 로그 아이템은 지원 상태로 유지되고 모니터링이 계속됩니다. 런타임 오류는 Zabbix agent 로그 파일에 기록됩니다(로그 파일 레코드는 제외).

Zabbix agent가 자체 로그 파일을 모니터링할 수 있도록 로깅 빈도는 검사당 런타임 오류 하나로 제한됩니다. 예를 들어 레코드 10개를 분석하고 레코드 3개에서 정규 표현식 런타임 오류가 발생하면 에이전트 로그에 레코드 하나가 생성됩니다.

예외: MaxLinesPerSecond=1이고 update interval=1인 경우(검사당 레코드 1개만 분석 가능) 정규 표현식 런타임 오류가 기록되지 않습니다.

zabbix_agentd는 런타임 오류가 발생하면 아이템 키를 기록하고, zabbix_agent2는 런타임 오류가 있는 로그 아이템을 식별하는 데 도움이 되도록 아이템 ID를 기록합니다. 런타임 오류가 발생하면 정규 표현식을 다시 설계하는 것이 좋습니다.