모니터링 용 주요 IIS 메트릭

 

Key IIS metrics to monitor

Microsoft의 인터넷 정보 서비스(IIS)는 전통적으로 Windows(예: 버전 5.0, 6.0 이상)와 함께 제공되는 웹 서버입니다.IIS에는 수많은 확장 기능들이 존재합니다.

ISAPI 및 FastCGI와 같은 교체 가능한 인터페이스를 통해 Flask와 같은 마이크로 프레임워크에서 Windows 기반 프로덕션 환경에서 찾을 수 있는 기술(예: , ASP.NET) 과 함께 Node.js와 같은 런타임에 이르기까지 다양한 백엔드 기술과 함께 IIS 를 사용 가능하게 합니다. 또한 모듈이라고 하는 IIS 확장 생태계을 통해 URL 재작성 및 프로그래밍 방식의 로드 밸런싱 요청과 같은 작업을 수행하도록 서버를 구성할 수 있습니다.

IIS를 사용하면 기본 제공 콘텐츠 캐싱 및 압축 기능으로 성능을 최적화하고 응용 프로그램을 별도의 응용 프로그램 풀에 격리하여 응용 프로그램의 안정성을 향상시킬 수 있습니다.

 

이 게시물에서는 웹 서버의 가용성과 성능을 보장하는 데 도움이 되는 IIS 메트릭을 조사 해 볼 것입니다.Windows Server 2016 및 Windows 10과 함께 번들로 제공되는 IIS 10에 초점을 맞추고 있지만, 이전 버전을 사용 중이고 여기서 논의된 내용도 사용 가능 한지를 확인하려면 설명서를 참조 할 수 있을 것입니다.

그리고 IIS는 FTP를 포함하여 여러 TCP 기반 프로토콜을 구현할 수 있겠지만, 우리는 HTTP 또는 HTTPS용 서버로서 IIS의 기본 구성에 집중할 것입니다.

IIS 서버 구조

IIS의 구성 요소가 여러 Windows 프로세스 및 드라이버들로 분산되어 있다는 사실에 중점을 두고 모니터링 전략을 구성하는 것이 좋을 것입니다.

우리는 이러한 구성 요소들을 살펴본 다음 이를 모니터링하는 데 사용할 IIS 메트릭을 소개 할 것입니다.

 

HTTP.sys 와 작업자 프로세스(worker processes)

작업자 프로세스는 웹 서버의 주요 작업인 클라이언트 요청 처리와 응답 제공을 관리 합니다.

IIS는 구성에 따라 한 번에 여러 작업자 프로세스로 요청을 처리할 수 있으며 각 프로세스는 w3wp.exe 실행 파일로 실행됩니다.

 

요청이 Windows 서버에 도달하면 커널 모드 장치 드라이버인 HTTP.sys를 통해 전달 됩니다.

HTTP.sys는 HTTP 및 HTTPS 요청을 수신하고 작업자 프로세스에 전달하기 전에 각각의 유효성을 검사합니다. 요청을 처리할 수 있는 작업자 프로세스가 없으면 HTTP.sys는 해당 요청을 커널 모드 대기열에 넣습니다.

 

당신이 HTTP.sys에 대한 트래픽을 모니터링 한다면, svchost.exe 프로세스 인스턴스의 일부로 실행되는 World Wide Web 게시 서비스(WWW 서비스)에 의해서 수집 된 성능 카운터(performance counter)를 사용하게 될 것입니다.

WWW 서비스는 저장된 IIS 구성 설정을 HTTP.sys로 전달하고 각 IIS 사이트에 대한 성능 카운터를 수집하게 됩니다.

 

모든 작업자 프로세스는 응용 프로그램 풀에 속하며 응용 프로그램을 상호 격리하여 가용성을 향상시킵니다. 응용 프로그램의 충돌이 일어나더라도 다른 응용 프로그램 풀에는 영향을 미치지 않을 것입니다.

하나의 풀에 작업자 프로세스는 자신의 리소스를 다른 풀과 공유하지 않습니다. 예를 들어 작업자의 CPU 사용률을 조절하기 위해 구성 설정을 단일 풀에 전달할 수 있습니다.

각 응용 프로그램 풀은 기본적으로 단일 작업자 프로세스로 설정되어 있으며, 우리는 더 많은 작업자 프로세스를 포함하도록 풀을 구성할 수 있습니다.

 

URI 와 리소스

HTTP.sys는 요청의 URI를 사용하여 요청을 올바른 작업자 프로세스로 라우팅합니다.

사이트, 애플리케이션 및 가상 디렉터리를 구성하여 URI를 애플리케이션 풀 및 파일에 일치시킬 수 있습니다.

이들 각각은 URI의 부분을 지정합니다. 가상 디렉터리는 사이트 내에 중첩된 응용 프로그램 내에 포함되므로 <사이트>/<응용 프로그램>/<가상 디렉터리>(<site>/<application>/<virtual directory>)의 URI를 사용하여 리소스를 정의할 수 있습니다.

 

IIS에서 URI의 도메인 이름은 사이트에 속합니다. 사이트는 프로토콜(IIS 6 이하의 경우 HTTP 및 HTTPS, IIS 7 이상의 모든 프로토콜을 수용하도록 확장 가능) 또는 사이트의 IP 주소, 포트 및 호스트 헤더와 같은 특정 최상위 구성 세부 정보를 지정합니다.

그 외의 설정들은 사이트에서 요청을 처리하거나 라우팅하는 방법을 결정합니다.

IIS가 비활성 연결을 얼마나 유지해야 하는지와 사이트에서 허용할 수 있는 동시 연결 수에 대한 구성 설정을 적용할 수 있습니다.

 

애플리케이션은 URI 경로를 애플리케이션 풀 및 호스트 내의 물리적 디렉터리와 연결합니다.

모든 사이트에는 루트 URI에 바인딩되는 기본 애플리케이션이 적어도 하나 이상 있습니다. 응용 프로그램 생성하면, 이 응용프로그램을 응용 프로그램 풀(여러 응용 프로그램이 공유할 수 있음)에 가리킵니다.

응용 프로그램과 사이트는 각각 다른 응용 프로그램 풀을 가리킬 수 있습니다 - IIS는 URI를 기반으로 사이트 또는 응용 프로그램 풀에 대한 요청을 라우팅 할 것입니다.

애플리케이션의 물리적 디렉터리에는 가상 디렉터리라고 하는 추가 URI에 매핑되는 하위 디렉터리가 포함될 수 있습니다.

당신이 응용 프로그램을 실제 디렉터리에 할당하면 IIS는 각 하위 디렉터리를 가상 디렉터리로 지정하고 디렉토이에 대한 URI를 제공합니다.

 

단일 애플리케이션은 여러 가상 디렉토리를 가리킬 수 있으므로 하나의 하위 디렉토리를 images에 할당하고 다른 하위 디렉토리를 stylesheets에 할당하거나 아니면 당신의 애플리케이션 내에서 assets로 구성할 수 있습니다.

가상 디렉터리는 해당 파일 경로와 다른 이름을 가질 수도 있습니다.

 

주요 IIS 매트릭

IIS를 모니터링할 때 최소한 다음 네 가지 메트릭 범주에 집중해야 할 것입니다:

 

• HTTP 요청 메트릭
• HTTP 응답 메트릭
• 가용성 메트릭
• 리소스 메트릭

각 표의 "가용성(Availability)" 열은 각 메트릭에 액세스할 수 있는 위치를 나타냅니다.

2부에서는 우리는 성능 카운터(Windows 운영 체제 전체에서 내부적으로 메트릭을 계산하는 개체) 및 IIS 로그와 같은 소스에서 이러한 메트릭에 접근 하는 방법을 보여 줄 것입니다.

이 문서는 메트릭 수집 및 알림을 위한 프레임워크를 제공하는 Monitoring 101 시리즈의 메트릭 용어를 참조합니다.

HTTP 요청 매트릭

요청 볼륨을 추적하면 서버 사용량을 알 수 있으며 IIS 구성이 얼마나 잘 작동하는지 이해하기 위한 출발점 역할을 합니다.

HTTP 요청 메트릭은 또한 병목 현상을 식별하고, 가장 많은 트래픽을 수신하는 URI 경로를 확인하고, 애플리케이션 코드가 시스템 리소스에 어떤 종류의 요구를 하는지 결정하는 데 도움이 될 수 있습니다.

 

Name	Description	Metric Type	Availability
TotalMethodRequestsPerSec	Rate of requests received per second by the WWW Service, per site	Work: Throughput	Web Service counter set
Requests / Sec	Rate of requests received by a given worker process	Work: Throughput	W3SVC_W3WP performance counter set
CurrentQueueSize	Number of requests in the HTTP.sys queue, per application pool	Resource: Saturation	HTTP Service Request Queues counter set
cs-uri-stem	Rate of requests to a specific URI path	Work: Throughput	IIS logs
cs-method	Rate of requests sent through a specific HTTP method	Work: Throughput	IIS logs, Web Service counter set

 

경고 지표: TotalMethodRequestsPerSec

TotalMethodRequestsPerSec은 서버에서 초당 수신한 모든 HTTP 요청의 비율을 추적합니다.

이것은 HTTP 요청에 대한 처리량의 기본 척도이며 문제를 발견하기 위한 출발점입니다.

요청 비율의 급격한 감소는 서버 가용성 저하와 같은 인프라 문제를 일으킬 수 있습니다.

당신은 기본 요청 속도의 갑작스러운 변경 사항을 알리도록 경고를 설정하고 5xx 오류 및 서비스 가동 시간(나중에 논의 할 것임)과 함께 이 메트릭을 모니터링해야 할 것입니다.

 

IIS 활동을 면밀히 주시해 보면 합법적인 트래픽과 불법적인 트래픽을 구별하는 데 도움이 될 수 있습니다. 네트워크 보안은 그 자체로 하나의 분야이며 이 기사의 범위를 벗어나지만 일반적으로 HTTP 활동을 깊이 이해하는 것이 중요합니다.

 

초당 요청 수를 모니터링하는 것이 좋은 첫 번째 단계가 됩니다. 초당 요청이 급증하는 경우 원인이 예를 들어 서비스 거부(DoS) 공격인지 또는 인기 있는 소스의 참조 급증(소위 hug of death)인지 확인하기 위해 추가 판단을 할 수 있을 것입니다.

 

Microsoft는 클라이언트 연결이 keep-alive timeout에 도달했을 때 나타나는 Timer_ConnectionIdle 메시지의 급증이 일어나면 IIS 로그를 모니터링할 것을 권장합니다.

Timer_ConnectionIdle 로그 수가 급증하면 DoS 공격자가 서버에 대한 사용 가능한 연결을 최대화하려고 시도하고 있음을 나타낼 수 있습니다. 하지만 사용자가 연결에 문제가 있는 경우에도 발생될 수 있습니다.

 

경고 지표: CurrentQueueSize

앞에서 요청을 처리할 수 있는 작업자 프로세스가 없으면 HTTP.sys가 해당 요청을 대기열에 넣는다고 우리는 이야기 했었습니다. CurrentQueueSize는 응용 프로그램 풀당 HTTP.sys 요청 대기열의 깊이를 측정합니다.

풀의 CurrentQueueSize가 풀의 최대 요청 큐 길이(기본적으로 1,000, IIS 관리자 내에서 구성 가능)에 지속적으로 근접하는 경우 당신은 backlog의 소스를 파악하길 원할 것입니다.

 

당신은 CurrentQueueSize가 지속적으로 증가하는지 지켜보고 싶을 것입니다.

CPU는 응용 프로그램 풀 내에서 요청을 처리하기 때문에 대기열 찾음은 응용 프로그램 풀에 대한 CPU 제한을 잘못 구성했거나 풀이 단일 요청에 대해 CPU 집약적인 작업을 수행하고 있음을 의미할 수 있습니다.

아래 그래프는 응용 프로그램 풀의 CPU 사용률을 2%로 제한하기 전과 후의 단일 작업자 프로세스에 대한 % Processor Time(파란색)과 함께 CurrentQueueSize(빨간색)를 보여줍니다.

 

당신은 CurrentQueueSize에 대한 효과를 볼 수 있습니다. 그래프의 전반부에서 CPU 사용률은 주기적으로 급증하는 기준선이 매우 낮습니다. 조정 후에는 더 이상 CPU 주기 급증이 사라지고CurrentQueueSize가 증가합니다.

 

사용자가 당신의 웹 응용 프로그램을 사용할 수 있도록 하려면 지정된 응용 프로그램 풀의 CurrentQueueSize가 최대값에 도달할 때 알리도록 경고를 설정해야 할 것입니다.

응용 프로그램 풀이 최대 대기열 길이에 도달하면 들어오는 요청이 삭제되고 서버는 오류 코드 503(서버 사용량이 많음-Server Too Busy)을 반환 할 것입니다.

이 오류와 다른 HTTP 오류에 대해서는 이후 섹션에서 논의할 것입니다.

 

대기열 문제의 원인에 따라 당신이 취할 수 있는 몇 가지 단계가 있습니다.

응용 프로그램 풀이 지속적으로 매우 높은 비율의 CPU를 사용하는 경우 이 문제를 해결할 수 있을 때까지 해당 풀의 소비를 특정 limit으로 제한하면 나머지 시스템에 영향을 미치지 않습니다.

IIS 8.0부터 응용 프로그램 풀에 대한 ThrottleUnderLoad 속성을 설정할 수도 있습니다. 그러면 CPU 경합이 없는 경우에만 응용 프로그램 풀이 CPU 제한을 초과할 수 있도록 허용합니다.

IIS 호스트에 더 많은 CPU 코어를 할당할 수도 있습니다.

 

503 응답을 줄이는 한 가지 방법은 웹 가든으로 알려진 배치인, 응용 프로그램 풀에 다중의 작업자 프로세스를 부여하는 것입니다.

웹 가든은 작업자 프로세스가 항상 요청을 처리할 수 있도록 보장할 수 있습니다.

 

웹 가든이 모든 응용 프로그램에 항상 적합한 것은 아니며 경우에 따라 IIS 성능에 부정적인 영향을 미칠 수 있습니다.

첫째, 작업자 프로세스가 호스트 내의 파일에 독점적으로 액세스해야 하는 경우 파일을 놓고 경쟁하는 작업자 프로세스의 수를 늘리면 병목 현상만 발생 할 것입니다.

둘째, 모든 추가 작업자 프로세스는 또 자체 캐시 및 CPU 스레드도 유지하며 응용 프로그램 풀의 리소스 사용량을 증가시킬 것입니다.

당신의 사용 사례에 따라서 웹 가든에 대한 보다 안정적인 대안은 애플리케이션을 마이크로 서비스로 분할하고 각각에 애플리케이션 풀을 할당하는 것일 수 있습니다.

각 작업자 프로세스의 CPU 및 메모리 사용량을 모니터링하여 특정 사례에서 웹 가든이 성능에 영향을 미치는 정도를 관찰할 수 있습니다.

 

당신은 각 응용 프로그램 풀의 최대 요청 대기열 길이를 늘리거나 줄일 수도 있습니다.

최대 대기열 길이가 높을수록 IIS는 클라이언트로 503 오류를 반환하기 전에 더 많은 수의 동시 요청을 처리할 수 있습니다.

하지만 최대 대기열 길이를 너무 높게 설정하면 요청이 대기열에서 대기하는 동안 서버가 클라이언트에 응답하지 않는 것처럼 보일 수 있습니다.

그리고 요청이 사이트에 대해 지정한 connectionTimeout 제한보다 오랫동안 응용 프로그램 풀의 대기열에 남아 있으면 요청 시간 초과되고 HTTP.sys의 결과 로그로서 HTTPERR 로그 내 Timer_AppPool 오류가 기록 될 것입니다.

이러한 로그는 C:\Windows\System32\LogFiles\HTTPERR\httperr.log에서 찾을 수 있습니다. Microsoft는 최대 대기열 길이를 10,000 이하로 설정할 것을 권장합니다.

 

관찰 지표: Requests/Sec

TotalMethodRequestsPerSec은 HTTP.sys에서 수신한 모든 요청을 세지만, Requests/Sec은 HTTP.sys가 각 작업자 프로세스로 라우팅하는 모든 요청을 추적합니다.

IIS 요청 처리량을 보다 완벽하게 파악하려면 Requests/Sec(작업자 프로세스 당)과 TotalMethodRequestsPerSec을 모두 모니터링해야 합니다. 이러한 두 메트릭의 동작이 항상 일치하는 것은 아니기 때문입니다.

우리가 설명했듯이 IIS에 대한 요청은 먼저 HTTP.sys에 도달하고 적절한 작업자 프로세스로 이동하기 전에 대기열에 들어갈 수 있습니다.

각 작업자 프로세스의 Requests/Sec와 함께 TotalMethodRequestsPerSec를 모니터링하면 HTTP 트래픽의 서버 이동 경로를 명확하게 알 수 있습니다.

 

관찰 지표: cs-method, cs-uri-stem

당신은 IIS 인스턴스에 대한 요청의 URI 경로와 HTTP 메서드를 계속 주시해야 합니다. 이것이 웹 응용 프로그램의 어느 부분이 성능 저하의 원인인지를 결정하는 가장 직접적인 방법이기 때문일 것입니다.

기본적으로 IIS는 cs-method(GET 또는 POST와 같은 HTTP 요청 방법) 및 cs-uri-stem, 요청의 URI 대상(예: "/")을 기록합니다. 이러한 메트릭 이름의 cs는 "client-to-server"를 의미합니다.

 

로그를 구문 분석하여 각 요청의 cs-method 및 cs-uri-stem을 수집하고 이 데이터를 사용하여 처리량, 대기 시간 및 웹 애플리케이션 내 특정 경로에 대한 요청의 리소스 사용에 미치는 영향을 분석할 수 있습니다.

예를 들어 평균 소요 시간이 예상보다 길면 cs-method 및 cs-uri-stem을 사용하여 대기 시간 문제가 특정 페이지에서 발생하는지 확인할 수 있습니다.

 

HTTP 응답 매트릭

HTTP 응답 모니터링은 IIS 사이트가 어떻게 사용자에게 서비스를 제공하는 지를 확인하는 가장 직접적인 방법입니다.

당신은 사용자가 당신에게 알려주기 전에 응답 대기 시간의 증가에 대해 알고 싶을 것입니다.

그리고 4xx 또는 5xx 오류의 급증은 구성 설정에 문제가 있거나 깨진 응용 프로그램의 주요 변경으로 나타낼 수 있습니다.

당신은 IIS 로그를 구문 해독하고 분석하여 오류 응답을 반환한 요청 유형을 추적할 수 있습니다.

버전 7.0 이상에서 IIS는 더 자세한 설명을 제공하는 4xx 및 5xx 상태 코드의 하위 집합을 보고 해 줍니다.

아래에서 HTTP 상태 및 하위 상태 코드 목록을 찾을 수 있습니다.

 

2부에서 우리는 IIS 로깅 모듈을 사용하여 HTTP 요청 방법(GET, POST 등), cs-uri-stem(URL 경로) 및 time-taken (요청 처리 시간)을 포함 한 각 요청에 대한 주요 정보를 기록하는 방법을 보여 줄 것입니다.

Name	Description	Metric Type	Availability
4xx errors	Count or rate of 4xx client errors	Work: Error	IIS logs, W3SVC_W3WP performance counter set (for certain error codes)
5xx errors	Count or rate of 5xx server errors	Work: Error	IIS logs, W3SVC_W3WP performance counter set (for 500 error codes)
time-taken	Time elapsed between the first byte of a request and the final byte of a response	Work: Performance	IIS logs

 

경고 지표: 5xx server errors

IIS는 서버가 유효한 요청에 응답할 수 없을 때 5xx 상태 코드를 보냅니다.

503(서버 사용량이 많음 - Server Too Busy) 및 500(내부 서버 오류-Internal Server Error)는 일반적인 5xx 오류 코드에 포함됩니다.

IIS는 최대 요청 큐 길이에 도달하고 추가 요청을 처리할 수 없게 되면 503 오류 응답을 보내기 시작할 것입니다.

당신은 웹 가든을 설정하거나 최대 대기열 길이를 늘려서 하나의 원인으로 인한 503오류를 방지하는 방법에 대해 논의했습니다. 하지만 503의 다른 원인이 있을 수도 있습니다.

CPU 사용량의 증가 없이 높은 비율의 503 오류가 표시되기 시작하면(일반적으로 작업자 프로세스가 초과 적재되었다는 주요 지표임) HTTP.sys가 요청이 작업자 프로세스에 도작하기 전에 503 을 리턴 할 수도 있으므로 (예: 응용 프로그램 풀이 오프라인이 되는 경우) HTTPERR 로그를 참조할 수 있습니다.

ASP.NET 응용 프로그램을 실행 중인 경우 IIS에서 유입되는 동시 요청의 최대 대기열 크기인 appConcurrentRequestLimit와 관련된 503이 표시될 수도 있습니다.

응용 프로그램 풀이 최대 대기열 길이에 도달했을 때와 마찬가지로 ASP.NET 응용 프로그램은 appConcurrentRequestLimit(기본적으로 5,000)에 도달한 후 503 오류로 요청에 응답하기 시작합니다.

더 깊은 조사 없이는 500 오류의 원인을 파악하기 어려울 수 있지만 IIS 하위 상태 코드가 단서를 제공할 수는 있습니다.

예를 들어 500.13은 "웹 서버가 너무 바쁩니다-Web server is too busy,"를 나타냅니다. 이는 리소스 제약으로 인해 서버가 처리할 수 있는 동시 요청 수를 초과했음을 의미합니다(구성한 appConcurrentRequestLimit에 관계없이).

ASP 웹 프레임워크를 사용하는 경우 500.100 하위 상태 코드는 "내부 ASP 오류-Internal ASP error."를 나타냅니다. 이 경우 ASP 오류 로그에서 보다 구체적인 오류 메시지를 확인해야 합니다.

5xx 오류를 요청된 URI 경로(cs-uri-stem) 및 HTTP 요청 메서드(cs-method)의 비율 또는 개수와 연관시킬 수 있습니다.

특정 URI 경로에 대한 요청이 훨씬 더 빠른 속도로 500개의 상태 코드를 반환하는 경우 애플리케이션 코드의 최근 변경 사항과 관련이 있는지 조사할 수 있습니다.

 

마지막으로 W3SVC_W3WP 카운터인 % 500 HTTP Response Sent를 사용하여 500 오류를 반환한 응답의 비율을 추적할 수 있습니다.

이 집합의 다른 오류 관련 카운터와 마찬가지로 이 카운터는 하위 상태 코드를 알려주지 않습니다. 해당 정보는 로그에서만 수집할 수 있습니다.

일반적으로 로그를 사용하여 5xx 오류 비율을 모니터링하는 것이 좋습니다. 각 오류의 정확한 원인에 대한 더 많은 컨텍스트를 제공 받을 수 있기 때문입니다.

 

경고 지표: time-taken

IIS가 요청을 처리하는 데 걸리는 시간인 time-taken을 기록하도록 IIS를 구성할 수 있습니다.

이 메트릭은 HTTP.sys가 요청의 첫 번째 바이트를 수신할 때와 IIS가 네트워크 대기 시간을 포함하여 클라이언트에 대한 응답의 마지막 바이트 전송을 완료할 때의 두 타임스탬프 사이의 차이(밀리초)를 나타냅니다.

응답 대기 시간이 길면 사용자 경험에 영향을 줄 수 있으므로 바람직하지 않은 임계값을 지속적으로 초과하는 경우 알림을 받아야 합니다.

응답 대기 시간을 개선할 수 있는 두 가지 방법에는 HTTP 압축을 사용하여 IIS가 반환하는 파일의 크기를 줄이는 것과 출력 캐싱을 사용하여 일반적으로 생성되는 동적 콘텐츠 버전을 메모리에 저장하는 것이 있습니다.

이러한 솔루션의 효과는 당신의 사용 사례에 따라 다를 것입니다.

웹 서버가 정적 파일만 보내는 경우 출력 캐싱은 아무런 영향을 미치지 못할 것입니다.

콘텐츠가 자주 변경되는 경우 캐싱의 리소스 사용이 응답 대기 시간 감소를 상쇄할 수 있습니다.

파일 압축은 IIS 구성에서 지정한 압축 전략(예: "Deflate" 또는 "GZIP")과 일치하는 Accept-encoding 헤더를 포함하는 특정 HTTP 요청의 대기 시간만 개선합니다.

파일 압축을 구현하려는 경우 사용자 지정 필드로 로깅하여 Accept-encoding 헤더를 모니터링할 수 있습니다.

 

관찰 지표: 4xx client errors

 

사용자가 보내는 요청인 만큼 몇 몇 4xx 오류에 대한 조절 권한이 거의 없습니다.

그러나 특정 메시지의 변화는 조사할 가치가 있습니다. HTTP.sys가 HTTP 요청을 유효한 것으로 인식하지 않으면 IIS는 400 상태 코드(잘못된 요청)를 반환할 것입니다.

400개의 상태 코드 패턴은 HTTP.sys가 수락하려는 요청을 종료하고 있음을 나타낼 수 있습니다.

예를 들어 MaxFieldLength 속성은 요청의 각 헤더에 대한 제한(바이트)을 지정하며 특정 헤더를 거부할 수 있습니다. 당신은 HTTPERR 로그에서 400 오류의 원인을 찾을 수 있습니다.

MaxFieldLength의 예에서 당신은 HTTPERR 로그의 FieldLength로 s-reason 필드 값을 볼 수 있습니다.

레지스트리에서 MaxFieldLength 및 기타 속성을 편집할 수 있습니다.

때때로 404(찾을 수 없음) 상태 코드가 예상되지만 지속적인 증가는 asset이 정리되지 않았거나 누락되었음을 나타낼 수 있습니다.

일부 404 들은 특정 URI 경로(예: 파일 형식)에 대한 요청을 처리하는 IIS 확장인 처리기에 문제가 있음을 나타낼 수 있습니다. IIS는 처리기가 존재하지 않는 파일 경로에서 자체 종속성을 찾을 때(아마도 설치하지 않았기 때문에) 404 오류를 반환 할 것이기 때문입니다.

 

대부분의 HTTP 오류 기록은 로그를 통해서만 사용할 수 있지만 W3SVC_W3WP 성능 카운터 세트를 쿼리하여 특정 4xx 오류(401(권한 없음), 403(금지됨) 및 404)의 비율을 측정할 수 있다는 점은 주목할 가치가 있습니다.

 

가용성 매트릭

사용자가 콘텐츠에 액세스할 수 있도록 하려면 IIS의 여러 구성 요소의 가용성을 모니터링해야 할 것입니다.당신은 응용 프로그램 풀이 최근에 다시 시작되었거나 실행이 완전히 중지된 시점을 알고 싶을 것입니다. 또한 당신은 IIS가 더 이상 HTTP 요청을 수신하지 않는 경우 경고를 받고 싶을 것입니다.

 

이 섹션에서는 서버 가용성에 대한 통찰력을 제공할 수 있는 두 가지 IIS 메트릭에 대해 설명합니다.

 

Name	Description	Metric Type	Availability
ElapsedTime	Number of seconds a process has been running	Resource: Availability	Process performance counter set
ServiceUptime	Number of seconds the WWW Service has been running (per site or across all sites)	Resource: Availability	Web Service counter set

 

관찰 지표: ElapsedTime

ElapsedTime은 Windows 프로세스가 실행된 시간(초)을 기록하며 특히 IIS 작업자 프로세스를 모니터링하는 데 유용합니다.

응용 프로그램 풀이 다시 시작(또는 "재활용")되면 ElapsedTime이 0으로 재설정됩니다.

재활용 이벤트는 응용 프로그램 상태를 지우고 잠시 사용할 수 없게 될 수 있습니다.

재활용 이벤트가 인프라에 문제를 일으키는 경우 재활용을 위해 구성한 임계값이 응용 프로그램 풀의 실제 리소스 사용과 맞지 않을 수 있습니다.

 

당신은 다음 두 종류의 메모리 임계값에 도달하면 풀을 재활용하도록 구성할 수 있습니다; 다른 풀과 공유되지 않는 전용 메모리(private memory)와 각 응용 프로그램 풀의 예약된 메모리 주소인 가상 메모리(virtual memory)가 그것입니다.

정기적인 time-based interval을 기반으로 또는 특정 수의 요청을 처리한 후에 응용 프로그램 풀을 재활용할 수도 있습니다.

기본적으로 요청 수 및 메모리 사용량에 따른 재활용은 비활성화되어 있으며 응용 프로그램 풀은 29시간마다 다시 시작됩니다.

다른 응용 프로그램 풀이 종료되기 시작할 때마다 새 응용 프로그램 풀을 자동으로 기동하는 IIS 옵션설정을 구성할 수 있습니다.

당신이 만약 작업자 프로세스의 ElapsedTime이 최근에 재설정된 것을 발견한 경우 로그를 참조하여 응용 프로그램 풀이 재활용되었는지 여부와 그 이유가 무엇인지 확인할 수 있습니다.

IIS 관리자 내의 응용 프로그램 풀에 대한 "고급 설정-Advanced Settings" 창에는 재활용 이벤트의 이름을 나열해 보면, 로그 여부를 선택할 수 있는 "재활용 이벤트 로그 항목 생성-Generate Recycle Event Log Entry,"이라는 섹션이 있습니다. .

 

관찰 지표: ServiceUptime

ServiceUptime은 WWW 서비스(또는 특정 IIS 사이트)가 마지막으로 다시 시작된 이후 실행된 시간(초)을 추적합니다.

왜냐하면 WWW 서비스는 전체 IIS 인스턴스 위에서 작동하기 때문에 ServiceUptime은 IIS 소프트웨어 전체에서 펄스를 가져올 수 있는 유일한 메트릭입니다.

이것은 WWW 서비스 - 당신의 IIS 사이트 - 가 계속 실행 되게 할 (그리고 503 에러를 사용자에게 보내면서) 단일 작업자 프로세스를 사용할 수 없게 될 수 있으므로 중요합니다. 따라서 ElapsedTime과 ServiceUptime을 별도로 모니터링해야 합니다.

아래 예에서는 오후 3시 32분경에 애플리케이션 풀을 재활용했습니다.

각 작업자 프로세스의 ElapsedTime은 재설정되고 ServiceUptime은 계속 증가합니다.

오후 3시 42분경에 IIS 서버를 다시 시작했을 때 두 지표가 모두 재설정되었습니다.

 

리소스 매트릭

응용 프로그램 풀은 자체 작업자 프로세스로 서로 격리되어 있으므로 개별적으로 모니터링하는 것이 중요합니다. 응용 프로그램 풀은 리소스 경합 또는 충돌에 직면할 수 있지만 IIS는 전체적으로 동작하는 것처럼 보입니다.

 

Name	Description	Metric Type	Availability
PercentProcessorTime	Percentage of CPU utilization per process (within a user-configured sample interval)	Resource: Utilization	Process performance counter set
WorkingSet	Number of bytes within a process’s virtual address space stored in physical memory	Resource: Utilization	Process performance counter set

 

관찰 지표: PercentProcessorTime

모니터링하려는 리소스 메트릭 중 하나는 지정된 프로세스가 CPU를 사용한 시간의 백분율인 PercentProcessorTime입니다.

실행 중인 작업자 프로세스의 CPU 사용률을 모니터링하면 서버 리소스를 효과적으로 할당할 수 있습니다. 예를 들어 특정 제한에 도달하면 응용 프로그램 풀의 CPU 소비를 제한할 수 있습니다.

또한 당신은 높은 CPU 사용량의 원인을 조사하고 완화할 수 있는지 확인하고 싶을 것입니다.

단일 응용 프로그램 풀이 지속적으로 예상 CPU보다 더 많은 CPU를 사용하는 경우 응용 프로그램 코드를 최적화하는 방법을 찾아야 할 가능성이 높습니다.

문제를 일으키는 응용 프로그램 풀과 그 이상으로 문제가 있는 코드를 식별하고 싶을 것입니다.

IIS 관리자를 사용하여 특정 작업자 프로세스가 속한 응용 프로그램 풀을 식별할 수는 없지만 이러한 목적으로 다운로드할 수 있는 도구는 있습니다.

 

URI 경로 및 HTTP 메서드로 분류된 요청 빈도와 높은 CPU 사용량 기간을 연관시켜 다른 방식으로 문제에 접근할 수도 있습니다.

HTTP 메서드와 URI 경로의 특정 조합이 있는 요청의 급증이 CPU 사용률의 급증과 일치하는 경우 이러한 헤더를 처리하는 백엔드 코드를 조사해야 합니다.

메모리 덤프를 만들고 별도의 소프트웨어 프로그램을 사용하여 스택 추적을 수행할 수도 있을 것입니다.

 

관찰 지표: WorkingSet

Windows 프로세스는 데이터가 물리적 RAM에 저장되는 위치에 매핑되는 페이지를 저장하는 가상 주소 공간에 액세스할 수 있습니다.WorkingSet은 물리적 메모리에 저장된 프로세스의 가상 주소 공간 내 페이지인 작업자 프로세스의 작업 집합 내에서 현재 바이트 수를 추적합니다.

 

당신은 응용 프로그램 풀과 시스템 전체에서 메모리 소비를 모니터링하고 싶을 것입니다.

 

시스템 전체에서 너무 많은 메모리를 사용하면 메모리 부족 예외(out-of-memory)가 발생할 수 있습니다. 그리고 응용 프로그램 풀이 특정 메모리 임계값에 도달할 때 재활용하도록 구성했지만 풀에 대한 요청을 처리하는 코드가 계속해서 많은 메모리를 소비하는 경우 풀을 재활용한다고 해도 문제를 연기할 뿐입니다

응용 프로그램 풀의 메모리 누수를 감시하고 이를 IIS 모듈이나 응용 프로그램 코드로 추적할 수 있는지 여부를 확인하는 것이 중요합니다.

예를 들어 문자열 연결을 사용하여 HTML을 반환하는 등 응용 프로그램이 단순히 많은 메모리를 소비하는 경우도 있을 수 있습니다.

 

CPU 사용률과 마찬가지로 DebugDiag(2부 참조)와 같은 도구로 메모리 덤프를 분석하고 메모리 소비를 HTTP 요청의 경로 및 메서드와 연관시키고 w3wp.exe 인스턴스가 어떤 작업자 프로세스 내에 속하는지 식별하여 높은 메모리 소비의 원인을 찾을 수 있습니다.

 

아래에서 풀이 오후 1시 22분경에 재활용된 후 특정 응용 프로그램 풀에서 작업자 프로세스당 메모리 사용량이 증가한 것을 볼 수 있습니다.

 

다음 단계: IIS 매트릭 수집

이 게시물에서는 IIS의 상태 및 성능을 추적하기 위한 몇 가지 주요 IIS 메트릭을 다루었습니다.

특히 HTTP 요청에서 집계된 지표와 함께 IIS 응용 프로그램 풀의 트래픽 및 리소스 사용량을 모니터링하는 것의 중요성을 설명했습니다. 이 시리즈의 2부에서는 Windows 성능 카운터, IIS 로그 및 IIS HTTP API에서 이러한 메트릭을 수집하는 방법을 보여 줄 것입니다.

 

이 게시물의 소스 Markdown은 GitHub에서 사용할 수 있습니다. 질문, 수정, 추가 등? 저희에게 알려주십시오.

 

이상.