Linux 시스템의 Amazon Kinesis Agent 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

이 문서에서는 다음과 같은 문제를 다룹니다.

• Kinesis Agent가 중복 이벤트를 보냅니다.
• Kinesis Agent로 인해 Amazon Kinesis 스트림에서 쓰기 제한과 실패한 레코드가 발생합니다.
• Kinesis Agent가 로그 파일을 읽거나 스트리밍할 수 없습니다.
• Java 힙 크기가 부족하여 Amazon Elastic Computing(Amazon EC2) 서버가 계속 실패합니다.
• 내 Amazon EC2 CPU 사용률이 매우 높습니다.

해결 방법

Kinesis Agent가 중복 이벤트를 전송하는 경우

Kinesis Agent에서 로그를 전송할 때마다 중복이 발생하는 경우 일치 패턴이 제대로 검증되지 않은 파일 순환이 발생할 수 있습니다. 로그를 보낼 때마다 Kinesis Agent는 파일 패턴과 일치하는 각 파일의 latestUpdateTimestamp를 확인합니다. 기본적으로 Kinesis Agent는 가장 최근에 업데이트된 파일을 선택하여 순환 패턴과 일치하는 활성 파일을 식별합니다. 둘 이상의 파일이 동시에 업데이트되는 경우 Kinesis Agent는 추적할 활성 파일을 확인할 수 없습니다. 따라서 Kinesis Agent는 처음부터 업데이트된 파일을 따르기 시작하여 여러 개의 중복이 발생합니다.

이 문제를 방지하려면 각 개별 파일에 대해 서로 다른 파일 흐름을 만들고 대신 파일 패턴이 순환을 추적하는지 확인합니다.

참고: 순환을 추적하는 경우 copytruncate 대신 로그 순환 생성 또는 이름 바꾸기 설정을 사용하는 것이 좋습니다.

예를 들어 다음과 유사한 파일 흐름을 사용할 수 있습니다.

"flows": [
        {
            "filePattern": "/tmp/app1.log*",
            "kinesisStream": "yourkinesisstream1"
        },
        {
            "filePattern": "/tmp/app2.log*",
            "kinesisStream": "yourkinesisstream2"
        }
    ]

또한 Kinesis Agent는 간헐적인 네트워크 문제가 있을 때 다시 보내지 못한 모든 레코드를 다시 시도합니다. Kinesis Agent가 서버 측 승인을 받지 못한 경우 다시 시도하여 중복을 생성합니다. 이 예에서 다운스트림 애플리케이션은 중복을 제거해야 합니다.

체크포인트 파일을 조정하거나 제거할 때도 중복이 발생할 수 있습니다. 체크포인트 파일이 /var/run/aws-kinesis-agent에 저장되어 있는 경우 재설치 또는 인스턴스 재부팅 중에 파일이 정리될 수 있습니다. Kinesis Agent를 다시 실행하면 파일을 읽는 즉시 애플리케이션이 실패하여 중복이 발생합니다. 따라서 체크포인트를 기본 Agent 디렉터리에 유지하고 Kinesis Agent 구성을 새 위치로 업데이트합니다.

예:

"checkpointFile": "/aws-kinesis-agent-checkpoints/checkpoints"

Kinesis Agent로 인해 Amazon Kinesis 데이터 스트림에서 쓰기 제한과 실패한 레코드가 발생하는 경우

기본적으로 Kinesis Agent는 Kinesis의 처리량 임계값을 위반하여 가능한 한 빨리 로그 파일을 전송하려고 시도합니다. 그러나 실패한 레코드는 다시 대기열에 추가되고 데이터 손실을 방지하기 위해 계속 재시도됩니다. 대기열이 꽉 차면 Kinesis Agent가 파일 미행을 중지하여 애플리케이션이 지연될 수 있습니다.

예를 들어 대기열이 꽉 찬 경우 로그는 다음과 비슷합니다.

com.amazon.kinesis.streaming.agent.Agent [WARN] Agent: Tailing is 745.005859 MB (781195567 bytes) behind.

참고: 대기열 크기는 publishQueueCapacity 파라미터(기본값은 “100"으로 설정됨)에 의해 결정됩니다.

Kinesis 데이터 스트림에서 실패한 레코드 또는 성능 문제를 조사하려면 다음을 시도합니다.

• Amazon CloudWatch에서 RecordSendErrors 지표를 모니터링합니다.
• Kinesis Agent 로그를 검토하여 지연이 발생했는지 확인합니다. ProvisionedThroughputExceededException 항목은 DEBUG 로그 수준에서만 볼 수 있습니다. 이 시간 동안 대부분의 CPU를 사용하여 데이터를 구문 분석하고 변환하는 경우 Kinesis Agent의 레코드 전송 속도가 느려질 수 있습니다.
• Kinesis Agent가 지연되는 것을 발견하면 Amazon Kinesis 전송 스트림을 확장하는 것이 좋습니다.

Kinesis Agent가 로그 파일을 읽거나 스트리밍할 수 없는 경우

Kinesis Agent가 실행 중인 Amazon EC2 인스턴스에 대상 Kinesis 전송 스트림에 액세스할 수 있는 적절한 권한이 있는지 확인합니다. Kinesis Agent가 로그 파일을 읽지 못하는 경우 Kinesis Agent에 해당 파일에 대한 읽기 권한이 있는지 확인합니다. 이 패턴과 일치하는 모든 파일에 대해 aws-kinesis-agent-user에게 읽기 권한을 부여해야 합니다. 파일이 포함된 디렉터리의 경우 aws-kinesis-agent-user에게 읽기 및 실행 권한도 부여해야 합니다. 그렇지 않으면 액세스 거부 오류 또는 Java 런타임 예외가 발생합니다.

Java 힙 크기가 부족하여 Amazon EC2 서버에 계속 장애가 발생하는 경우

Java 힙 크기가 부족하여 Amazon EC2 서버에 계속 장애가 발생하는 경우 Amazon Kinesis Agent에 할당된 힙 크기를 늘립니다. Kinesis Agent에서 사용할 수 있는 메모리 양을 구성하려면 ‘start-aws-kinesis-agent’ 파일을 업데이트합니다. 다음 파라미터의 설정 값을 늘립니다.

• JAVA_START_HEAP
• JAVA_MAX_HEAP

참고: 리눅스에서 ‘start-aws-kinesis-agent’의 파일 경로는 ‘/usr/bin/start-aws-kinesis-agent’입니다.

내 Amazon EC2 CPU 사용률이 매우 높은 경우

Kinesis Agent가 최적화되지 않은 정규식 패턴 일치 및 로그 변환을 수행하는 경우 CPU 사용률이 급증할 수 있습니다. Kinesis Agent를 이미 구성한 경우 모든 정규식(regex) 패턴 일치 및 변환을 제거해 봅니다. 그런 다음 여전히 CPU 문제가 발생하는지 확인합니다.

여전히 CPU 문제가 발생하면 메모리에 버퍼링되는 스레드와 레코드를 튜닝하는 것이 좋습니다. 또는 /etc/aws-kinesis/agent.json 구성 설정 파일에서 일부 기본 파라미터를 업데이트합니다. Kinesis Agent 구성 파일에서 여러 파라미터를 낮출 수도 있습니다.

다음은 낮출 수 있는 일반적인 구성 파라미터입니다.

• sendingThreadsMaxQueueSize: 대상으로 데이터를 전송하기 위한 threadPool의 workQueue 크기입니다. 기본값은 100입니다.
• maxSendingThreads: 대상으로 데이터를 전송하기 위한 스레드 수입니다. 최소값은 2입니다. 기본값은 컴퓨터의 코어 수의 12배입니다.
• maxSendingThreadsPerCore: 대상으로 데이터를 전송하기 위한 코어당 스레드 수입니다. 기본값은 12입니다.

낮출 수 있는 흐름 구성 파라미터는 다음과 같습니다.

• publishQueueCapacity: 대상으로 전송되기 전에 대기열에 넣을 수 있는 레코드의 최대 버퍼 수입니다. 기본값은 100입니다.
• minTimeBetweenFilePollsMillis: 추적된 파일이 폴링되고 새 데이터가 구문 분석되기 시작하는 시간 간격입니다. 기본값은 100입니다.

---