S3 서버 액세스 로그, ELB 액세스 로그, CloudWatch 로그, VPC 플로우 로그 등 여러 다른 다양한 AWS 서비스의 로그를 S3 버킷에 저장할 수 있습니다. 예를 들어, S3 서버 액세스 로그는 버킷에 이루어진 요청에 대한 상세한 레코드를 제공합니다. 이것은 대단히 유용한 정보이지만 아쉽게도 AWS는 여러 운영에 대해 여러 .txt 파일을 생성하여 각 개별 .txt 파일을 모두 열어보지 않고는 로그 파일에 정확히 어느 운영이 기록되어 있는지 알기가 어렵습니다. 아울러, S3 서버 액세스 로그는 복잡한 형식으로 기록되어, 사용자가 단순히 .txt 파일을 열어 필요한 정보를 찾기가 대단히 어렵습니다.
다행히도, 모든 AWS 로그는 Elastic Stack을 통해 손쉽게 색인, 분석, 시각화될 수 있어, 여기에 포함된 모든 중요한 데이터를 활용할 수 있습니다. 이 블로그에서는 이 작업이 얼마나 쉬운지를 살펴보겠습니다.
들어가는 말
Filebeat 7.4에서는 s3 입력이 사용자에게 옵션이 되었기 때문에 S3 버킷의 파일에서 이벤트를 검색할 수 있으며, 각 파일의 각 줄은 별개의 이벤트가 됩니다. s3 입력과 더불어, 또한 Filebeat AWS 모듈에 대해 두 개의 새로운 파일 세트를 제공합니다. 바로 s3access 파일 세트와 elb 파일 세트(7.5 버전에 새로 탑재)입니다. 이 파일 세트를 이용해 사용자는 다른 S3 버킷에서 로그를 수집한 다음 각 파일을 다운로드하거나 수동으로 열지 않고도 중앙화된 위치에서 이 수집된 로그를 시각화하고 분석할 수 있습니다.
각 S3 버킷에서 모든 로그 파일을 폴링할 때 상당한 지연을 피하기 위해, 우리는 알림과 폴링을 결합하기로 결정했습니다. 따라서 새로운 S3 객체가 생성될 때 Amazon S3에 대해 Amazon Simple Queue Service(SQS)를 이용할 수 있습니다. Filebeat s3 입력은 S3에서 생성되는 새로운 객체에 관한 새 메시지에 대해 SQS를 확인하고 이 메시지의 정보를 사용해 S3 버킷으로부터 로그를 검색합니다. 이 설정으로 각 S3 버킷에서 주기적인 폴링을 할 필요가 없어집니다. 대신에 Filebeat s3 입력은 S3 버킷으로부터 속도와 안정성 면에서 거의 실시간에 가까운 데이터 수집을 보장합니다.
SQS를 이용한 S3 이벤트 알림 구성
다음 네 단계에 따라 사용자는 AWS S3를 요청하는 버킷의 알림 구성을 추가하여 s3:ObjectCreated:* 유형의 이벤트를 AWS SQS 대기열에 게시할 수 있습니다. 자세한 내용은 버킷 알림 구성 예제 상세 안내를 참조하세요.
1단계: SQS 대기열과 S3 버킷 생성
Amazon SQS 콘솔을 사용해 동일한 AWS 지역에서 SQS 대기열과 S3 버킷을 생성합니다.
2단계: SQS 대기열 구성
대기열에 첨부된 액세스 정책을 다음 대기열 정책으로 대체합니다.
{
"Version": "2012-10-17",
"Id": "example-ID",
"Statement": [
{
"Sid": "example-statement-ID",
"Effect": "Allow",
"Principal": {
"AWS":"*"
},
"Action": [
"SQS:SendMessage"
],
"Resource": "<SQS-queue-ARN>",
"Condition": {
"ArnLike": { "aws:SourceArn": "arn:aws:s3:*:*:<bucket-name>" }
}
}
]
}
해당 SQS 대기열 및 S3 버킷 이름과 일치되도록 <sqs-queue-arn> 및 <bucket-name> 변경을 잊지 말고 수행하세요.
3단계: S3 버킷 구성
Amazon S3 콘솔을 사용해 Amazon S3가
Amazon SQS 대기열에
s3:ObjectCreated:* 유형의 이벤트를 게시하도록 요청하는 알림 구성을 추가합니다.
4단계: 테스트 S3-SQS 설정
S3 버킷으로 객체를 업로드하고 Amazon SQS 콘솔에서 이벤트 알림을 확인합니다.
Filebeat s3 입력 사용
s3 입력으로 Filebeat를 활성화하여 사용자는 AWS S3 버킷으로부터 로그를 수집할 수 있게 됩니다. 각 로그 파일의 모든 줄이 별개의 이벤트가 되어 Elasticsearch처럼 구성된 Filebeat 출력에 저장됩니다. s3 입력만 사용하여 메시지가 구문 분석 없이 각 이벤트의 message 필드에 저장됩니다.
SQS 메시지에 의해 참조되는 S3 객체를 처리할 때, 구성된 가시성 타임아웃의 반이 지나고 처리가 여전히 계속되고 있으면, 해당 SQS 메시지의 가시성 타임아웃이 재설정되어 메시지가 처리 도중에 대기열로 돌아가지 않도록 합니다. S3 객체의 처리 중에 발생하는 오류가 있으면, 처리가 중단되고 SQS 메시지가 대기열로 다시 반환됩니다.
0단계: IAM 정책 생성
IAM 정책은 AWS 환경 내 객체에 대한 권한을 정의하는 엔터티입니다. 특정 권한으로 Filebeat에 대한 사용자 지정 IAM 정책을 생성해야 합니다. 자세한 내용은 IAM 정책 생성을 참조하세요. 다음은 SQS 및 S3에 액세스하는 데 필요한 권한 목록입니다.- s3:GetObject
- sqs:ReceiveMessage
- sqs:ChangeMessageVisibility
- sqs:DeleteMessage
1단계: Filebeat 설치
Filebeat를 다운로드하고 설치하기 위해, 다른 시스템에 대해 작동하는 다른 명령이 있습니다. 예를 들어, Mac의 경우는 다음과 같습니다.
curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.5.1-darwin-x86_64.tar.gz tar xzvf filebeat-7.5.1-darwin-x86_64.tar.gz
자세한 정보는 Filebeat 설치를 참조하세요.
2단계: s3 입력 구성
다음은 filebeat.yml에서 s3 입력을 활성화하는 예제입니다.
filebeat.inputs: - type: s3 queue_url: https://sqs.us-east-1.amazonaws.com/1234/test-fb-ks visibility_timeout: 300s credential_profile_name: elastic-beats
이 구성을 통해, Filebeat는 test-fb-ks AWS SQS 대기열로 이동하여 알림 메시지를 읽게 됩니다. 메시지로부터, Filebeat는 특정 S3 객체들에 대한 정보를 얻고 객체를 한 줄씩 읽게 됩니다. visibility_timeout은 받은 메시지가 ReceiveMessage 요청에 의해 검색된 후 다음 검색 요청으로부터 숨겨지는 기간(단위: 초)입니다. 기본 설정으로 visibility_timeout은 300초입니다. 최소 0초이며 최대 12시간입니다. AWS API 호출을 하려면, s3 입력은 구성에서 AWS 자격 증명이 필요합니다. 위의 예제에서는, AWS API 호출을 하기 위해 프로필 이름 elastic-beats가 제공됩니다. 자세한 정보는 AWS 자격 증명 구성을 참조하세요.
3단계: Filebeat 시작
Mac과 Linux의 경우, 다음과 같습니다.
sudo chown root filebeat.yml sudo ./filebeat -e
자세한 정보는 Filebeat 시작을 참조하세요.
s3access 파일 세트를 이용한 S3 서버 액세스 로그 수집
Filebeat 7.4에서는 s3 입력을 이용해 S3 서버 액세스 로그를 수집하기 위해 s3access 파일 세트가 추가되었습니다. 서버 액세스 로그는 버킷에 이루어지는 요청에 대한 상세한 레코드를 제공하며, 이것은 보안과 액세스 감사에서 대단히 유용할 수 있습니다. 기본 설정으로, 서버 액세스 로깅은 비활성화되어 있습니다. 버킷에 대한 액세스 요청을 추적하기 위해, 서버 액세스 로깅을 활성화할 수 있습니다. 각 액세스 로그 레코드는 관련된 경우 요청자, 버킷 이름, 요청 시간, 요청 작업, 응답 상태, 오류 코드 등 단일한 액세스 요청에 대한 세부 사항을 제공합니다.
1단계: 서버 액세스 로깅 활성화
특정한 S3 버킷의 속성에서 로깅 활성화를 선택하여 서버 액세스 로깅을 활성화할 수 있습니다.
2단계: Filebeat에서 aws 모듈 활성화
Filebeat의 기본 구성에서, aws 모듈은 활성화되어 있지 않습니다. 다음 명령을 사용하면 MacOS 및 Linux 시스템의 modules.d 디렉토리에서 aws 구성을 활성화할 수 있습니다.
sudo ./filebeat modules enable aws
3단계: aws 모듈 구성
기본 설정으로, s3access 파일 세트는 비활성화되어 있습니다. s3access 파일 세트를 활성화하려면, 아래의 aws.yml을 참조하세요.
- module: aws
s3access:
enabled: true
var.queue_url: https://sqs.myregion.amazonaws.com/123456/myqueue
var.credential_profile_name: fb-aws
4단계: Filebeat 시작
Mac과 Linux의 경우, 다음과 같습니다.
sudo chown root filebeat.yml sudo ./filebeat -e
자세한 정보는 Filebeat 시작을 참조하세요.
5단계: Kibana s3access 파일 세트 대시보드 사용
s3access 파일 세트에는 [Filebeat AWS] S3 서버 액세스 로그 개요라고 하는 미리 정의된 대시보드가 포함되어 있습니다. Filebeat를 시작할 때 설정 명령을 실행하면 Kibana에서 이러한 대시보드가 자동으로 설정됩니다.
Mac과 Linux의 경우, 다음과 같습니다.
./filebeat setup --dashboards
이에 대한 자세한 정보는 Kibana 대시 보드 설정 설명서를 참조하세요.
이 대시보드는 AWS S3 서버 액세스 로그의 개요입니다. 여기서는 최고 순위 URL들과 그 응답 코드, 시간에 따른 HTTP 상태, 모든 오류 로그 등을 보여줍니다.
그 다음은 무엇일까요?
Filebeat s3 입력을 통해 사용자는 AWS 서비스에서 손쉽게 로그를 수집하고 이 로그를 이벤트로 저희 Elastic Cloud의 Elasticsearch Service로 전송하거나 기본 배포를 실행해 클러스터로 전송할 수 있습니다. 7.4에서는 S3 서버 액세스 로그를 수집하고 분석하기 위해 사용자에게 s3access 파일 세트가 제공됩니다. 7.5에서는 클래식 로드 밸런서, 애플리케이션 로드 밸런서, 네트워크 로드 밸런서로부터 로그를 수집할 수 있도록 사용자에게 elb 파일 세트가 제공됩니다. 가까운 미래에, VPC 플로우 로그, CloudWatch 로그, Cloudtrail 로그와 같은 일반적으로 사용되는 다른 로그를 지원하기 위해 더 많은 파일 세트를 추가하기 시작할 예정입니다. 질문이나 피드백이 있으시면, Beats 토론 포럼에 자유롭게 글을 올려주세요!