Application Load Balancer 로그 쿼리
Application Load Balancer는 컨테이너를 사용하여 마이크로서비스 분포에서 트래픽 분배를 가능하게 하는, Elastic Load Balancing을 위한 로드 밸런싱 옵션입니다. Application Load Balancer 로그를 쿼리하면 Elastic Load Balancing 인스턴스 및 백엔드 애플리케이션과 주고 받는 트래픽, 지연 시간 및 바이트의 소스를 볼 수 있습니다. 자세한 내용은 Application Load Balancers 사용 설명서의 Application Load Balancer에 대한 액세스 로그 및 Application Load Balancer에 대한 연결 로그를 참조하세요.
주제
사전 조건
-
Application Load Balancer 로그를 Amazon S3 버킷에 저장할 수 있도록 액세스 로깅 또는 연결 로깅을 활성화합니다.
-
Athena용으로 만들 테이블을 보관할 데이터베이스입니다. 데이터베이스를 만들려면 Athena 또는 AWS Glue 콘솔을 사용하세요. 자세한 내용은 이 가이드의 Athena에서 데이터베이스 생성 또는 AWS Glue 개발자 안내서의 AWS glue 콘솔에서 데이터베이스 관련 작업을 참조하세요.
ALB 액세스 로그의 테이블 생성
-
다음
CREATE TABLE
문을 복사하여 Athena 콘솔의 쿼리 편집기에 붙여넣은 다음 자체 로그 항목 요구 사항에 필요한 대로 수정합니다. Athena 콘솔 시작하기에 대한 자세한 내용은 시작하기 섹션을 참조하세요.LOCATION
절의 경로를 Amazon S3 액세스 로그 폴더의 위치로 바꿉니다. 액세스 로그 파일 위치에 대한 자세한 내용은 Application Load Balancer 사용 설명서의 액세스 로그 파일을 참조하세요.각 로그 파일 필드에 대한 자세한 내용은 Application Load Balancer 사용 설명서의 액세스 로그 항목을 참조하세요.
참고
다음 예제
CREATE TABLE
문에는 최근에 추가된classification
,classification_reason
및conn_trace_id
('추적성 ID' 또는 TID) 열이 포함되어 있습니다. 이러한 항목을 포함하지 않은 Application Load Balancer 액세스 로그에 대한 테이블을 생성하려면CREATE TABLE
문에서 해당되는 열을 제거하고 그에 따라 정규 표현식을 수정합니다.CREATE EXTERNAL TABLE IF NOT EXISTS alb_access_logs ( type string, time string, elb string, client_ip string, client_port int, target_ip string, target_port int, request_processing_time double, target_processing_time double, response_processing_time double, elb_status_code int, target_status_code string, received_bytes bigint, sent_bytes bigint, request_verb string, request_url string, request_proto string, user_agent string, ssl_cipher string, ssl_protocol string, target_group_arn string, trace_id string, domain_name string, chosen_cert_arn string, matched_rule_priority string, request_creation_time string, actions_executed string, redirect_url string, lambda_error_reason string, target_port_list string, target_status_code_list string, classification string, classification_reason string, conn_trace_id string ) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe' WITH SERDEPROPERTIES ( 'serialization.format' = '1', 'input.regex' = '([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0-9]*) ([-.0-9]*) (|[-0-9]*) (-|[-0-9]*) ([-0-9]*) ([-0-9]*) \"([^ ]*) (.*) (- |[^ ]*)\" \"([^\"]*)\" ([A-Z0-9-_]+) ([A-Za-z0-9.-]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\" \"([^\"]*)\" ([-.0-9]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\" \"([^ ]*)\" \"([^\\s]+?)\" \"([^\\s]+)\" \"([^ ]*)\" \"([^ ]*)\" ?([^ ]*)?( .*)?' ) LOCATION 's3://DOC-EXAMPLE-BUCKET/
access-log-folder-path
/' -
Athena 콘솔에서 쿼리를 실행합니다. 쿼리가 완료된 후 Athena는
alb_access_logs
테이블을 등록하여 쿼리를 실행할 수 있도록 데이터를 준비합니다.
파티션 프로젝션을 사용하여 Athena에서 ALB 액세스 로그의 테이블 생성
ALB 액세스 로그에는 미리 지정할 수 있는 파티션 스키마를 가진 알려진 구조가 있기 때문에 Athena 파티션 프로젝션 기능을 사용하여 쿼리 런타임을 줄이고 파티션 관리를 자동화할 수 있습니다. 새 데이터가 추가되면 파티션 프로젝션은 자동으로 새 파티션을 추가합니다. 따라서 ALTER TABLE ADD PARTITION
을 사용해 파티션을 수동으로 추가할 필요가 없습니다.
다음 CREATE TABLE
문 예제에서는 하나의 AWS 리전에 대해 지정된 날짜부터 현재까지의 ALB 액세스 로그에 파티션 프로젝션을 자동으로 사용합니다. 이 문은 이전 섹션의 예제를 기반으로 하지만 파티션 프로젝션을 사용하기 위해 PARTITIONED BY
과 TBLPROPERTIES
절을 추가합니다. LOCATION
및 storage.location.template
절에서 자리 표시자를 ALB 액세스 로그의 Amazon S3 버킷 위치를 식별하는 값으로 바꿉니다. 액세스 로그 파일 위치에 대한 자세한 내용은 Application Load Balancer 사용 설명서의 액세스 로그 파일을 참조하세요. projection.day.range
에 대해 2022
/01
/01
을 사용하려는 시작 날짜로 바꿉니다. 쿼리가 성공적으로 실행된면 테이블을 쿼리할 수 있습니다. 파티션을 로드하기 위해 ALTER TABLE ADD PARTITION
을 실행하지 않아도 됩니다. 각 로그 파일 필드에 대한 자세한 내용은 액세스 로그 항목을 참조하세요.
CREATE EXTERNAL TABLE IF NOT EXISTS alb_access_logs ( type string, time string, elb string, client_ip string, client_port int, target_ip string, target_port int, request_processing_time double, target_processing_time double, response_processing_time double, elb_status_code int, target_status_code string, received_bytes bigint, sent_bytes bigint, request_verb string, request_url string, request_proto string, user_agent string, ssl_cipher string, ssl_protocol string, target_group_arn string, trace_id string, domain_name string, chosen_cert_arn string, matched_rule_priority string, request_creation_time string, actions_executed string, redirect_url string, lambda_error_reason string, target_port_list string, target_status_code_list string, classification string, classification_reason string, conn_trace_id string ) PARTITIONED BY ( day STRING ) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe' WITH SERDEPROPERTIES ( 'serialization.format' = '1', 'input.regex' = '([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0-9]*) ([-.0-9]*) (|[-0-9]*) (-|[-0-9]*) ([-0-9]*) ([-0-9]*) \"([^ ]*) (.*) (- |[^ ]*)\" \"([^\"]*)\" ([A-Z0-9-_]+) ([A-Za-z0-9.-]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\" \"([^\"]*)\" ([-.0-9]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\" \"([^ ]*)\" \"([^\\s]+?)\" \"([^\\s]+)\" \"([^ ]*)\" \"([^ ]*)\" ?([^ ]*)?( .*)?' ) LOCATION 's3://DOC-EXAMPLE-BUCKET/AWSLogs/
<ACCOUNT-NUMBER>
/elasticloadbalancing/<REGION>
/' TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.range" = "2022/01/01,NOW", "projection.day.format" = "yyyy/MM/dd", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "storage.location.template" = "s3://DOC-EXAMPLE-BUCKET/AWSLogs/<ACCOUNT-NUMBER>
/elasticloadbalancing/<REGION>
/${day}" )
파티션 프로젝션에 대한 자세한 내용은 Amazon Athena를 사용한 파티션 프로젝션 단원을 참조하세요.
ALB 액세스 로그의 쿼리 예제
다음 쿼리는 클라이언트 IP 주소별로 그룹화된 로드 밸런서가 수신한 HTTP GET 요청의 개수를 계산합니다:
SELECT COUNT(request_verb) AS count, request_verb, client_ip FROM alb_access_logs GROUP BY request_verb, client_ip LIMIT 100;
다른 쿼리는 Safari 브라우저 사용자가 방문한 URL을 보여줍니다:
SELECT request_url FROM alb_access_logs WHERE user_agent LIKE '%Safari%' LIMIT 10;
다음 쿼리는 ELB 상태 코드 값이 500보다 크거나 같은 레코드를 보여 줍니다.
SELECT * FROM alb_access_logs WHERE elb_status_code >= 500
다음 예에서는 datetime
을 통해 로그를 구문 분석하는 방법을 보여 줍니다.
SELECT client_ip, sum(received_bytes) FROM alb_access_logs WHERE parse_datetime(time,'yyyy-MM-dd''T''HH:mm:ss.SSSSSS''Z') BETWEEN parse_datetime('2018-05-30-12:00:00','yyyy-MM-dd-HH:mm:ss') AND parse_datetime('2018-05-31-00:00:00','yyyy-MM-dd-HH:mm:ss') GROUP BY client_ip;
다음 쿼리는 지정된 날짜의 모든 ALB 액세스 로그에 대해 파티션 프로젝션을 사용하는 테이블을 쿼리합니다.
SELECT * FROM alb_access_logs WHERE day = '2022/02/12'
ALB 연결 로그의 테이블 생성
-
다음 예제
CREATE TABLE
문을 복사하여 Athena 콘솔의 쿼리 편집기에 붙여넣은 다음 자체 로그 항목 요구 사항에 필요한 대로 수정합니다. Athena 콘솔 시작하기에 대한 자세한 내용은 시작하기 섹션을 참조하세요.LOCATION
절의 경로를 Amazon S3 연결 로그 폴더의 위치로 바꿉니다. 연결 로그 파일 위치에 대한 자세한 내용은 Application Load Balancer 사용 설명서의 연결 로그 파일을 참조하세요. 각 로그 파일 필드에 대한 자세한 내용은 연결 로그 항목을 참조하세요.CREATE EXTERNAL TABLE IF NOT EXISTS alb_connection_logs ( time string, client_ip string, client_port int, listener_port int, tls_protocol string, tls_cipher string, tls_handshake_latency double, leaf_client_cert_subject string, leaf_client_cert_validity string, leaf_client_cert_serial_number string, tls_verify_status string, conn_trace_id string ) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe' WITH SERDEPROPERTIES ( 'serialization.format' = '1', 'input.regex' = '([^ ]*) ([^ ]*) ([0-9]*) ([0-9]*) ([A-Za-z0-9.-]*) ([^ ]*) ([-.0-9]*) \"([^\"]*)\" ([^ ]*) ([^ ]*) ([^ ]*) ?([^ ]*)?( .*)?' ) LOCATION 's3://DOC-EXAMPLE-BUCKET/
connection-log-folder-path
/' -
Athena 콘솔에서 쿼리를 실행합니다. 쿼리가 완료된 후 Athena는
alb_connection_logs
테이블을 등록하여 쿼리를 실행할 수 있도록 데이터를 준비합니다.
파티션 프로젝션을 사용하여 Athena에서 ALB 연결 로그의 테이블 생성
ALB 연결 로그에는 미리 지정할 수 있는 파티션 스키마를 가진 알려진 구조가 있기 때문에 Athena 파티션 프로젝션 기능을 사용하여 쿼리 런타임을 줄이고 파티션 관리를 자동화할 수 있습니다. 새 데이터가 추가되면 파티션 프로젝션은 자동으로 새 파티션을 추가합니다. 따라서 ALTER TABLE ADD PARTITION
을 사용해 파티션을 수동으로 추가할 필요가 없습니다.
다음 CREATE TABLE
문 예제에서는 하나의 AWS 리전에 대해 지정된 날짜부터 현재까지의 ALB 연결 로그에 파티션 프로젝션을 자동으로 사용합니다. 이 문은 이전 섹션의 예제를 기반으로 하지만 파티션 프로젝션을 사용하기 위해 PARTITIONED BY
과 TBLPROPERTIES
절을 추가합니다. LOCATION
및 storage.location.template
절에서 자리 표시자를 ALB 연결 로그의 Amazon S3 버킷 위치를 식별하는 값으로 바꿉니다. 연결 로그 파일 위치에 대한 자세한 내용은 Application Load Balancer 사용 설명서의 연결 로그 파일을 참조하세요. projection.day.range
에 대해 2023
/01
/01
을 사용하려는 시작 날짜로 바꿉니다. 쿼리가 성공적으로 실행된면 테이블을 쿼리할 수 있습니다. 파티션을 로드하기 위해 ALTER TABLE ADD PARTITION
을 실행하지 않아도 됩니다. 각 로그 파일 필드에 대한 자세한 내용은 연결 로그 항목을 참조하세요.
CREATE EXTERNAL TABLE IF NOT EXISTS alb_connection_logs ( time string, client_ip string, client_port int, listener_port int, tls_protocol string, tls_cipher string, tls_handshake_latency double, leaf_client_cert_subject string, leaf_client_cert_validity string, leaf_client_cert_serial_number string, tls_verify_status string, conn_trace_id string ) PARTITIONED BY ( day STRING ) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe' WITH SERDEPROPERTIES ( 'serialization.format' = '1', 'input.regex' = '([^ ]*) ([^ ]*) ([0-9]*) ([0-9]*) ([A-Za-z0-9.-]*) ([^ ]*) ([-.0-9]*) \"([^\"]*)\" ([^ ]*) ([^ ]*) ([^ ]*) ?([^ ]*)?( .*)?' ) LOCATION 's3://DOC-EXAMPLE-BUCKET/AWSLogs/
<ACCOUNT-NUMBER>
/elasticloadbalancing/<REGION>
/' TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.range" = "2023/01/01,NOW", "projection.day.format" = "yyyy/MM/dd", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "storage.location.template" = "s3://DOC-EXAMPLE-BUCKET/AWSLogs/<ACCOUNT-NUMBER>
/elasticloadbalancing/<REGION>
/${day}" )
파티션 프로젝션에 대한 자세한 내용은 Amazon Athena를 사용한 파티션 프로젝션 단원을 참조하세요.
ALB 연결 로그의 쿼리 예제
다음 쿼리는 tls_verify_status
값이 'Success'
가 아닌 발생 항목 수를 세고, 클라이언트 IP 주소별로 그룹화합니다.
SELECT DISTINCT client_ip, count() AS count FROM alb_connection_logs WHERE tls_verify_status != 'Success' GROUP BY client_ip ORDER BY count() DESC;
다음 쿼리는 지정된 시간 범위에서 tls_handshake_latency
값이 2초를 초과하는 발생 항목을 검색합니다.
SELECT * FROM alb_connection_logs WHERE ( parse_datetime(time, 'yyyy-MM-dd''T''HH:mm:ss.SSSSSS''Z') BETWEEN parse_datetime('2024-01-01-00:00:00', 'yyyy-MM-dd-HH:mm:ss') AND parse_datetime('2024-03-20-00:00:00', 'yyyy-MM-dd-HH:mm:ss') ) AND (tls_handshake_latency >= 2.0);
추가 리소스
-
AWS 지식 센터의 Amazon Athena를 사용하여 Application Load Balancer 액세스 로그를 분석하려면 어떻게 해야 합니까?
를 참조하세요. -
Elastic Load Balancing에서 HTTP 상태 코드에 대한 자세한 내용은 Application Load Balancer 사용 설명서의 Application Load Balancer 문제 해결을 참조하세요.
-
AWS 빅 데이터 블로그의 Catalog and analyze Application Load Balancer logs more efficiently with AWS Glue custom classifiers and Amazon Athena
를 참조하세요.