[AWS] 📚 ELB(ALB) 로그 활성화 & S3에 로그 저장하기

...

ALB Access Log

ALB Access Log는 말 그대로 단순 트래픽 로그다.

로드밸런서 DNS를 통해 사용자들이 로드밸런서를 경유해 인스턴스로 접속할때 기록된다.

이 로그를 통해 ELB-respose, Target-response, Client, 접근 경로 등을 알 수 있어서, 클라우드 환경에서 서비스를 올린다면 자주 접해야 하는 로그이다.

하지만 Access Log를 통해 Client의 요청이 어디까지 도달했는지, 무슨 에러를 뱉었는지, 어떤 요청을 했을 때 어떤 반응을 보였는지 ..등 대략적인 추측이 가능하나, 정확한 점검을 위해선 어플리케이션 점검이 필수적이다.

ALB Access Log 특징으로는 다음과 같다.

Timstamp는 UTC 기준 : KST 기준이 아니므로 특정 시간대의 트래픽 로그를 찾을 때, 그 로그는 그 전날 혹은 그다음 날 이름의 로그 데이터에 쌓여있을 수 있다.
ALB Access Log는 5분 단위로 저장 : 예를 들어 08:03에 발생한 트래픽은 08:00~08:05 사이로 08:05 기준 트래픽에 저장된다.
Network Interface 마다 나눠져서 저장 : 내부적으로 ALB가 Scale-Out 되면 그 수만큼 나눠져서 저장된다. 따라서 특정 시간대에 트래픽을 분석하려 한다면 모든 Network Interface를 분석해야 한다.

ALB Access Log 활성화 및 S3 저장 설정

보통 이러한 로그 파일들은 시간이 지나면 지날수록 대용량이 되기 때문에 보통 S3 버킷에다가 저장하는 편이다.

로그 기능 활성화에 추가 요금은 없으며 로그 저장을 위한 S3 버킷 과금만 발생하니 웹서비스를 운영한다면 웬만해선 설정해주는 것이 좋다.

이번 시간에는 ELB(ALB) 엑세스 로그 기록을 활성화 하고, 로그 파일들을 자동으로 S3 버킷에 업로드하도록 설정해보도록 하자.

ELB(Application Load Balancer) 만들기

EC2 인스턴스 2개와 로드밸런서를 준비한다.

다음 포스팅에 로드밸런서 실전 구축 세팅에 대해 자세히 나열되어있다.

[AWS] 📚 ELB(Load Balancer) 개념 원리 & 사용 세팅 💯 정리

ELB (Elastic Load Balancer) ELB(Elastic Load Balancer)란 애플리케이션 트래픽을 여러 대상에 자동으로 분산시켜 안정적인 AWS서버 환경을 운용하는데에 도움을 주는 서비스다. EC2뿐만 아니라 컨테이너(ECS)..

inpa.tistory.com

버킷 생성 & 버킷 정책 설정

필자는 athena-log-test-11 라는 버킷을 만들어주었다.

그리고 버킷정책으로는 다음 json에 <> 꺾쇠 괄호 부분만 자신의 AWS 서버에 맞게 바꿔주면 된다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<elb-account-id>:root"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::<버킷명>/<경로>/AWSLogs/<your-aws-account-id>/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "logdelivery.elb.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::<버킷명>"
    }
  ]
}

elb-account-id 입력값으로 다음 표를 참고해 자신의 Region에 맞게 ELB ID를 적어준다.

your-aws-account-id 입력값으로 자신의 계정 ID 넘버를 적어주면 된다. (- 를 지우고 숫자만 적는다.)

ALB Access Log 활성화 하기

버킷 정책이 완료되었으면, 다음으로 ELB > Description > Attributes 에서 Access logs 를 활성화 시켜주도록 한다.

위에서 정책 설정이 제대로 안되있으면 활성화 자체가 안되니 정책을 다시 확인해보자.

문제없이 설정이 되면, 다음 엑세스 로그 S3 위치가 설정된다.

버킷에서 ALB 로그 확인

ALB 액세스 로그 활성화가 완료되면 지정했던 S3 버킷 경로로 가서 ELBAccessLogTestFile이 있는지 확인해주자.

파일이 있으면 제대로 연동된 것이다.

그리고 로드밸런서를 통해 인스턴스로 접속을 해보면, elasticloadbalancing 폴더가 생기게 되고, 안에는 날짜별로 폴더가 생성되어 로그가 .gz 로 압축되어 저장되어진다.

로드밸런서로 접속했다고 바로는 로그가 쌓이지 않는다. 조금 기다리면 보일 것이다.

압축파일을 열어보면 다음과 같이 접속 로그가 기록되어 있음을 확인 할 수 있다.

ALB Access Log 분석하기

Access logs for your Application Load Balancer - Elastic Load Balancing

Access logs for your Application Load Balancer Elastic Load Balancing provides access logs that capture detailed information about requests sent to your load balancer. Each log contains information such as the time the request was received, the client's IP

docs.aws.amazon.com

ALB 로그를 살펴보면 여러 문자열들이 나열되어있는데, 띄어쓰기(공백)을 기준으로 다음과 같은 포맷 순서대로 이루어져 있다.

[type] [time] [elb] [client:port] [target:port] [request_processing_time] [target_processing_time] [response_processing_time] [elb_status_code] [target_status_code] [received_bytes] [sent_bytes] ["request"] ["user_agent"] [ssl_cipher] [ssl_protocol] [target_group_arn] ["trace_id"] ["domain_name"] ["chosen_cert_arn"] [matched_rule_priority] [request_creation_time] ["actions_executed"] ["redirect_url"] ["error_reason"] ["target:port_list"] ["target_status_code_list"] ["classification"] ["classification_reason"]