6 로그 파일 모니터링

개요

Zabbix는 로그 로테이션 지원 여부와 관계없이 로그 파일의 중앙 집중식 모니터링 및 분석에 사용할 수 있습니다.

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

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

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

설정

에이전트 매개변수 확인

에이전트 구성 파일에서 다음 사항을 확인하세요:

• Hostname 매개변수가 프론트엔드의 호스트 이름과 일치하는지 확인합니다.
• ServerActive 매개변수의 서버들이 능동 검사 처리를 위해 지정되어 있는지 확인합니다.

아이템 구성

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

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

로그 모니터링 아이템의 경우 다음과 같이 입력합니다:

중요 사항

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

정규 표현식의 일치하는 부분 추출하기

때로는 정규 표현식 일치가 발견되었을 때 전체 줄을 반환하는 대신 대상 파일에서 관심 있는 값만 추출하고 싶을 수 있습니다.

로그 아이템은 일치하는 줄에서 원하는 값을 추출할 수 있는 기능을 가지고 있습니다. 이는 log와 logrt 아이템의 추가적인 output 매개변수를 통해 수행됩니다.

'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를 보호)으로 구성됩니다. 그럼에도 불구하고, 내장 보호에는 2가지 문제가 있습니다. 첫째, 많은 수의 잠재적으로 그리 정보성이 없는 메시지들이 서버에 보고되어 데이터베이스의 공간을 소모합니다. 둘째, 초당 분석되는 라인 수가 제한되어 있어 에이전트가 최신 로그 레코드보다 몇 시간 뒤처질 수 있습니다. 아마도 몇 시간 동안 오래된 레코드들을 살펴보는 대신 로그 파일의 현재 상황에 대해 더 빨리 알림을 받기를 선호할 것입니다.

두 문제 모두에 대한 해결책은 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 < 업데이트 간격으로 설정하는 것은 권장되지 않습니다 (빈번한 작은 "점프"가 발생할 수 있습니다).

'copytruncate' 로그 파일 순환 처리에 대한 참고사항

copytruncate 옵션을 사용하는 logrt는 서로 다른 로그 파일이 다른 레코드를 가지고 있다고 가정합니다(최소한 타임스탬프가 다름). 따라서 초기 블록(최초 512바이트까지)의 MD5 합계가 다를 것입니다. 초기 블록의 MD5 합계가 동일한 두 파일이 있다는 것은 그 중 하나는 원본이고, 다른 하나는 복사본임을 의미합니다.

copytruncate 옵션을 사용하는 logrt는 중복 보고 없이 로그 파일 복사본을 올바르게 처리하기 위해 노력합니다. 하지만 동일한 타임스탬프로 여러 로그 파일 복사본을 생성하거나, logrt[] 항목 업데이트 간격보다 더 자주 로그 파일 순환을 수행하거나, 에이전트를 자주 재시작하는 것은 권장되지 않습니다. 에이전트는 이러한 모든 상황을 합리적으로 잘 처리하려고 시도하지만, 모든 상황에서 좋은 결과를 보장할 수는 없습니다.

log*[] 항목의 영구 파일에 대한 참고사항

지속 파일의 목적

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

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

새로운 선택적 매개변수 persistent_dir은 log[], log.count[], logrt[] 또는 logrt.count[] 항목의 상태를 파일에 저장하기 위한 디렉터리를 지정합니다. log 항목의 상태는 Zabbix agent가 재시작된 후 지속 파일에서 복원됩니다.

주요 사용 사례는 미러링된 파일 시스템에 위치한 로그 파일의 모니터링입니다. 어떤 시점까지는 로그 파일이 두 미러 모두에 작성됩니다. 그 다음 미러가 분할됩니다. 활성 복사본에서는 로그 파일이 여전히 증가하여 새로운 레코드를 받습니다. Zabbix agent는 이를 분석하고 처리된 로그 크기와 수정 시간을 서버로 보냅니다. 수동 복사본에서는 로그 파일이 동일하게 유지되어 활성 복사본보다 훨씬 뒤처집니다. 나중에 운영 체제와 Zabbix agent가 수동 복사본에서 재부팅됩니다. Zabbix agent가 서버에서 받는 처리된 로그 크기와 수정 시간은 수동 복사본의 상황에는 유효하지 않을 수 있습니다. 파일 시스템 미러 분할 시점에 agent가 중단했던 지점부터 로그 파일 모니터링을 계속하기 위해 agent는 지속 파일에서 상태를 복원합니다.

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

시작 시 Zabbix 에이전트는 영구 파일에 대해 아무것도 알지 못합니다. Zabbix 서버(프록시)로부터 활성 검사 목록을 받은 후에야 에이전트는 일부 로그 항목이 지정된 디렉토리 하위의 영구 파일로 백업되어야 함을 알게 됩니다.

에이전트 작업 중에 영구 파일은 쓰기용으로 열리며(fopen(filename, "w") 사용) 최신 데이터로 덮어씌워집니다. 덮어쓰기와 파일 시스템 미러 분할이 동시에 발생하는 경우 영구 파일 데이터가 손실될 가능성은 매우 낮으므로 이에 대한 특별한 처리는 없습니다. 영구 파일에 쓰기 작업 후 저장 매체로의 강제 동기화는 수행되지 않습니다(fsync()가 호출되지 않음).

최신 데이터로의 덮어쓰기는 일치하는 로그 파일 레코드나 메타데이터(처리된 로그 크기 및 수정 시간)를 Zabbix 서버에 성공적으로 보고한 후 수행됩니다. 로그 파일이 계속 변경되는 경우 항목 검사마다 이 작업이 수행될 수 있습니다.

에이전트 종료 시에는 특별한 작업이 없습니다.

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

• 해당 로그 항목이 더 이상 모니터링되지 않는 경우;
  • 로그 항목이 이전과 다른 persistent_dir 위치로 재구성된 경우.

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

24시간이 만료되기 전에 에이전트가 중지되면, Zabbix 에이전트가 더 이상 Zabbix 서버로부터 해당 위치에 대한 정보를 받지 못하므로 사용되지 않는 파일들은 삭제되지 않습니다.

지속 파일의 명명 및 위치

Zabbix 에이전트는 키를 통해 활성 검사를 구분합니다. 예를 들어, 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 에이전트의 액세스 권한으로 파일을 생성/쓰기/읽기/삭제할 수 없는 경우 로그 아이템이 NOTSUPPORTED가 됩니다.

에이전트 작업 중에 지속 스토리지 파일에 대한 액세스 권한이 제거되거나 기타 오류가 발생하는 경우(예: 디스크 가득참) 오류는 에이전트 로그 파일에 기록되지만 로그 아이템은 NOTSUPPORTED가 되지 않습니다.

I/O 시 로드

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

에이전트와 서버 간 통신 실패 시 조치 사항

log[] 및 logrt[] 항목의 각 매칭 라인과 각 log.count[] 및 logrt.count[] 항목 검사 결과는 에이전트 전송 버퍼의 지정된 50% 영역에서 사용 가능한 슬롯이 필요합니다. 버퍼 요소는 정기적으로 서버(또는 프록시)로 전송되며 버퍼 슬롯은 다시 사용 가능해집니다.

에이전트 전송 버퍼의 지정된 로그 영역에 사용 가능한 슬롯이 있고 에이전트와 서버(또는 프록시) 간 통신이 실패하는 동안 로그 모니터링 결과는 전송 버퍼에 누적됩니다. 이는 짧은 통신 장애를 완화하는 데 도움이 됩니다.

장기간 통신 장애 중에 모든 로그 슬롯이 점유되면 다음과 같은 조치가 취해집니다:

• log[] 및 logrt[] 항목 검사가 중지됩니다. 통신이 복원되고 버퍼에서 사용 가능한 슬롯이 있을 때 이전 위치부터 검사가 재개됩니다. 매칭되는 라인은 손실되지 않으며, 나중에 보고됩니다.
• log.count[] 및 logrt.count[] 검사는 maxdelay = 0(기본값)인 경우 중지됩니다. 동작은 위에서 설명한 log[] 및 logrt[] 항목과 유사합니다. 이는 log.count[] 및 logrt.count[] 결과에 영향을 줄 수 있습니다: 예를 들어, 한 번의 검사에서 로그 파일에서 100개의 매칭 라인을 카운트했지만, 버퍼에 사용 가능한 슬롯이 없어서 검사가 중지됩니다. 통신이 복원되면 에이전트는 동일한 100개의 매칭 라인과 70개의 새로운 매칭 라인을 카운트합니다. 에이전트는 이제 한 번의 검사에서 찾은 것처럼 count = 170을 전송합니다.
• maxdelay > 0인 log.count[] 및 logrt.count[] 검사: 검사 중에 "점프"가 발생하지 않은 경우, 동작은 위에서 설명한 것과 유사합니다. 로그 파일 라인에 대한 "점프"가 발생한 경우 "점프" 후의 위치가 유지되고 카운트된 결과는 폐기됩니다. 따라서 에이전트는 통신 장애 상황에서도 증가하는 로그 파일을 따라잡으려고 시도합니다.

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

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

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

로깅 속도는 Zabbix 에이전트가 자체 로그 파일을 모니터링할 수 있도록 체크당 하나의 런타임 오류로 제한됩니다. 예를 들어, 10개 레코드가 분석되고 3개 레코드가 정규식 런타임 오류로 실패하는 경우, 에이전트 로그에 하나의 레코드가 생성됩니다.

예외: MaxLinesPerSecond=1이고 업데이트 간격=1인 경우(체크당 1개 레코드만 분석 허용), 정규식 런타임 오류는 기록되지 않습니다.

zabbix_agentd는 런타임 오류 발생 시 아이템 키를 기록하고, zabbix_agent2는 런타임 오류가 발생한 로그 아이템을 식별하는 데 도움이 되도록 아이템 ID를 기록합니다. 런타임 오류가 발생하는 경우 정규식을 재설계하는 것이 권장됩니다.