📝 서론
이전 포스팅에서 로그 확인을 위한 S3 버킷을 생성해 봤다.
이번에는 로그를 직접 확인해 보자.
🔍 로그 확인
S3 버킷에 생성된 로그를 확인해 보자.
로그는 저장할 로그가 있을 때 마다 5분 단위로, 새로 생성이 된다.
나의 요청에 대한 로그
- 200 OK에 대한 로그
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" "-" "-"- 504 BadGateway에 대한 로그
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의 원인이 나의 서비스가 아닌, 로드밸런서의 문제라는 것을 확인했다.
다음 포스팅에서는 로드 밸런서의 문제 원인을 조금 더 명확하게 파악해 보고, 문제를 해결해 보자.
