로그 / 관측 가능성 도구
CloudFront 표준 로그나 ALB 액세스 로그를 붙여넣으면 형식이 자동으로 판별됩니다（직접 선택도 가능）. 「로그 분석」을 클릭하면 필터링 가능한 표가 나타납니다.
모든 처리는 브라우저에서 로컬로 이루어지며, 로그 내용은 업로드되지 않고 AWS 계정도 필요 없습니다.
로그를 분석하면 여기에 표가 표시됩니다.
CloudFront와 ALB는 AWS에서 가장 흔히 쓰이는 두 가지 액세스 로그지만, 둘 다 눈으로 바로 읽기에는 적합하지 않습니다. CloudFront의 필드는 로깅을 켤 때 선택한 열 구성과 버전에 따라 달라지고, ALB는 한 줄에 30개가 넘는 공백 구분 값을 담고 있으며 그중 일부는 따옴표로 묶여 있습니다. 이 AWS 로그 분석 도구는 지원 티켓이나 S3, CloudWatch 내보내기에서 복사해 온 로그 조각을 손에 들고, 어느 엣지 로케이션이 요청을 처리했는지, 어느 타겟이 502를 반환했는지, 어느 클라이언트 IP가 특정 경로를 집중적으로 두드리는지 Athena 쿼리 없이 바로 확인하고 싶을 때를 위한 도구입니다.
수백에서 수천 줄 정도의 일회성 점검에 어울리며, 상시 운영되는 분석 파이프라인을 대체하는 것은 아닙니다. 모든 처리는 브라우저 탭 안에서 이루어지고, 로그 내용은 어디에도 업로드되지 않으며 AWS 계정이나 S3 접근 권한도 필요하지 않습니다.
두 AWS 형식이 각자 필드를 선언하는 실제 방식에 맞춰 설계했습니다.
CloudFront 표준 로그는 맨 앞에 #Version과 #Fields 두 줄이 있고, 각 열의 이름이 순서대로 적혀 있습니다. 이 도구는 고정된 레이아웃을 가정하지 않고 이 두 줄을 그대로 읽기 때문에, AWS가 나중에 필드를 추가해도 표가 자동으로 늘어날 뿐 이 도구를 업데이트하거나 버전을 선택할 필요가 없습니다.
CloudFront에서는 캐시 결과(Hit, Miss, RefreshHit, Error) 분포와 상위 edge location을 보여줍니다. CDN이 이상하게 동작할 때 실제로 확인하게 되는 두 가지입니다. ALB에서는 실행된 액션 분포와 함께, 로드밸런서 상태 코드와 타겟 상태 코드가 일치하지 않는 요청 수를 보여주는데, 보통 백엔드 이상의 첫 신호가 됩니다.
분석, 필터링, 내보내기를 3단계로 진행합니다.
CloudFront 표준 로그나 ALB 액세스 로그를 붙여넣습니다. 자동 감지는 첫 번째 비어 있지 않은 줄만 확인합니다. #Version:으로 시작하면 CloudFront, 첫 단어가 http/https/h2/grpcs/ws/wss 중 하나면 ALB로 판별합니다. 둘 다 해당하지 않으면(예: 헤더 없이 데이터 행만 붙여넣은 경우) 추측하지 않고 드롭다운에서 직접 선택하세요.
입력하는 동안 자동으로 분석이 실행되지 않습니다. 이런 로그는 흔히 수천 줄에 달하고 한 줄에 30개가 넘는 필드가 있을 수 있어, 입력할 때마다 다시 매칭하는 것은 낭비입니다. 「로그 분석」을 한 번 클릭하거나 단축키를 사용하면 표가 채워집니다.
상태 코드, 경로, 클라이언트 IP, 그리고(CloudFront의 경우) edge location 이렇게 4가지 필터는 이미 분석된 행에 즉시 적용되며 「로그 분석」을 다시 클릭할 필요가 없습니다. 표 아래의 요약 패널도 필터에 맞춰 갱신되며, 캐시 결과나 실행된 액션 분포, 현재 표시된 결과의 총 바이트 수와 평균/최대 지연 시간을 보여줍니다. 표시된 행은 CSV, JSON, 일반 텍스트로 내보낼 수 있습니다.
실제 AWS 액세스 로그를 조사하기 위한 필드 매핑, 4가지 필터, 형식별 통계.
열 이름은 로그 자체의 #Fields 줄에서 그대로 가져오므로, 표는 로깅을 켤 때 직접 선택한 필드 구성을 포함해 붙여넣은 로그의 실제 버전과 항상 일치합니다.
ALB에는 헤더 줄이 없지만, AWS 공식 문서는 새 필드가 항상 끝에만 추가된다고 명시하고 있습니다. 이 도구는 알려진 전체 필드 목록에 대해 각 행의 토큰을 위치 기준으로 매핑하고 실제로 일치한 필드 수를 보고하므로, 뒤쪽 필드가 적은 오래된 로그도 오류 없이 깔끔하게 분석됩니다.
상태 코드 범위나 정확한 코드, 경로 부분 일치나 정규식, 클라이언트 IP 부분 일치, 그리고(CloudFront에 한해) edge location 부분 일치로 표를 좁힐 수 있으며 로그를 다시 분석할 필요가 없습니다.
CloudFront 행은 x-edge-result-type(Hit, Miss, RefreshHit, Error 등)으로 요약되고, ALB 행은 쉼표로 구분된 actions_executed 값으로 요약되며, 여기에 ELB와 타겟 상태 코드가 일치하지 않는 요청 건수도 함께 표시됩니다.
감지된 형식과 열 수가 맞지 않는 행은 1부터 시작하는 줄 번호와 원본 텍스트가 함께 목록에 표시되어, 몇 줄의 이상 데이터가 건수에서 조용히 사라지지 않습니다.
현재 필터로 표시된 행만, 표와 같은 열 구성으로 내보냅니다. 스프레드시트나 다른 도구에 바로 가져다 쓸 수 있습니다.
필드 판별, 잘못된 행 처리, 범위 경계에 대한 구체적인 동작으로 당분간 바뀌지 않습니다.
CloudFront나 ALB 액세스 로그를 온라인에서 분석하기 전에 많이 묻는 질문들입니다.
ALB에는 헤더 줄이 없기 때문에, 이 도구는 AWS 공식 문서에 나온 필드 순서(type, time, elb, client:port부터 시작해 classification, ip_address 같은 더 최신 필드까지)에 따라 각 행의 공백 구분 토큰을 위치 기준으로 대응시킵니다. ALB를 선택하거나 자동 감지에 맡기고 붙여넣으면 이 대응이 자동으로 적용됩니다.
로깅을 켤 때의 설정과 버전에 따라 달라지기 때문에, 이 도구는 로그 자체의 #Fields 줄에서 필드 이름을 읽어 오고 고정된 목록을 가정하지 않습니다. 로그를 붙여넣으면 표의 열 제목이 그 로그의 실제 버전에 해당하는 진짜 필드 이름이 되며, date와 c-ip부터 fle-status, sc-range-start처럼 흔치 않은 필드까지 표시됩니다.
이 도구가 다루는 것은 ALB의 표준 액세스 로그 하나뿐입니다. 이름이 다르게 불리더라도 실제로는 AWS 문서에 정의된 동일한 access log entry syntax를 가리키는 경우가 대부분이며, 이 도구는 그 필드 순서를 그대로 따라 매핑합니다.
이 도구는 두 로그를 자동으로 연결하지 않고 각각 따로 분석합니다. 대신 수동으로 대조할 때 필요한 필드를 제공합니다 — CloudFront 쪽의 x-edge-request-id와 x-forwarded-for, ALB 쪽의 trace_id입니다. AWS 문서에서도 이 값을 두 홉에 걸쳐 연관시키는 데 쓰도록 안내합니다.
가능합니다. 붙여넣은 텍스트는 어디로도 전송되지 않습니다. 분석, 필터링, 내보내기 모두 브라우저 탭 안의 자바스크립트로 처리되며 서버로의 업로드나 저장, 기록이 전혀 없고 AWS 계정이나 S3 접근 권한도 요구하지 않습니다.
AWS는 2016년 이후 ALB 로그 끝부분에 여러 차례 필드를 추가해 왔습니다 — desync 완화를 위한 classification과 classification_reason, conn_trace_id, 그리고 비교적 최근의 transformed_host와 ip_address까지입니다. 이 도구는 알려진 34개 필드 중 해당 행이 실제로 가진 만큼을 매핑하고 그 개수를 보여주므로, 오래된 로그든 최신 로그든 어떤 릴리스에서 무엇이 추가됐는지 몰라도 그대로 사용할 수 있습니다.
아니요. 이 도구는 전통적인, 탭으로 구분된 텍스트 로그 형식(legacy 형식과 Standard Logging v2의 해당 w3c 출력 옵션)만 읽습니다. Parquet은 바이너리 열 지향 파일이라 텍스트로 붙여넣어도 의미 있게 처리할 수 없어서, 브라우저 기반 텍스트 분석 도구의 범위를 벗어납니다.
실제 로그에서 이 도구가 잘못 분석한 행을 발견하셨나요?
CloudFront 표준 로그나 ALB 액세스 로그를 붙여넣으면 몇 초 만에 필터링과 내보내기가 가능한 표를 얻을 수 있습니다 — S3 연결도, AWS 자격 증명도, 업로드도 필요 없습니다.
캐시 적중률을 확인하거나, 특정 경로를 집중적으로 두드리는 클라이언트를 찾거나, 타겟 그룹이 왜 잘못된 상태 코드를 반환하는지 알아볼 때를 위해 이 AWS 로그 분석 도구를 즐겨찾기에 추가해 두세요.
모든 분석은 브라우저에서 로컬로 이루어집니다.