재시도 한계

기본적으로 로깅 에이전트 은 오류가 발생하면 성공할 때까지 로그 전송을 계속 재시도하도록 구성되어 있습니다. 기본 동작은 retryLimit: false 매개변수로 구성됩니다. Kubernetes 환경에서는 로깅 에이전트 configmap에서, Linux 환경에서는 로깅 에이전트 config 파일에서 관리합니다.

기본값인 retryLimit 값을 변경하면 데이터가 삭제될 가능성이 있습니다. 예를 들어 retryLimit: "no_retries" 은 오류 발생 시 로깅 에이전트 이 로그 전송을 전혀 다시 시도하지 않음을 나타냅니다. 예를 들어 retryLimit: 8 과 같은 정수 값을 지정하면 로깅 에이전트 에서 지정된 횟수(8) 동안 로그 전송을 재시도한 후 로그가 삭제됩니다.

플루언트 비트에서 재시도 간격을 예약하는 방법에 대한 자세한 내용은 예약 및 재시도를 참조 하세요

유창한 비트 버퍼링

로깅 에이전트 은 기본적으로 플루언트 비트 filesystem 버퍼링을 사용하도록 구성되어 있습니다. 이 구성은 시스템 장애 발생 시 로깅 에이전트 에서 처리된 로그가 파일 저장소에 보관된다는 것을 의미합니다. 로깅 에이전트 사이트가 다시 시작되면 filesystem 버퍼의 로그가 처리됩니다.

memory 버퍼링을 사용하도록 구성을 변경했는데 로깅 에이전트 사이트가 예기치 않게 종료되거나 종료되는 문제가 발생하면 memory 버퍼에 있는 로그가 삭제될 수 있습니다.

자세한 내용은 버퍼링 및 저장소를 참조하세요.

로그 로테이션

로깅 에이전트 에서 로그 파일을 처리하기 전에 환경이 로그 파일을 회전하는 경우 로그가 삭제될 가능성이 있습니다. 로깅 에이전트 가 상당 시간 동안 실행이 중지되면 로그 순환으로 인한 데이터 손실이 발생할 수 있습니다.

Kubernetes

IBM 관리형 클러스터에서는 /var/log/containers 의 모든 stdout 컨테이너 로그 파일이 kublet에 의해 관리됩니다. 각 컨테이너 로그 파일은 100MiB 크기에 도달하면 회전됩니다. 로테이션 후에는 컨테이너당 최대 3개의 로그 파일이 유지됩니다. 이러한 파일의 크기와 개수는 구성할 수 없습니다.

로깅 에이전트 에서 데이터를 처리하기 전에 로그 파일이 채워지고 회전하는 경우 처리되지 않은 로그가 삭제될 수 있습니다.

Linux

로그 순환 처리는 Linux 에서 구성할 수 있습니다. 예를 들어 logrotate 도구를 사용합니다.

로깅 에이전트 에서 데이터를 처리하기 전에 로그 파일이 채워지고 회전하는 경우 처리되지 않은 로그가 삭제될 수 있습니다.

Windows

로그 로테이션 처리는 Windows에서 구성할 수 있습니다. 그러나 로그 로테이션을 위한 기본 제공 Windows 도구는 존재하지 않습니다. 타사 애플리케이션 또는 기본 제공 애플리케이션 설정을 사용하여 로그 로테이션을 구성할 수 있습니다.

로깅 에이전트 에서 데이터를 처리하기 전에 로그 파일이 채워지고 회전하는 경우 처리되지 않은 로그가 삭제될 수 있습니다.