[Logstash] File input plugin 4.1.11

File input plugin

• Plugin version: v4.1.11
• Released on: 2019-09-25

Description

일반적으로 tail -0F와 유사한 방식으로 파일에서 이벤트를 스트리밍하지만, 선택적으로 처음부터 이벤트를 읽는다.

 

일반적으로 로깅은 쓰여진 각 행의 끝에 새로운 라인을 추가한다. 기본적으로 각 이벤트는 하나의 라인으로 가정되며, 라인의 새로운 문자 앞에 있는 텍스트로 간주된다. 여러 개의 로그 라인을 하나의 이벤트에 결합하려면 멀티라인 코덱을 사용하면 된다. 플러그인은 새 파일을 검색하는 것과 각 검색된 파일을 처리하는 것 사이를 순환한다. 검색된 파일은 생명 주기를 가지며 "watched" 또는 "ignored" 상태로 시작한다. 생명주기의 다른 상태는 "active", "closed" 및 "unwatched"가 있다.

 

기본적으로 사용 중인 파일 핸들 수를 제한하는 데 4095개의 창이 사용된다. 처리단계에는 다음과 같은 여러 단계가 있다.

 

• "closed" 파일 또는 "ignored" 파일의 크기가 지난 번 이후로 변경되었는지 확인하고 파일이 "watched" 상태에 있는지 확인한다.
• 창에서 사용 가능한 공간을 채울 만큼 "watched" 파일을 선택하면 파일들은 "active"가 된다.
• active 파일들은 열리고 읽혀지며, 각 파일은 기본적으로 마지막으로 알려진 위치에서 현재 콘텐츠의 끝(EOF)까지 읽힌다.

일부 경우에는 어떤 파일을 먼저 읽고, 정렬하고, 파일을 완전히 읽는지, 또는 벤딩/스트라이핑 하는지 제어할 수 있는 것이 유용하다. 전체 읽기는 파일 A, 파일 B, 파일 C 등의 전부이다. 벤딩 또는 스트라이핑 읽기는 파일 A와 파일 B, 파일 C의 일부분이며, 모든 모든 파일이 읽힐 때 까지 다시 파일 A로 돌아간다. 밴딩 읽기는 file_chunk_count 및 file_chunk_size를 변경하여 지정한다. 가능한 빨리 모든 파일의 일부 이벤트를 Kibana에 표시하려면 벤딩과 정렬이 유용할 수 있다.

 

플러그인은 Tail 모드와 Read 모드라는 두 가지 작동 모드를 가지고 있다.

 

Tail 모드

이 모드에서 플러그인은 변화하는 파일을 추적하고 각 파일에 추가될 때 새로운 콘텐츠를 내보내는 것을 목표로 한다. 이 모드에서 파일은 결코 끝나지 않는 콘텐츠 스트림으로 보여지며 EOF는 특별한 의미가 없다. 플러그인은 항상 더 많은 콘텐츠가 있을 것이라고 가정한다. 파일이 회전되면, 크기가 작거나 0이 감지되고 현재 위치가 0으로 재설정되고 스트리밍이 계속된다. 누적된 문자를 한줄로 내보내려면 먼저 구분자가 표시되어야 한다.

 

Read 모드

이 모드에서 플러그인은 각 파일을 마치 콘텐츠가 완성된 것처럼 취급하며, 즉 유한한 라인의 스트림으로 처리하고 이제 EOF는 유효하다. EOF는 누적된 문자를 라인으로 내부낼수 있다는 것을 의미하기 때문에 마지막 구분 기호는 필요하지 않다. 또한, 여기서 EOF는 파일을 닫고 "unwatched" 상태로 전환할 수 있다는 것을 의미하며, 이는 자동으로 활성창에 공간을 확보한다. 또한 이 모드는 콘텐츠가 완성된 압축 파일을 처리할수 있게 한다. 또한 읽기 모드에서는 파일을 완전히 처리한 후 작업을 수행할 수 있다.

 

과거에는 무한 스트림이 이상적이지 않고 읽기 전용 모드가 개선되었다고 가정하면서 읽기 모드를 시뮬레이션하려고 시도 했다.

 

감시된 파일의 현재 위치 추적

플러그인은 각 파일의 현재 위치를 sincedb라는 별도의 파일에 기록하여 추적한다. 이를 통해 Logstash를 중지하고 다시 시작할 수 있으며 Logstash가 중지된 동안 파일에 추가된 라인을 놓치지 않고 중단된 위치에서 픽업할 수 있다.

 

기본적으로 sincedb 파일은 감시 중인 파일이름 패턴(즉, path 옵션)에 기반한 파일 이름과 함께 Logstash의 data 디렉터리에 배치된다. 따라서 파일이름 패턴을 변경하면 새로운 sincedb 파일이 사용되며 기존의 모든 위치 상태가 손실된다. 패턴을 자주 변경하는 경우 sincedb_path를 명시적으로 선택하는 것이 타당할 수 있다.

 

각 입력에 대해 서로 다른 sincedb_path를 사용해야 한다. 같은 경로를 사용하면 문제가 발생할 수 있다. 각 입력의 읽기 체크포인트는 정보가 오버라이 되지 않도록 다른 경로에 저장해야 한다.

 

파일은 식별자를 통해 추적된다. 이 빅별자는 inode, 주요 장치 번호 및 보조 장치 번호로 구성된다. windows에서는 kernel32 API call에서 다른 식별자를 얻는다.

 

Sincedb 레코드는 이제 만료될 수 있다. 즉, 일정기간 후에는 이전 파일의 읽기 위치가 기억되지 않는다는 뜻이다. 파일 시스템은 새로운 콘텐츠에 대해 inode를 재사용해야 할 수도 있다. 이상적으로, 우리는 오래된 콘텐츠의 읽기 위치를 사용하지 않을 것이지만, 우리는 그 inode 재사용이 일어났음을 감지할 수 있는 믿을만한 방법이 없다. 이는 많은 파일이 sincedb에서 추적되는 읽기 모드와 더 관련이 있다. 그러나 레코드가 만료되면 이전에 본 파일을 다시 읽게 된다는 점을 명심하라.

 

Sincedb파일은 4개(<v5.0.0), 5개 또는 6개의 열이 있는 텍스트 파일이다.

 

1. inode 번호(또는 동등한 것)
2. 파일 시스템의 주요 장치 번호(또는 동등한 것)
3. 파일 시스템의 보조 장치 번호(또는 동등한 것)
4. 파일 내의 현재 바이트 오프셋
5. 마지막 활성 타임스탬프(부동 소수점 수)
6. 이 레코드가 일치하는 마지막으로 알려진 경로(새 형식으로 반환된 이전 sincedb 레코드의 경우, 이 경로는 비어있음)

Windows가 아닌 시스템에서는 ls -li와 같은 명령어로 파일의 inode 번호를 얻을 수 있다.

 

원격 네트워크 볼륨에서 읽기

파일 입력은 NFS, Samba, s3fs-fuse 등과 같은 원격 파일 시스템에서 철저히 테스트되지는 않지만 NFS는 때때로 테스트 된다. 원격 FS 클라이언트에 의해 주어진 파일 크기는 할당된 메모리로 읽지만 채워지지 않은 메모리로 읽힌느 것을 방지하기 위해 주어진 시간에 읽을 데이터의 양을 제어하는데 사용된다. 식별자에서 주 장치와 보조 장치를 사용하여 파일의 "마지막 읽은" 위치를 추적하고 다시 마운트하면 주 장치와 보조 장치가 변경될 수 있으므로 sincedb 레코드가 재마운트간에 일치 하지 않을 수 잇다. 읽기 모드는 원격 파일 시스템에 적합하지 않을 수 있다. 클라이언트 측에서 검색 시 파일 크기가 원격 측에서 클라이언트 복사 프로세스의 지연 시간으로 인해 원격 시스템의 파일 크기와 같지 않을 수 있기 때문이다.

 

Tail 모드에서 파일 회전

파일 회전은 파일 이름 변경 또는 복사 작업을 통해 파일이 회전하는지에 관계없이 입력에 의해 감지되고 처리된다. 회전이 발생한 후 일정 시간 동안 회전된 파일에 쓰는 프로그램을 지원하려면 감시할 파일 이름(path 옵션)에 원래 파일 이름과 회전된 파일 이름(예: /var/log/syslog와 /var/log/syslog.1)을 모두 포함 해야한다. 이름 변경의 경우 inode는 /var/log/syslog에서 /var/log/syslog.1로 이동한 것으로 감지되며, 따라서 "state"도 내부적으로 이동하면 이전 콘텐츠는 다시 읽히지 않지만 이름이 바뀐 파일의 새 콘텐츠는 읽힌다. 복사/운영을 위해 복사된 내용을 새 파일 경로로 복사하여 발견되면, 새로운 발견으로 처리하고 처음부터 읽는다. 따라서 복사된 파일 경로는 감시할 파일이름 패턴(path 옵션)에 있지 않아야 한다. 트렌젝션이 감지되고 "마지막 읽기" 위치가 0으로 업데이트 된다.