Windows Server 2008이 나오면... (50) - 실패한 요청 추적 in IIS 7.0

http://blogs.technet.com/koalra/archive/2007/11/07/windows-server-2008-50-in-iis-7-0.aspx

 

웹 사이트가 굉장히 느릴 경우, 또는 웹 사이트내 특정 디렉터리에서 원하는 데로 작동하지 않는 경우, 디버깅이 필요한 경우...

IIS 6.0에서는 어떻게 하셨나요? 제 경우에는 이를 Log로 남겨서, Log Parser를 통해 원하는 정보를 찾아서 이를 확인하고 수정하려고 시도했었습니다. 이 로그내에는 문제의 상황도 상황이지만, 정상적으로 200대 코드를 리턴했던 정보도 기록되므로, 이를 걸러내고 찾아내기 위해 많은 시간과 노력이 필요했죠.

IIS 7.0은 다릅니다. 바로 실패한 요청 추적(Failed Request Tracing)이라는 기능이 추가되었고, 이는 사이트에 원하는 상황에 대한 규칙을 생성하여, 원하는 상황에 대해서 바로 찾아낼 수 있도록 해줍니다.

추가 프로그램 하나를 웹 사이트에 추가했을 경우, 대표적으로 모듈을 추가하는 경우가 이에 해당되겠죠. 웹 사이트가 느려졌을 때 어떤 고민을 하시게 되나요? 이게 정말 모듈 문제인가, 웹 사이트의 문제인가, 웹 서버의 문제인가, 운영 체제의 문제인가... 다양한 원인을 생각해보게 되고, 외부에서 구입한 솔루션인 경우, 하드웨어 업체, 소프트웨어 업체 등 연계된 모든 업체들을 다 연락해야하는 어려움이 있습니다.

위의 그림은 실패한 요청 추적을 통해 오랜 시간이 걸린 부분에 대한 확인을 해본 로그입니다. Filter 부분 작업이 다른 작업 보다 오래 걸렸음을 알 수 있고(딴 건 0ms인데... Filter 부분만 5007ms죠?),

이에 대한 추적 정보를 클릭해보면, 위의 그림과 같이 노란색으로 dll 파일 하나에서 문제가 발생했음을 알 수 있습니다.

위와 같이 나오는 경우도 웹사이트에 많죠? X박스라고 불리는.. 원인은 다양할 수 있습니다. 파일이 없거나, 오타이거나, 권한 문제일수도 있고...

추적 결과는...

권한 문제입니다. 결과론적인 것만을 보여드렸습니다. IIS 7의 실패한 요청 추적 기능은 기존의 로깅 부분을 대폭적으로 향상시켰고, 기존의 Log 포맷을 사용하지 않고, XLST 포맷을 사용하기 때문에, 다양한 용도로의 활용도 꾀해보실 수 있습니다.

자.. 이제 설정 부분을 얼릉 살펴보고, 해당 포스팅을 마치겠습니다. 추적하려고 하는 사이트의 Failed Request Tracing Rules 아이콘을 클릭합니다.

 

일단 기능 자체를 Enable 시켜야 합니다. 그러고 조건들을 입력해야죠. 조건은 파일 이름 기반으로 조건문을 시작합니다. 물론 *와 ?와 같은 연산자도 사용하실 수 있습니다.

 

이러한 파일에 대한 어떤 이벤트인가를 결정합니다. 상태 코드.. 대표적인 것이 에러 코드, 또는 소요 시간, 또는 이벤트 발생 심각도를 선택하실 수 있습니다. 여러개를 다 설정하시던가, 한개만을 설정할 수 있습니다. 마지막으론 해당 웹 사이트에 대한 프로바이더를 선택합니다.

조금 포스팅이 길어졌네요. 매우 매력적인 기능이기에 많은 스크린샷이 있어서 조금 길어진 것 같습니다. 실패한 요청 추적 기능! 너무 좋은 것 같습니다. ^^