6 로그 파일 모니터링

개요

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

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

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

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

설정

에이전트 매개변수 확인

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

• 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 에이전트가 시작되면 Zabbix 서버나 프록시로부터 활성 검사 목록을 받습니다. log*[] 메트릭의 경우 처리된 로그 크기와 수정 시간을 받아 로그 파일 모니터링을 어디서부터 시작할지 찾습니다. 파일 시스템에서 보고된 실제 로그 파일 크기와 수정 시간에 따라 에이전트는 처리된 로그 크기부터 로그 파일 모니터링을 계속할지 또는 처음부터 로그 파일을 다시 분석할지를 결정합니다.

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

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

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

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

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

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

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

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

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

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

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

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

영구 파일의 명명과 위치

Zabbix agent는 키를 통해 능동 검사를 구분합니다. 예를 들어, logrt[/home/zabbix/test.log]와 logrt[/home/zabbix/test.log,]는 다른 아이템입니다. 프론트엔드에서 logrt[/home/zabbix/test.log,,,10] 아이템을 logrt[/home/zabbix/test.log,,,20]로 수정하면 agent의 능동 검사 목록에서 logrt[/home/zabbix/test.log,,,10] 아이템이 삭제되고 logrt[/home/zabbix/test.log,,,20] 아이템이 생성됩니다 (일부 속성은 프론트엔드/서버에서 수정 시 전달되지만, agent에서는 그렇지 않습니다).

파일명은 아이템 키의 MD5 합에 아이템 키 길이가 추가되어 충돌 가능성을 줄이도록 구성됩니다. 예를 들어, logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] 아이템의 상태는 영구 파일 c963ade4008054813bbc0a650bb8e09266에 보관됩니다.

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

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

persistent_dir 디렉터리를 생성할 수 없거나 존재하지 않거나, Zabbix agent의 액세스 권한으로 파일 생성/쓰기/읽기/삭제가 허용되지 않으면 로그 아이템은 NOTSUPPORTED가 됩니다.

agent 운영 중 영구 스토리지 파일에 대한 액세스 권한이 제거되거나 기타 오류(예: 디스크 풀)가 발생하면 오류가 agent 로그 파일에 기록되지만 로그 아이템은 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를 기록합니다. 런타임 오류가 발생하는 경우 정규 표현식을 재설계하는 것을 권장합니다.