IIS 모니터링 도구로 메트릭 수집하기

2023. 2. 26. 19:27ㆍ이것저것

728x90

 

 

Collecting metrics with IIS monitoring tools

Collect IIS metrics and performance counters by using the monitoring tools covered in this article.

www.datadoghq.com

 

이 시리즈의 1부에서 IIS가 다음과 같은 두 가지 주요 방법으로 메트릭을 노출한다는 것을 기억할 수 있습니다.

 

-Performance counters(성능 카운터): 일반적으로 Windows용 성능 카운터와 함께 IIS 웹 서비스에 대한 성능 카운터는 IIS 사이트당 요청 비율 및 작업자 프로세스당 CPU 사용률과 같은 메트릭을 표시할 수 있습니다.

- Web service logs(웹 서비스 로그): 요청 대기 시간 및 각 URI 줄기의 빈도와 같은 일부 메트릭은 HTTP 요청 로그에서만 볼 수 있습니다.

 

이 게시물에서는 우리는 기본 제공 IIS 모니터링 도구를 사용하여 성능 카운터에 액세스하여 그래프 작성, IIS 로깅 환경 구성, Microsoft의 Log Parser Studio를 통한 로그를 질의하는 방법을 보여 줄 것입니다. 또한 우리는 진단 도구를 사용하여 응용 프로그램 풀 및 작업자 프로세스에서 메모리 누수 및 높은 CPU 사용률을 조사하는 방법에 대해서도 설명 할 것입니다.

 

Performance counters(성능 카운터)

Windows에서 성능 카운터는 운영 체제 자체뿐만 아니라 특정 서비스, 응용 프로그램 또는 드라이버에서 자동으로 데이터를 수집합니다. 1부에서 우리는 IIS의 상태와 성능을 모니터링하는 데 유용한 몇 가지 성능 카운터 클래스를 소개했습니다.

 
Performance Monitor 이름
전체 이름
Web Service
Win32_PerfFormattedData_W3SVC_WebService
HTTP Service Request Queues
Win32_PerfFormattedData_Counters_HTTPServiceRequestQueues
W3SVC_W3WP
Win32_PerfFormattedData_W3SVCW3WPCounterProvider_W3SVCW3WP
Process
Win32_PerfFormattedData_PerfProc_Process

 

성능 카운터는 지정된 IIS 호스트 내에 저장된 클래스의 메트릭을 보고해 주기때문에, 여러가지 기술을 이용해서 질의할 수 있습니다. 우리는 PowerShell 스크립트, 성능 모니터 및 IIS API를 통해 IIS 관련 성능 카운터를 수집하는 방법을 보여줄 것입니다. 특히 우리는 1부에서 소개한 성능 카운터를 살펴볼 것입니다.

 

웹 서비스 성능 카운터 클래스 활성화 하기

IIS 성능 카운터를 쿼리하기 전에 당신은 성능 카운터가 활성화되어 있는지 확인해야 할 것입니다.

웹 서비스 클래스를 제외하고 IIS를 모니터링하는 데 필요한 모든 성능 카운터는 Windows 시스템에 이미 설치되어 있어야 합니다.

다음 PowerShell 스크립트를 실행하여 서버 호스트에서 웹 서비스 클래스가 존재 하는 지 여부를 확인하십시오:

Get-WmiObject -List -Namespace root\cimv2 | select -Property name | where name -like "*Win32_PerfFormattedData_W3SVC*"
 

만약 웹 서비스 클래스가 이미 설치된 경우 출력 결과에 다음이 포함되어야 합니다:

Name
----
Win32_PerfFormattedData_W3SVC_WebService
 

설치되지 않았다면, 다음 명령을 실행하여 클래스를 설치합니다:

install-windowsfeature web-common-http
 

The performance counters will then collect data from different components of IIS, including your worker processes, HTTP.sys, and the IIS request queue. You can then query these performance counters in a number of ways, which we’ll explain below.

그런 다음 성능 카운터는 작업자 프로세스, HTTP.sys 및 IIS 요청 큐를 포함하여 IIS의 다양한 구성 요소들로 부터 데이터를 수집 할 것입니다. 그리고 당신은 여러 가지 방법으로 이러한 성능 카운터를 질의 할 수 있습니다. 이에 대해서는 아래에서 설명하겠습니다.

 

  • PowerShell
  • Windows Performance Monitor
  • The IIS Administration API

 

파워쉘을 통한 성능 카운터 접근하기.

다양한 도구 및 라이브러리(예: Python용 패키지)를 사용하여 프로그래밍으로 성능 카운터에 액세스할 수 있습니다. 이 섹션에서는 PowerShell 명령으로 WMI 성능 카운터에 액세스하는 방법을 보여줍니다. PowerShell은 임시(ad-hoc) 검사에 매우 적합하며 이를 스크립트에 포함하거나 출력 결과를 다른 명령어로 이어주는(pipe) 것이 간단합니다.

 

성능 카운터 집합 내의 카운터 값에 액세스하려면 당신은 해당 클래스에 WMI 쿼리를 하기만 하면 됩니다. PowerShell 명령 Get-WmiObject를 입력하고 -Class 옵션으로 선택한 클래스를 넣어 줍니다. 쿼리할 수 있는 클래스를 확인 해 보려면 Microsoft의 WMI 클래스 목록을 참조하십시오.

예를 들어 웹 서비스 클래스(Win32_PerfFormattedData_W3SVC_WebService) 내의 모든 성능 카운터를 보려면 다음 PowerShell 명령을 실행할 수 있습니다:

Get-WmiObject -Class Win32_PerfFormattedData_W3SVC_WebService
 

출력 결과는 다음과 유사해야 합니다(목록의 일부이며 훨씬 더 김).

__CLASS                                   : Win32_PerfFormattedData_W3SVC_WebService
__SUPERCLASS                              : Win32_PerfFormattedData
__RELPATH                                 : Win32_PerfFormattedData_W3SVC_WebService.Name="_Total"
__PROPERTY_COUNT                          : 95
__DERIVATION                              : {Win32_PerfFormattedData, Win32_Perf, CIM_StatisticalInformation}
__SERVER                                  : EC2AMAZ-O31F7MR
AnonymousUsersPersec                      : 0
BytesReceivedPersec                       : 562
BytesSentPersec                           : 2480
TotalAllowedAsyncIORequests               : 0
TotalAnonymousUsers                       : 138
TotalBlockedAsyncIORequests               : 0
Totalblockedbandwidthbytes                : 0
TotalBytesReceived                        : 44466
TotalBytesSent                            : 1874900
TotalBytesTransferred                     : 1919366
 

이중 밑줄로 시작하는 속성은 모든 WMI 클래스에 속하는 시스템 속성을 나타냅니다.

당신은 BytesReceivedPersec 및 TotalBytesReceived 같은 WMI 클래스 중 웹 서비스 클래스들의 특정 속성을 볼 수 있을 것입니다. 어떤 카운터들은 비율(예: BytesReceivedPersec)을, TotalBytesReceived와 같은 다른 카운터는 IIS 서버(개별 사이트가 아닌)가 시작된 마지막 시간부터 계산된 누적 합계를 보고 해 줍니다. WMI에는 당신이 Microsoft 설명서에서 찾을 수 있는 성능 카운터 유형의 분류가 포함되어 있습니다.

 

다음 PowerShell 명령을 실행하여 지정된 카운터의 유형을 확인할 수 있습니다:

$obj = Get-WmiObject <COUNTER_CLASS> -List
$obj.properties.Where{$_.Name -eq '<COUNTER_NAME>'}.Qualifiers.Where({$_.Name -eq "CookingType"})
 

출력 결과에서 CookingType의 값은 WMI가 카운터를 형식을 지정된 값으로 "요리"하는 데 사용하는 카운터 유형입니다. BytesSentPersec에는 CookingType이 PERF_COUNTER_BULK_COUNT이며 사용자 정의 샘플 간격 동안 평균을 취합니다. TotalBytesSent에는 카운터의 현재 값인 CookingType이 PERF_COUNTER_LARGE_RAWCOUNT입니다(서버 실행이 중지될 때까지 계속 증가함).

만약 당신이 특정 속성을 쿼리하거나 특정 형식으로 결과를 표시하려는 경우 쿼리를 Format-List 명령으로 이어 줄 수 있을 것입니다.

 

아래 예에서는 -Property 옵션을 사용하여 쿼리할 속성을 지정하고 보려는 순서대로 나열하는 방법을 보여줍니다:

Get-WmiObject -class Win32_PerfFormattedData_W3SVC_WebService | Format-List -Property Name, ServiceUptime, TotalGetRequests, TotalPutRequests, TotalBytesReceived, TotalBytesSent
 

Format-List 명령은 WMI 클래스의 각 속성 값을 별도의 줄에 출력합니다. 출력 결과는 다음과 유사해야 합니다(Name 값은 카운터 인스턴스의 값이며 _Total은 모든 인스턴스의 합계를 나타냄):

Name                          : _Total
ServiceUptime                 : 667801
TotalGetRequests              : 27
TotalPutRequests              : 5
TotalBytesReceived            : 19873
TotalBytesSent                : 206196
 

윈도우 성능 모니터를 사용하여 성능 카운터 접근하기

성능 모니터는 NT 3.51 이후의 모든 Windows 버전이 설치 되어 있습니다. 당신은 시계열 그래프, 히스토그램 및 보고서와 함께 실시간으로 업데이트되는 높은 수준의 성능 카운터 보기를 제공하는 IIS 모니터링 도구로 사용할 수 있습니다.

 

성능 모니터의 IIS 메트릭 그래프를 보려면, 시작 메뉴에서 응용 프로그램을 엽니다. 다음으로 당신이 플로팅할 성능 카운터를 선택합니다. 탐색 트리 내에 "모니터링 도구-Monitoring Tools" 폴더가 표시 될 것입니다. 이 폴더를 클릭한 다음 아래 스크린샷과 같이 도구 모음에서 "추가...-Add…" 버튼을 클릭합니다.

WMI 클래스 메뉴를 찾을 수 있으며, 하나를 클릭하면 여기에 포함된 성능 카운터가 나타 날 것입니다.

각 성능 카운터는 하나 또는 여러 개의 인스턴스를 가질 수 있습니다(추적 대상에 따라 다름).

IIS 작업자 프로세스를 추적하는 성능 카운터의 경우, 프로세스당 하나의 인스턴스가 를 확인 할 수 있을 것입니다. 웹 서비스 클래스의 경우 IIS 사이트당 하나의 인스턴스가 존재 합니다. 하나의 인스턴스 또는 모든 인스턴스에 대한 카운터를 그래프로 표시하도록 당신은 선택할 수 있습니다. 아래 예에서는 단일 인스턴스인 IIS 사이트에 해당하는 모든 카운터를 플로팅 하고 있습니다.

성능 카운터 클래스 메뉴 내에서 당신은 웹 서비스, 프로세스 및 메모리 클래스 같은 1부에서 다룬 대부분의 주요 메트릭을 찾을 수 있을 것입니다.

 

"속성-Properties" 아이콘을 클릭하거나 Ctrl+Q를 입력하여 기본 시계열 그래프를 사용자 지정할 수 있습니다. 옵션은 y축 길이, 그래프 내의 선 색상, 각 성능 카운터의 샘플 속도가 포함됩니다.

 

드롭다운 메뉴에서 그래프 유형 변경을 클릭하여 데이터를 히스토그램 또는 텍스트 보고서 형식으로 표시하도록 선택할 수도 있습니다.

이 보고서는 선택한 카운터의 특정 값을 보려는 경우, 특히 값의 크기가 매우 다르기 때문에 동일한 y축 내에서 시각화하기 어려운 경우에 특히 유용합니다.

 

IIS 관리자 API 를 통한 성능 카운터 접근하기

Windows 7부터는 IIS 관리자 REST API를 사용하여 IIS 환경 구성하고 모니터링하는 옵션도 있습니다. API는 IIS 7.5 이상과 호환되며 당신의 IIS 호스트에서 실행되는 마이크로서비스를 접근 합니다.

또한 HTTP 서비스로서 cURL 스크립트에서 Microsoft 자체 웹 기반 프런트엔드인 https://manage.iis.net 에 이르기까지 다양한 도구에서 IIS를 관리할 수 있습니다. API는 IIS 내에서 응용 프로그램 풀, 사이트 및 기타 개체를 구성하기 위한 끝점을 노출하며 우리의 목적을 위해 상태 및 성능 지표를 보고하는 다음 세 가지 끝점(endpoint)이 노출 됩니다:

 

  • /api/webserver/monitoring
  • /api/webserver/application-pools/monitoring
  • /api/webserver/websites/monitoring

 

API를 설정하려면 설치 프로그램을 다운로드하여 실행하고 https://localhost:55539/security/tokens 에 접근하거나, 프로그래밍 방식으로 토큰을 생성하여 액세스 토큰을 만들어야 합니다.

 

기본적으로 API 마이크로 서비스는 포트 55539에서 수신 대기하며 다른 포트와 마찬가지로 명령줄을 통해 변경할 수 있습니다(IIS 자체 내에서는 아님). 방화벽 설정을 편집하여 원격 트래픽 포트를 열 수도 있습니다.

 

몇 가지 다른 방식으로 IIS 관리 REST API에서 데이터를 쿼리할 수 있습니다. 한 가지 접근 방식은 시계열 그래프의 대시보드를 표시하는 브라우저 기반 그래픽 인터페이스를 사용하는 것입니다.

초당 요청 수, 사용 가능한 시스템 메모리, 초당 송수신 바이트, CPU 사용률을 포함하여 다양한 고급 IIS 메트릭을 볼 수 있습니다. https://manage.iis.net/connect 를 접근하여 당신의 액세스 토큰과 API 서버 URL를 입력하여 프론트엔트에 접근 할 수 있습니다. (기본적으로 https://localhost:55539).

성능 모니터와 마찬가지로 API의 브라우저 기반 인터페이스는 실시간으로 업데이트되는 그래프를 표시합니다. 성능 모니터와 달리 y축 배율이 크게 다른 경우에도 상관 메트릭을 더 쉽게 만들 수 있는동일한 대시보드에서 각 메트릭을 별도의 시계열 그래프로 그래프로 표시할 수 있습니다.

그러나 표시할 메트릭을 선택할 수는 없습니다.

 

대표사진 삭제

사진 설명을 입력하세요.

모니터링을 위해 예약된 API 엔드포인트 중 하나로 GET 요청을 직접 보내거나 브라우저 기반 API 탐색기를 사용하여 API에서 JSON으로 메트릭을 반환할 수도 있습니다.

 

명령줄에서 API를 쿼리하는 경우 PowerShell의 Invoke-WebRequest 명령을 활용할 수 있습니다. 이 다음 예에서는 PowerShell을 사용하여 IIS 인스턴스의 상위 수준 메트릭에 대한 /api/webserver/monitoring 엔드포인트를 쿼리 하고 있습니다.

Invoke-WebRequest -Headers @{"Access-Token"="Bearer <YOUR_ACCESS_TOKEN>"} -Method GET
https://localhost:55539/api/webserver/monitoring -UseDefaultCredentials | ConvertFrom-Json
 

이러한 요청에 대해 몇 가지 유의해야 할 사항이 있습니다.

첫째, API에 대한 모든 요청은 Bearer 문자열로 시작하는 Access-Token 헤더 내에 유효한 액세스 토큰을 포함해야 합니다(공백 주의). 이 예에서는 우리는 -Headers 옵션을 사용하여 헤더를 지정했습니다. 이 옵션의 인수는 PowerShell dictionary 입니다.

또한 API 끝점에 대한 URI(https://localhost:55539/api/webserver/monitoring)

와 GET이어야 하는 -Method를 지정했습니다. 요청과 함께 현재 사용자의 자격 증명을 보내는 UseDefaultCredentials 스위치를 포함했습니다. 이 스위치를 생략하면 API가 401(권한 없음) 응답을 반환 할 것입니다.

 

마지막으로 Invoke-WebRequest의 출력을 GET 요청의 응답을 JSON으로 변환하는 PowerShell 명령인 ConvertFrom-Json으로 파이핑하고 있습니다. ConvertFrom-Json을 사용하지 않으면 응답의 RawContent 키가 불완전한 값으로 표출 될 것입니다.

 

API 요청을 전송하면 전송된 네트워크 바이트, 요청 처리량, 리소스 사용량 등에 대한 상위 수준 통계등의 다음과 유사한 내용이 표시됩니다:

id       : FZto7FXp2gguv2OrOJuHhg
network  : @{bytes_sent_sec=0; bytes_recv_sec=0; connection_attempts_sec=0; total_bytes_sent=738972827; total_bytes_recv=17299959;
           total_connection_attempts=164314; current_connections=1}
requests : @{active=0; per_sec=0; total=164410}
memory   : @{handles=219; private_bytes=8314880; private_working_set=2736128; system_in_use=1009979392; installed=1073332224}
cpu      : @{threads=16; processes=2; percent_usage=0; system_percent_usage=100}
disk     : @{io_write_operations_sec=0; io_read_operations_sec=0; page_faults_sec=0}
cache    : @{file_cache_count=0; file_cache_memory_usage=0; file_cache_hits=0; file_cache_misses=6; total_files_cached=0; output_cache_count=0;
           output_cache_memory_usage=0; output_cache_hits=0; output_cache_misses=164410; uri_cache_count=1; uri_cache_hits=164331;
           uri_cache_misses=79; total_uris_cached=28}
 

The IIS Administration API also exposes endpoints that give you access to statistics from specific application pools and websites.

IIS 관리 API는 또한 특정 응용 프로그램 풀 및 웹 사이트의 통계에 대한 액세스를 제공하는 끝점을 노출합니다.

You can obtain statistics about your application pools by querying the following endpoint:

다음 엔드포인트를 쿼리하여 애플리케이션 풀에 대한 통계를 얻을 수 있습니다.

/api/webserver/application-pools/monitoring
 

IIS 사이트에 대한 메트릭을 가져오려면 엔드포인트 질의 URI 는 다음과 같습니다.

/api/webserver/websites/monitoring
 

수동 쿼리의 경우 HTML 양식을 통해 제출되는 정보로 API를 호출하는 브라우저 기반 GUI인 API 탐색기(API Explorer)를 사용하는 것이 더 쉬울 수 있습니다.

API 탐색기는 IIS 관리 마이크로 서비스의 루트(https://localhost:55539)

에 접근 하면 보일 것입니다. API 탐색기를 사용하는 한 가지 이점은 자격 증명을 포함하거나 헤더를 정의할 필요가 없다는 것입니다. 그냥 끝점의 URI를 입력하기만 하면 됩니다.

 

아래 예에서는 네트워크 연결, 요청, 메모리, CPU, 디스크 및 IIS 캐시와 관련된 메트릭을 포함하여 IIS 인스턴스에 대한 전체 데이터를 얻기 위해 엔드포인트 /monitoring 에 질의 했습니다.

UI에는 API 끝점에 대한 입력 상자와 HTTP 메서드 메뉴가 포함되어 있습니다.

 

요청을 제출하면 API 탐색기에 다음과 유사한 출력이 표시 될 것입니다:

{
    "id": "GnyZVZsOxXqYBtxvJzO6dQ",
    "network": {
        "bytes_sent_sec": "5837",
        "bytes_recv_sec": "7094",
        "connection_attempts_sec": "36",
        "total_bytes_sent": "68784171",
        "total_bytes_recv": "8137036",
        "total_connection_attempts": "40920",
        "current_connections": "260"
    },
    "requests": {
        "active": "382",
        "per_sec": "36",
        "total": "40922"
    },
    "memory": {
        "handles": "205",
        "private_bytes": "15372288",
        "private_working_set": "10625024",
        "system_in_use": "926236672",
        "installed": "1073332224"
    },
    "cpu": {
        "threads": "17",
        "processes": "2",
        "percent_usage": "0",
        "system_percent_usage": "100"
    },
    "disk": {
        "io_write_operations_sec": "9",
        "io_read_operations_sec": "9",
        "page_faults_sec": "173"
    },
    "cache": {
        "file_cache_count": "1",
        "file_cache_memory_usage": "1208",
        "file_cache_hits": "7427",
        "file_cache_misses": "28",
        "total_files_cached": "27",
        "output_cache_count": "0",
        "output_cache_memory_usage": "0",
        "output_cache_hits": "0",
        "output_cache_misses": "40814",
        "uri_cache_count": "4",
        "uri_cache_hits": "40372",
        "uri_cache_misses": "442",
        "total_uris_cached": "215"
    },
    "_links": {
        "self": {
            "href": "/api/webserver/monitoring/GnyZVZsOxXqYBtxvJzO6dQ"
        }
    }
}
 

웹 서비스 로그

로그는 서비스 요청에 소요된 시간, HTTP 4xx 및 5xx 응답의 비율과 개수를 포함하여 1부에서 다루었던 일부 주요 메트릭들의 유일한 소스입니다.

당신은 로그가 가져야 할 형식과 로그에 포함될 필드에 대해서 환경 구성할 수 있을 것입니다.

그런 다음 Log Parser Studio와 같은 도구 또는 전용 로그 관리 서비스를 사용하여 로그 파일을 쿼리하여 집계를 추출할 수 있습니다.

 

웹 서비스 로그 환경 설정

IIS 로깅은 활성화가 기본 입니다. IIS 관리자를 열고 정보를 기록하려는 IIS 인스턴스의 이름으로 이동하여(아래 비디오 참조) 활성화되어 있는지 확인하고 그렇지 않은 경우 로깅을 활성화할 수 있습니다.

다음 옵션 목록에서 로깅 아이콘을 두 번 클릭합니다.

오른쪽에 "작업-Actions"이라는 제목의 사이드바가 표시 될 것입니다. "활성화-Enable"를 클릭합니다. 그런 다음 로그 형식을 선택하고 1부에서 소개한 몇 가지 지표를 포함하여 기록할 필드를 지정할 수 있습니다.

당신은 W3C Extended, IIS, NCSA, ODBC 및 Centralized Binary와 같은 여러 표준 형식 중 하나로 로그를 출력하도록 IIS를 구성할 수 있습니다.

이 중 W3C 확장 형식(기본값)만 1부에서 설명한 내용을 포함하여 기록할 필드를 사용자 지정할 수 있습니다.

다음은 W3C 확장 형식을 따르는 IIS 로그 항목의 예입니다. #Fields 목록은 로그 파일의 네 번째 줄에 나타나며 그 아래에 IIS는 들어오는 모든 요청에 ​​대해 새 로그 항목을 만들 것입니다.

#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus time-taken
2018-03-14 17:00:37 172.31.3.237 GET / - 80 - 172.31.3.237 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/65.0.3325.146+Safari/537.36 - 200 0 78
 

이 특정 로그 항목에는 다음 필드가 포함되어 있습니다.

 
Field
Description
date
Date of the request
time
Time of the request
s-ip
Server IP address
cs-method
HTTP request method
cs-uri-stem
URI stem
cs-uri-query
Query string
s-port
Server port
cs-username
Client username
c-ip
Client IP
cs(User-Agent)
User agent
cs(Referer)
Referer
sc-status
Status of the request
sc-substatus
Substatus of the request
time-taken
Duration of the request, in milliseconds

 

Microsoft 문서에서 모든 W3C 확장 로깅 필드에 대한 키를 찾을 수 있을 것입니다.

 

웹 서비스 로그 질의하기

로그를 생성하도록 IIS에 대해서 환경 구성을 했다면 로그에서 메트릭을 수집할 방법이 필요 할 것입니다. Log Parser Studio는 SQL과 유사한 명령으로 IIS 로그를 쿼리할 수 있는 Microsoft 도구입니다.

Log Parser Studio를 사용하려면 안내에 따라 Log Parser를 설치해야 합니다. 이 작업을 마치면 Log Parser Studio를 설치가 끝나면, 실행 합니다.

 

Log Parser Studio 내에서 분석하려는 로그 파일의 위치를 ​​선택하고 "새 쿼리 만들기-Create a new query" 버튼을 클릭합니다. 화면 하단에 텍스트 필드가 표시됩니다. 텍스트 필드 위의 "로그 유형-Log Type"이 쿼리하려는 파일의 형식과 일치하는지 확인하십시오. W3C 확장 로그 형식(W3C Extended log format)을 사용하는 경우 "IISW3CLOG"를 선택합니다.

 

Log Parser Studio에서 SQL SELECT 문으로 쿼리를 보낼 수 있습니다. SQL 표준에는 몇 가지 중요한 변형이 있습니다. 첫째, FROM 절의 인수는 테이블 이름이 아니라 주어진 로그 파일의 절대 경로입니다. 로그 파일의 위치를 ​​찾으려면 IIS 관리자에 들어가 이전에 로깅을 활성화한 로깅 보기로 돌아가서 "작업-Actions" 사이드바 내에서 "로그 파일 보기-View Log Files"를 클릭합니다.

 

둘째, WHERE 절의 인수는 테이블의 열 이름이 아니라 쿼리하려는 로그 파일 내의 필드 이름이 됩니다. W3C 형식을 사용하는 로그 파일을 쿼리하는 경우 #Fields 아래의 네 번째 줄에서 파일 내의 필드 목록을 볼 수 있습니다. 아래 예는 하나의 로그파일에 대해서 완료하는 데 9초 이상 걸린 모든 요청에 ​​대해 로그 파일을 쿼리하고 있습니다.

SELECT * FROM 'C:\inetpub\logs\LogFiles\W3SVC1\u_extend1.log' WHERE time-taken > 9000
 

결과를 표 형식으로 볼 수 있습니다. 이 쿼리는 요청 당 한 줄을 반환합니다.

GROUP BY 절을 사용하여 데이터를 집계할 수도 있습니다. 아래 예는 URI 스템별로 집계된 평균 소요 시간을 쿼리하는 방법을 보여줍니다:

SELECT
  cs-uri-stem as URIStem,
  AVG(time-taken) as TimeTaken
FROM 'C:\inetpub\logs\LogFiles\W3SVC1\u_extend1.log'
GROUP BY URIStem
 

우리는 위 쿼리에서 하나의 URI 스템에 대한 HTTP 요청이 다른 것보다 훨씬 더 오래 걸리는 경향이 있다고 판단되면 해당 스템에 대한 로그를 분석하면 어떤 HTTP 메서드가 원인인지 확인할 수 있습니다. 데모 애플리케이션의 URI 스템인 /create에 대한 요청을 완료하는 데 평균 1,550밀리초가 걸린다는 것을 확인했다고 가정해 보겠습니다.

이 스템에 대한 GET 요청은 웹 양식을 검색하는 반면 POST 요청은 데이터베이스에 액세스해야 합니다.

이 정보를 기반으로 POST 요청이 더 오래 걸리는 것으로 의심되며 HTTP 요청 메서드별로 그룹화된 각 요청의 평균 소요 시간을 쿼리하여 이런 가설을 테스트할 수 있습니다:

SELECT
  cs-method as Method,
  AVG(time-taken) as TimeTaken
FROM 'C:\inetpub\logs\LogFiles\W3SVC1\u_extend1.log'
WHERE cs-uri-stem = '/create'
GROUP BY Method
 

출력은 다음과 유사한 테이블 일 것입니다.

 
Method
TimeTaken
GET
2,109
POST
295

 

실제로 /create에 대한 GET 요청은 평균 2,109밀리초가 소요된 반면 POST 요청은 평균 295밀리초만 소요되었습니다. 로그의 정보를 분석하면 요청 대기 시간을 개선하기 위해 사이트의 어떤 측면을 최적화할 수 있는지 결정하는 데 도움이 됩니다. 이 끝점에 대한 GET 요청의 속도를 높이려면 해당 페이지의 리소스 크기(예: 대용량 비디오 파일)를 줄여볼 수 있습니다.

 

DebugDiag

그냥 생략 합니다~

 

Automate your IIS monitoring

그냥 생략 합니다~

 

이상.

 

728x90

'이것저것' 카테고리의 다른 글

IoT를 위한 고 가용성 MQTT 클러스터 구축하기  (0) 2023.02.28
MQTT 에 대해서  (0) 2023.02.27
nodejs 설치 및 grunt 설정  (0) 2023.02.23
Gray scale 및 RGB 색상 공간  (0) 2023.02.18
모니터링 용 주요 IIS 메트릭  (0) 2023.02.16

관련글

댓글 0

티스토리툴바