이전 포스팅에서 로그 확인을 위한 S3 버킷을 생성해 봤다.
이번에는 로그를 직접 확인해 보자.
S3 버킷에 생성된 로그를 확인해 보자.
로그는 저장할 로그가 있을 때 마다 5분 단위로, 새로 생성이 된다.
h2 2023-04-01T05:06:32.491649Z app/zangsuBackendBalancer/1f660d92f10232d3
155.230.84.160:51267 172.31.22.203:80 0.001 0.001 0.000 200 200 23 318
"GET https://zangsu-backend.store:443/result HTTP/2.0" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
TLS_AES_128_GCM_SHA256 TLSv1.3 arn:aws:elasticloadbalancing:ap-southeast-2:521950034805:
targetgroup/moon-jang/7a955228ca838b80 "Root=1-6427bbd8-35c2e80f3bd4e60d7938f5d8"
"zangsu-backend.store" "arn:aws:acm:ap-southeast-2:521950034805:certificate/42464b91-e70c-44dc-
bb95-05097df2946e" 0 2023-04-01T05:06:32.489000Z "forward" "-" "-" "172.31.22.203:80"
"200" "-" "-"
h2 2023-04-01T05:06:35.755129Z app/zangsuBackendBalancer/1f660d92f10232d3
155.230.84.160:51267 172.31.22.203:443 -1 -1 -1 502 - 23 594
"GET https://zangsu-backend.store:443/result HTTP/2.0" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
TLS_AES_128_GCM_SHA256 TLSv1.3 arn:aws:elasticloadbalancing:ap-southeast-2:521950034805:
targetgroup/moon-jang/7a955228ca838b80 "Root=1-6427bbdb-434d342c0651b46071c217ff"
"zangsu-backend.store" "arn:aws:acm:ap-southeast-2:521950034805:certificate/42464b91-e70c-44dc-
bb95-05097df2946e" 0 2023-04-01T05:06:35.754000Z "forward" "-" "-" "172.31.22.203:443"
"-" "-" "-"
위의 메시지는 내 로드밸런서에서 출력한 로그이다.
지금은 내가 보기 좋게 개행을 추가했지만, 원래 각 로그는 공백으로 구분이 된다.
각 로그에 대한 정보는 AWS Docs - Syntax 에서 확인할 수 있다.
문제 로그를 각 정보로 정리하면 다음과 같다.
Field | logs |
---|---|
type | h2 |
time | 2023-04-01T05:06:32.491649Z |
elb | app/zangsuBackendBalancer/1f660d92f10232d3 |
client:port | 155.230.84.160:51267 |
target:port | 172.31.22.203:443 |
request_processing_time | -1 |
target_processing_time | -1 |
response_processing_time | -1 |
elb_status_code | 502 |
target_status_code | - |
received_bytes | 23 |
sent_bytes | 594 |
"request" | "GET https://zangsu-backend.store:443/result HTTP/2.0" |
"user_agent" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36" |
ssl_cipher | TLS_AES_128_GCM_SHA256 |
ssl_protocol | TLSv1.3 |
target_group_arn | arn:aws:elasticloadbalancing:ap-southeast-2:521950034805:targetgroup/moon-jang/7a955228ca838b80 |
"trace_id" | "Root=1-6427bbdb-434d342c0651b46071c217ff" |
"domain_name" | "zangsu-backend.store" |
"chosen_cert_arn" | "arn:aws:acm:ap-southeast-2:521950034805:certificate/42464b91-e70c-44dc-bb95-05097df2946e" |
matched_rule_priority | 0 |
request_creation_time | 2023-04-01T05:06:35.754000Z |
"actions_executed" | "forward" |
"redirect_url" | "-" |
"error_reason" | "-" |
"target:port_list" | "172.31.22.203:443" |
"target_status_code_list" | "-" |
"classification" | "-" |
"classification_reason" | "-" |
How do I troubleshoot Application Load Balancer HTTP 502 errors?를 참고하며 로그 정보를 이용해 502 오류의 출처를 찾아 보자.
이번 나의 오류의 경우 elb_status_code
가 502
의 값이기 때문에 로드밸런서가 502 오류의 이유이다.
Tomcat의 로그를 확인을 해 보아도, 200 OK
의 상황에서는 내가 작성했던 로그를 확인할 수 있는 반면에 502 Bad Gateway
의 상황에서는 아무런 로그도 출력되지 않았다.
즉, 502 Bad Gateway
의 문제는 내 스프링 서비스가 잘못된 정보를 반환해 오류를 일으키는 것이 아니라 로드밸런서에서 요청 자체를 EC2 서버로 전달해 주지 않고 바로 502 Bad Gateway
를 응답해 주는 것이다.
ALB의 Access Log를 확인해 보면서 502 Bad Gateway
의 원인이 나의 서비스가 아닌, 로드밸런서의 문제라는 것을 확인했다.
다음 포스팅에서는 로드 밸런서의 문제 원인을 조금 더 명확하게 파악해 보고, 문제를 해결해 보자.