실패한 요청 추적 규칙을 사용하여 애플리케이션 요청 라우팅 문제 해결

아티클
07/03/2023

적용 대상: 인터넷 정보 서비스 7.0 이상 버전

실패한 요청 추적은 IIS 7.0 이상 버전에서 요청 처리 실패 문제를 해결하기 위한 강력한 도구입니다. 이 문서에서는 실패한 요청 추적 규칙을 사용하여 애플리케이션 요청 라우팅에서 실패 및 추적 단계를 디버그할 수 있도록 하는 단계를 제공합니다. 실패한 요청 추적 규칙에 대한 자세한 내용은 IIS 8.5에서 추적을 사용하여 실패한 요청 문제 해결을 참조하세요.

목표

실패한 요청 추적 규칙을 구성하고 애플리케이션 요청 라우팅 문제를 해결할 때 찾을 항목을 이해하려면

필수 구성 요소

이 연습에는 다음과 같은 필수 구성 요소가 필요합니다.

IIS용 추적 역할 서비스가 설치된 Windows 2008(모든 SKU) 이상에서 IIS 7.0 이상.
Microsoft 애플리케이션 요청 라우팅 및 종속 모듈.
작업 사이트 및 애플리케이션이 있는 최소 두 개의 애플리케이션 서버.

애플리케이션 요청 라우팅이 설치되지 않은 경우 다운로드 센터에서 다운로드하고 애플리케이션 요청 라우팅 설치에 설명된 단계에 따라 설치합니다.

또 다른 필수 구성 요소는 애플리케이션 요청 라우팅 모듈을 사용하여 애플리케이션 요청 라우팅을 구성했다는 것입니다. 애플리케이션 요청 라우팅은 다음 섹션을 진행하기 전에 작동 순서대로 진행되어야 합니다.

1단계: 실패한 요청 추적 규칙 구성

UI를 사용하거나 명령줄을 사용하여 애플리케이션 요청 라우팅에 대한 실패한 요청 추적 규칙을 구성합니다.

UI를 사용하여 실패한 요청 추적 규칙을 구성하는 방법

IIS(인터넷 정보 서비스) 관리자(inetmgr)를 시작합니다.
기본 웹 사이트를 선택합니다.
작업 창의 구성에서 실패한 요청 추적...을 선택합니다.
웹 사이트 실패한 요청 추적 설정 편집 대화 상자에서 사용 확인란을 선택합니다.
확인을 선택하여 변경 내용을 저장합니다.
기본 웹 사이트를 선택합니다.
실패한 요청 추적 규칙을 두 번 클릭합니다.
작업 창에서 추가...를 선택합니다.

모든 콘텐츠(*)를 선택한 다음, 다음을 선택합니다.
상태 코드를 선택하고 200-399를 입력합니다.

다음을 선택합니다. 위의 구성은 상태 코드가 200에서 399 사이일 때 추적을 작성하는 실패한 요청 추적 규칙을 만들었습니다.
ASP, ASPNET 및 ISAPI 확장을 선택 취소합니다. WWW 서버를 선택한 후 영역:에서 다시 쓰기 및 RequestRouting을 제외한 모든 항목을 선택 취소합니다. 애플리케이션 요청 라우팅은 들어오는 요청을 검사하기 위해 URL 다시 쓰기 모듈을 사용하므로 애플리케이션 요청 라우팅(RequestRouting) 및 URL 다시 쓰기 모듈(다시 쓰기)에 대해 추적을 사용하도록 설정하는 것이 좋습니다.

URL 다시 쓰기 모듈 추적에 대한 자세한 내용은 실패한 요청 추적을 사용하여 추적 다시 쓰기 규칙을 참조하세요 .
완료를 선택합니다.

명령줄을 사용하여 실패한 요청 추적 규칙을 구성하는 방법

관리자 권한으로 명령 프롬프트를 엽니다.
%windir%\system32\inetsrv(으)로 이동합니다.
기본 웹 사이트에서 실패한 요청 추적을 사용하도록 설정하려면 다음 명령을 실행합니다.
```
appcmd set site "Default Web Site" -traceFailedRequestsLogging.enabled:"true" /commit:apphost
```

위의 UI에 표시된 대로 실패한 요청 추적 규칙을 구성하려면 다음 명령을 실행합니다.

appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /+"[path='*']"

appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /+"[path='*'].traceAreas.[provider='WWW Server',areas='Rewrite,RequestRouting',verbosity='Verbose']"

appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /[path='*'].failureDefinitions.statusCodes:"200-399"

2단계: 실패한 요청 추적 로그 분석

이 단계에서는 애플리케이션 요청 라우팅에 요청을 보내고 실패한 요청 추적 로그를 분석합니다.

실패한 요청 추적 로그를 보려면

실패한 요청 추적 로그가 기록되는 디렉터리로 이동합니다. 기본적으로 위치는 입니다 %SystemDrive%\inetpub\Logs\FailedReqLogFiles\.
디렉터리를 기본 웹 사이트와 일치하는 폴더로 변경합니다. 기본적으로 W3SVC1입니다. 확실하지 않은 경우 IIS 관리자에서 기본 웹 사이트를 선택한 다음 작업 창에서고급 설정...을 선택합니다. ID 값은 해당 폴더를 나타냅니다. 예를 들어 ID 1 은 W3SVC1에 해당합니다.
XML 파일이 있는 경우 다음을 입력하여 제거합니다.
```
del *.xml
```
애플리케이션 요청 라우팅에 요청을 보냅니다. 애플리케이션 요청 라우팅이 올바르게 작동하는 경우 200 응답이 발생합니다. 이 응답은 1단계에서 지정된 200~399 범위 내에 속합니다. 따라서 로그는 위의 위치에 기록됩니다.
디렉터리의 파일을 나열하여 새 XML 파일이 기록되는지 확인합니다.
XML 파일을 엽니다. 요청 세부 정보를 선택합니다. 요청 추적 완료를 선택한 다음 모두 확장을 선택합니다. 다음 이미지는 애플리케이션 요청 라우팅에 대한 실패한 요청 추적 로그의 예입니다.
다음 섹션에 자세히 주의하세요.
- GENERAL_REQUEST_HEADERS:
  - 헤더: 애플리케이션 요청 라우팅이 수신한 HTTP 헤더를 표시합니다.
- ARR_REQUEST_ROUTED:
  - WebFarm: 요청이 라우팅되는 서버 그룹의 이름을 나타냅니다.
  - 서버: 요청이 라우팅되는 대상 서버를 나타냅니다.
  - 알고리즘: 사용되는 부하 분산 알고리즘을 나타냅니다.
  - RoutingReason: 서버가 선택된 이유에 대한 결정을 나타냅니다.
- ARR_SERVER_STATS:
  - 상태: 대상 서버의 가용성입니다.
  - TotalRequests: 이 서버로 전송된 요청 수에 대한 런타임 통계입니다.
  - CurrentRequests: 이 서버에 대한 HTTP 요청의 동시 수에 대한 런타임 통계입니다.
  - BytesSent: 이 서버로 전송된 KB의 데이터 양에 대한 런타임 통계입니다.
  - BytesReceived: 이 서버에서 수신된 KB의 데이터 양에 대한 런타임 통계입니다.
  - ResponseTime: 이 서버의 ms 응답성에 대한 런타임 통계입니다.
- GENERAL_RESPONSE_HEADERS
  - 헤더: 대상 서버의 응답 HTTP 헤더를 표시합니다.
- GENERAL_RESPONSE_ENTITY_BUFFER
  - 버퍼: 대상 서버의 응답 엔터티를 표시합니다.
- 애플리케이션 요청 라우팅의 성능을 프로파일링하기 위해 해당 이벤트의 시작 및 종료 시간을 나타내기 위해 타임스탬프와 함께 다음이 추가되었습니다.
  - ARR_REQUEST_HEADERS_START
  - ARR_REQUEST_HEADERS_END
  - ARR_RESPONSE_HEADERS_START
  - ARR_RESPONSE_HEADERS_END
  - ARR_RESPONSE_ENTITY_START
  - ARR_RESPONSE_ENTITY_END
  - ARR_RESPONSE_ENTITY_START
  - ARR_RESPONSE_ENTITY_END

서버 코어에서 실패한 요청 추적 로그를 수집하는 경우 freb.xsl 스타일시트가 있는 로그를 브라우저를 사용할 수 있는 컴퓨터에 복사합니다.

요약

이제 애플리케이션 요청 라우팅에 대한 실패한 요청 추적 규칙을 성공적으로 구성했습니다. 실패한 요청 추적 규칙을 사용하여 애플리케이션 요청 라우팅 문제를 해결하고 디버그할 뿐만 아니라 지정된 요청에 대한 대상 서버를 선택할 때 수행한 부하 분산 알고리즘을 비롯한 라우팅 결정을 이해할 수 있습니다.