Application Gateway에 대한 진단 로그
Application Gateway 로그는 리소스 및 해당 작업과 관련된 이벤트에 대한 자세한 정보를 제공합니다. 이러한 로그는 액세스, 활동, 방화벽 및 성능과 같은 이벤트에 사용할 수 있습니다(V1에만 해당). 로그의 세부적인 정보는 이 원시 데이터를 사용하여 문제를 해결하거나 분석 대시보드를 빌드할 때 유용합니다.
로그는 Application Gateway의 모든 리소스에 사용할 수 있습니다. 그러나 이를 사용하려면 선택한 스토리지 위치에서 해당 컬렉션을 사용하도록 설정해야 합니다. Azure Application Gateway의 로깅은 Azure Monitor 서비스를 통해 사용하도록 설정할 수 있습니다. 미리 정의된 쿼리를 쉽게 사용하고 특정 로그 조건에 따라 경고를 설정할 수 있으므로 Log Analytics 작업 영역을 사용하는 것이 좋습니다.
진단 로그 유형
Azure에서 다양한 유형의 로그를 사용하여 Application Gateway를 관리하고 문제를 해결할 수 있습니다. 아래에서 이러한 유형에 대해 자세히 알아볼 수 있습니다.
- 활동 로그 - Azure 활동 로그(이전의 작업 로그 및 감사 로그)를 사용하여 Azure 구독에 제출된 모든 작업과 상태를 확인할 수 있습니다. 활동 로그 항목은 기본적으로 수집되고 Azure Portal에서 볼 수 있습니다.
- 액세스 리소스 로그: 이 로그를 사용하여 Application Gateway 액세스 패턴을 확인하고 중요한 정보를 분석할 수 있습니다. 여기에는 호출자의 IP, 요청된 URL, 응답 대기 시간, 반환 코드, 바이트 입출력이 포함됩니다. 액세스 로그는 60초마다 수집됩니다. 이 로그에는 Application Gateway 인스턴스당 하나의 레코드가 포함됩니다. Application Gateway 인스턴스는 instanceId 속성으로 식별됩니다.
- 성능 로그 - 이 로그를 사용하여 Application Gateway 인스턴스를 수행하는 방법을 확인할 수 있습니다. 이 로그는 인스턴스 단위로 처리된 총 요청 수, 처리량(바이트), 실패한 요청 수, 정상 및 비정상 백 엔드 인스턴스 수 등의 성능 정보를 캡처합니다. 성능 로그는 60초마다 수집됩니다. 성능 로그는 v1 SKU에 대해서만 사용할 수 있습니다. v2 SKU의 경우 성능 데이터에 대한 메트릭을 사용합니다.
- 방화벽 로그 - 이 로그를 사용하면 웹 애플리케이션 방화벽으로 구성된 애플리케이션 게이트웨이의 검색 모드 또는 방지 모드를 통해 로깅된 요청을 확인할 수 있습니다. 방화벽 로그는 60초마다 수집됩니다.
참고 항목
로그는 Azure Resource Manager 배포 모델에 배포된 리소스에만 사용할 수 있습니다. 클래식 배포 모델에서 리소스에 대한 로그를 사용할 수 없습니다. 두 모델에 대해 더 잘 이해하려면 리소스 관리자 배포 및 클래식 배포 이해 문서를 참조하세요.
스토리지 위치
원하는 위치에 로그를 저장할 수 있는 옵션은 다음과 같습니다.
로그 분석 작업 영역: 이 옵션을 사용하면 미리 정의된 쿼리, 시각화를 쉽게 사용하고 특정 로그 조건에 따라 경고를 설정할 수 있습니다. 로그 분석 작업 영역의 리소스 로그에 사용되는 테이블은 리소스가 사용하는 컬렉션 형식에 따라 다릅니다.
Azure Diagnostics: 데이터는 Azure Diagnostics 테이블에 기록됩니다. Azure Diagnostics 테이블은 여러 리소스 종류 간에 공유되며 각 리소스 종류에는 고유한 사용자 지정 필드가 추가됩니다. Azure Diagnostics 테이블에 수집된 사용자 지정 필드 수가 500개를 초과하면 새 필드가 최상위 수준으로 추가되지 않고 "AdditionalFields" 필드에 동적 키 값 쌍으로 추가됩니다.
리소스별(권장): 데이터는 리소스의 각 범주에 대한 전용 테이블에 기록됩니다. 리소스 특정 모드에서는 진단 설정에서 선택한 각 로그 범주에 선택한 작업 영역 내의 자체 테이블이 할당됩니다. 여기에는 다음과 같은 여러 가지 이점이 있습니다.
- 로그 쿼리에서 더 쉬운 데이터 조작
- 스키마 및 해당 구조의 검색 가능성 개선
- 수집 대기 시간 및 쿼리 시간 측면에서 향상된 성능
- 특정 테이블에 대한 Azure 역할 기반 액세스 제어 권한을 할당하는 기능
Application Gateway의 경우 리소스 특정 모드는 세 개의 테이블을 만듭니다.
참고 항목
리소스별 옵션은 현재 모든 공용 지역에서 사용할 수 있습니다.
기존 사용자는 Azure Diagnostics를 계속 사용할 수도 있고 진단 설정의 토글을 리소스별로 전환하거나 API 대상에서 전용으로 전환하여 전용 테이블을 선택할 수도 있습니다. 듀얼 모드는 불가능합니다. 모든 로그의 데이터는 Azure Diagnostics 또는 전용 테이블로 흐를 수 있습니다. 그러나 한 데이터 흐름은 Azure 진단으로 진행되고 다른 데이터 흐름은 동시에 특정 리소스를 사용하는 여러 진단 설정이 있을 수 있습니다.
로그 분석에서 대상 테이블 선택: 모든 Azure 서비스는 결국 리소스별 테이블을 사용합니다. 이 전환의 일환으로 토글 단추를 사용하여 진단 설정에서 Azure 진단 또는 리소스별 테이블을 선택할 수 있습니다. 토글은 기본적으로 리소스별로 설정되어 있으며 이 모드에서는 새로 선택한 범주에 대한 로그가 Log Analytics의 전용 테이블로 전송되고 기존 스트림은 변경되지 않습니다. 다음 예를 참조하세요.
작업 영역 변환: 리소스별 옵션을 선택하면 데이터가 작업 영역 변환으로 수집되기 전에 데이터를 필터링하고 수정할 수 있습니다. 이를 통해 세부적인 제어가 가능하므로 데이터 비용을 줄이고 보안을 강화하여 로그에서 가장 관련성이 높은 정보에 집중할 수 있습니다. 작업 영역 변환 설정에 대한 자세한 지침은 자습서: Azure Portal을 사용하여 Azure Monitor 로그에 작업 영역 변환 추가를 참조하세요.
작업 영역 변환을 사용한 액세스 로그 최적화의 예
예 1: 열의 선택적 프로젝션: 20개의 열이 있는 애플리케이션 게이트웨이 액세스 로그가 있지만 6개의 특정 열의 데이터만 분석하는 데 관심이 있다고 가정해 보세요. 작업 영역 변환을 사용하면 이러한 6개 열을 작업 영역에 프로젝션하고 나머지 14개 열은 효과적으로 제외할 수 있습니다. 제외된 열의 원본 데이터는 저장되지 않지만 해당 열에 대한 빈 자리 표시자는 여전히 로그 블레이드에 나타납니다. 이 방식은 스토리지를 최적화하고 관련 데이터만 분석을 위해 보존되도록 보장합니다.
참고 항목
로그 블레이드 내에서 새 Log Analytics 사용해 보기 옵션을 선택하면 사용자 인터페이스에 표시되는 열을 더 효과적으로 제어할 수 있습니다.
예 2: 특정 상태 코드에 포커스: 액세스 로그를 분석할 때 모든 로그 항목을 처리하는 대신 특정 HTTP 상태 코드(예: 4xx 및 5xx)가 있는 행만 쿼리하는 쿼리를 작성할 수 있습니다. 대부분의 요청은 이상적으로 2xx 및 3xx 범주(성공적인 응답을 나타냄)에 속하므로 문제가 있는 상태 코드에 포커스를 맞추면 데이터 세트의 범위가 좁아집니다. 이러한 대상 방식을 통해 가장 관련성이 높고 실행 가능한 정보를 추출할 수 있어 유익하고 비용 효율적입니다.
Azure 진단에서 리소스별 테이블로 이동하기 위한 권장 전환 전략:
- 현재 데이터 보존 평가: 데이터가 현재 Azure Diagnostics 테이블에 보존되는 기간을 결정합니다(예: 진단 테이블이 15일 동안 데이터를 보존한다고 가정).
- 리소스별 보존 설정: 리소스별 테이블을 사용하여 새로운 진단 설정을 구현합니다.
- 병렬 데이터 수집: 임시 기간 동안 Azure Diagnostics 및 리소스별 설정 모두에서 동시에 데이터를 수집합니다.
- 데이터 정확도 확인: 두 설정 모두에서 데이터 수집이 정확하고 일관되는지 확인합니다.
- Azure Diagnostics 설정 제거: 중복 데이터 수집을 방지하려면 Azure Diagnostics 설정을 제거합니다.
기타 스토리지 위치:
- Azure Storage 계정: 스토리지 계정은 로그를 장기간 저장하고 필요할 때 검토하는 경우에 가장 적합합니다.
- Azure Event Hubs: 이벤트 허브는 리소스에 대한 경고를 받기 위해 다른 SIEM(보안 정보 및 이벤트 관리) 도구와 통합하는 데 유용한 옵션입니다.
- Azure Monitor 파트너 통합.
Azure Monitor의 진단 설정 대상에 대해 자세히 알아봅니다.
PowerShell을 통한 로깅 사용
활동 로깅은 모든 Resource Manager 리소스에 대해 사용하도록 설정됩니다. 이러한 로그를 통해 사용 가능한 데이터 수집을 시작하려면 액세스 및 성능 로깅을 사용하도록 설정해야 합니다. 로깅을 사용하려면 다음 단계를 사용합니다.
로그 데이터를 저장할 스토리지 계정의 리소스 ID를 적어 둡니다. 이 값의 형식은 /subscriptions/<subscriptionId>/resourceGroups/<리소스 그룹 이름>/providers/Microsoft.Storage/storageAccounts/<스토리지 계정 이름>입니다. 구독의 모든 스토리지 계정을 사용할 수 있습니다. Azure Portal을 사용하여 이 정보를 찾을 수 있습니다.
로깅을 사용할 Application Gateway의 리소스 ID를 적어 둡니다. 이 값은 형식은 /subscriptions/<subscriptionId>/resourceGroups/<리소스 그룹 이름>/providers/Microsoft.Network/applicationGateways/<응용 프로그램 게이트웨이 이름>입니다. 포털을 사용하여 이 정보를 찾을 수 있습니다.
다음 PowerShell cmdlet을 사용하여 진단 로깅을 사용하도록 설정합니다.
Set-AzDiagnosticSetting -ResourceId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name> -StorageAccountId /subscriptions/<subscriptionId>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name> -Enabled $true
팁
활동 로그에는 별도의 스토리지 계정이 필요하지 않습니다. 액세스 및 성능 로깅에 스토리지를 사용할 경우 서비스 요금이 부과됩니다.
Azure Portal을 통한 로깅 사용
Azure Portal에서 리소스를 찾고 진단 설정을 선택합니다.
Application Gateway의 경우 다음 세 가지 로그를 사용할 수 있습니다.
- 액세스 로그
- 성능 로그
- 방화벽 로그
데이터 수집을 시작하려면 진단 켜기를 선택합니다.
진단 설정 페이지에서는 진단 로그에 대한 설정을 제공합니다. 이 예제에서 Log Analytics는 로그를 저장합니다. 또한 이벤트 허브 및 스토리지 계정을 사용하여 진단 로그를 저장할 수도 있습니다.
설정의 이름을 입력하고 설정을 확인하고 저장을 선택합니다.
활동 로그
Azure에서는 기본적으로 활동 로그를 생성합니다. 이러한 로그는 Azure 이벤트 로그 저장소에 90일 동안 유지됩니다. 이벤트 및 활동 로그 보기 문서를 참조하여 이러한 로그에 대해 자세히 알아보세요.
액세스 로그
이전 단계에서 설명한 대로 액세스 로그는 각 Application Gateway 인스턴스에서 이러한 로그를 사용하도록 설정한 경우에만 생성됩니다. 데이터는 로깅을 사용하도록 설정할 때 지정한 스토리지 계정에 저장됩니다. Application Gateway의 액세스는 각각 다음 예제와 같이 JSON 형식으로 로깅됩니다.
Application Gateway 및 WAF v2 SKU
참고 항목
TLS/TCP 프록시 관련 정보를 보려면 데이터 참조를 참조하세요.
| 값 | 설명 |
|---|---|
| instanceId | 요청을 처리한 Application Gateway 인스턴스 |
| clientIP | Application Gateway 직접 클라이언트의 IP. 다른 프록시가 애플리케이션 게이트웨이를 정면으로 연결하면 앞의 해당 프록시의 IP가 표시됩니다. |
| httpMethod | 요청에서 사용된 HTTP 메서드 |
| requestUri | 받은 요청의 URI |
| UserAgent | HTTP 요청 헤더의 사용자 에이전트 |
| httpStatus | Application Gateway에서 클라이언트로 반환한 HTTP 상태 코드 |
| httpVersion | 요청의 HTTP 버전 |
| receivedBytes | 받은 패킷의 크기(바이트) |
| sentBytes | 보낸 패킷의 크기(바이트) |
| clientResponseTime | 클라이언트로 전송된 첫 번째 바이트와 마지막 바이트 애플리케이션 게이트웨이 간의 시간 차이(초)입니다. 응답 또는 느린 클라이언트에 대한 Application Gateway의 처리 시간을 측정하는 데 유용합니다. |
| timeTaken | 클라이언트 요청의 첫 번째 바이트가 처리되고 클라이언트에 대한 응답으로 마지막 바이트가 전송되는 데 걸리는 시간(초)입니다. 걸린 시간(Time-Taken) 필드에는 대개 요청 및 응답 패킷이 네트워크를 통해 이동하는 시간이 포함됩니다. |
| WAFEvaluationTime | WAF에서 요청을 처리하는 데 걸리는 시간(초)입니다. |
| WAFMode | 값은 검색 또는 방지일 수 있습니다. |
| transactionId | 클라이언트에서 받은 요청의 상관 관계를 지정하는 고유 식별자 |
| sslEnabled | 백 엔드 풀에 대한 통신에서 TLS를 사용했는지 여부입니다. 유효한 값은 on과 off입니다. |
| sslCipher | TLS 통신에 사용되는 암호화 도구 모음입니다(TLS가 사용 설정된 경우). |
| sslProtocol | 사용되는 SSL/TLS 프로토콜입니다(TLS가 사용 설정된 경우). |
| serverRouted | Application Gateway에서 요청을 라우팅하는 백 엔드 서버입니다. |
| serverStatus | 백 엔드 서버의 HTTP 상태 코드입니다. |
| serverResponseLatency | 백 엔드 서버의 응답 대기 시간(초 단위)입니다. |
| host | 요청의 호스트 헤더에 나열된 주소입니다. 헤더 다시 쓰기를 사용하여 다시 생성하는 경우 이 필드에 업데이트된 호스트 이름이 포함됩니다. |
| originalRequestUriWithArgs | 이 필드에는 원래 요청 URL이 포함됩니다 |
| requestUri | 이 필드에는 Application Gateway에 다시 쓰기 작업 후 URL이 포함됩니다 |
| upstreamSourcePort | 백 엔드 대상에 대한 연결을 시작할 때 Application Gateway에서 사용하는 원본 포트 |
| originalHost | 이 필드는 원래 요청 호스트 이름을 포함합니다. |
| error_info | 4xx 및 5xx 오류의 원인입니다. 실패한 요청에 대한 오류 코드를 표시합니다. 오류 코드 정보에 대한 자세한 내용입니다. |
| contentType | 애플리케이션 게이트웨이에서 처리 또는 배달하는 콘텐츠 또는 데이터의 형식 |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"listenerName": "HTTP-Listener",
"ruleName": "Storage-Static-Rule",
"backendPoolName": "StaticStorageAccount",
"backendSettingName": "StorageStatic-HTTPS-Setting",
"operationName": "ApplicationGatewayAccess",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "appgw_2",
"clientIP": "185.42.129.24",
"clientPort": 45057,
"httpMethod": "GET",
"originalRequestUriWithArgs": "\/",
"requestUri": "\/",
"requestQuery": "",
"userAgent": "Mozilla\/5.0 (Windows NT 6.1; WOW64) AppleWebKit\/537.36 (KHTML, like Gecko) Chrome\/52.0.2743.116 Safari\/537.36",
"httpStatus": 200,
"httpVersion": "HTTP\/1.1",
"receivedBytes": 184,
"sentBytes": 466,
"clientResponseTime": 0,
"timeTaken": 0.034,
"WAFEvaluationTime": "0.000",
"WAFMode": "Detection",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"sslEnabled": "on",
"sslCipher": "ECDHE-RSA-AES256-GCM-SHA384",
"sslProtocol": "TLSv1.2",
"sslClientVerify": "NONE",
"sslClientCertificateFingerprint": "",
"sslClientCertificateIssuerName": "",
"serverRouted": "52.239.221.65:443",
"serverStatus": "200",
"serverResponseLatency": "0.028",
"upstreamSourcePort": "21564",
"originalHost": "20.110.30.194",
"host": "20.110.30.194",
"error_info":"ERRORINFO_NO_ERROR",
"contentType":"application/json"
}
}
참고 항목
clientIP 값이 127.0.0.1인 액세스 로그는 애플리케이션 게이트웨이 인스턴스에서 실행되는 내부 보안 프로세스에서 발생합니다. 이러한 로그 항목는 무시해도 됩니다.
Application Gateway Standard 및 WAF SKU(v1)
| 값 | 설명 |
|---|---|
| instanceId | 요청을 처리한 Application Gateway 인스턴스 |
| clientIP | 요청에 대한 원래 IP |
| clientPort | 요청에 대한 원래 포트 |
| httpMethod | 요청에서 사용된 HTTP 메서드 |
| requestUri | 받은 요청의 URI |
| RequestQuery | 서버 라우팅: 요청을 보낸 백 엔드 풀 인스턴스. X-AzureApplicationGateway-LOG-ID: 요청에 사용된 상관 관계 ID입니다. 백 엔드 서버에서 트래픽 문제를 해결하는 데 사용할 수 있습니다. SERVER-STATUS: Application Gateway에서 백 엔드로부터 받은 HTTP 응답 코드 |
| UserAgent | HTTP 요청 헤더의 사용자 에이전트 |
| httpStatus | Application Gateway에서 클라이언트로 반환한 HTTP 상태 코드 |
| httpVersion | 요청의 HTTP 버전 |
| receivedBytes | 받은 패킷의 크기(바이트) |
| sentBytes | 보낸 패킷의 크기(바이트) |
| timeTaken | 요청을 처리하고 응답을 보내는 데 걸리는 시간(밀리초)입니다. 이 값은 Application Gateway에서 HTTP 요청의 첫 번째 바이트를 받은 시점부터 응답 보내기 작업을 완료하는 시점까지의 간격으로 계산됩니다. 걸린 시간(Time-Taken) 필드에는 대개 요청 및 응답 패킷이 네트워크를 통해 이동하는 시간이 포함됩니다. |
| sslEnabled | 백 엔드 풀에 대한 통신에서 TLS/SSL을 사용했는지 여부. 유효한 값은 on과 off입니다. |
| host | 요청이 백 엔드 서버로 전송된 호스트 이름입니다. 백 엔드 호스트 이름이 재정의되는 경우 이 이름에 반영됩니다. |
| originalHost | 클라이언트로부터 Application Gateway가 요청을 받은 호스트 이름입니다. |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/PEERINGTEST/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayAccess",
"time": "2017-04-26T19:27:38Z",
"category": "ApplicationGatewayAccessLog",
"properties": {
"instanceId": "ApplicationGatewayRole_IN_0",
"clientIP": "191.96.249.97",
"clientPort": 46886,
"httpMethod": "GET",
"requestUri": "/phpmyadmin/scripts/setup.php",
"requestQuery": "X-AzureApplicationGateway-CACHE-HIT=0&SERVER-ROUTED=10.4.0.4&X-AzureApplicationGateway-LOG-ID=874f1f0f-6807-41c9-b7bc-f3cfa74aa0b1&SERVER-STATUS=404",
"userAgent": "-",
"httpStatus": 404,
"httpVersion": "HTTP/1.0",
"receivedBytes": 65,
"sentBytes": 553,
"timeTaken": 205,
"sslEnabled": "off",
"host": "www.contoso.com",
"originalHost": "www.contoso.com"
}
}
오류 코드 정보
애플리케이션 게이트웨이가 요청을 완료할 수 없는 경우 액세스 로그의 error_info 필드에 다음 이유 코드 중 하나를 저장합니다.
| 4XX 오류 | (4xx 오류 코드는 클라이언트 요청에 문제가 있었고 Application Gateway가 이를 이행할 수 없음을 나타냅니다.) |
|---|---|
| ERRORINFO_INVALID_METHOD | 클라이언트가 비 RFC 규격인 요청을 보냈습니다. 가능한 이유: 서버에서 지원하지 않는 HTTP 메서드를 사용하는 클라이언트, 철자가 잘못된 메서드, 호환되지 않는 HTTP 프로토콜 버전 등 |
| ERRORINFO_INVALID_REQUEST | 잘못된 구문으로 인해 서버가 요청을 처리할 수 없습니다. |
| ERRORINFO_INVALID_VERSION | 애플리케이션 게이트웨이가 잘못되었거나 지원되지 않는 HTTP 버전으로 요청을 받았습니다. |
| ERRORINFO_INVALID_09_METHOD | 클라이언트가 HTTP 프로토콜 버전 0.9를 사용하여 요청을 보냈습니다. |
| ERRORINFO_INVALID_HOST | "Host" 헤더에 제공된 값이 누락되었거나 형식이 잘못되었거나 예상 호스트 값과 일치하지 않습니다. 예를 들어, 기본 수신기가 없고 다중 사이트 수신기의 호스트 이름이 호스트와 일치하지 않는 경우입니다. |
| ERRORINFO_INVALID_CONTENT_LENGTH | content-Length 헤더에서 클라이언트가 지정한 콘텐츠의 길이가 요청에 있는 실제 콘텐츠의 길이와 일치하지 않습니다. |
| ERRORINFO_INVALID_METHOD_TRACE | 클라이언트가 애플리케이션 게이트웨이에서 지원하지 않는 HTTP TRACE 메서드를 보냈습니다. |
| ERRORINFO_CLIENT_CLOSED_REQUEST | 클라이언트는 유휴 제한 시간이 경과하기 전에 애플리케이션 게이트웨이와의 연결을 닫았습니다. 클라이언트 시간 제한 기간이 애플리케이션 게이트웨이의 유휴 시간 제한 기간보다 긴지 확인합니다. |
| ERRORINFO_REQUEST_URI_INVALID | 클라이언트의 요청에 제공된 URI(Uniform Resource Identifier)에 문제가 있음을 나타냅니다. |
| ERRORINFO_HTTP_NO_HOST_HEADER | 클라이언트가 호스트 헤더 없이 요청을 보냈습니다. |
| ERRORINFO_HTTP_TO_HTTPS_PORT | 클라이언트가 HTTPS 포트에 일반 HTTP 요청을 보냈습니다. |
| ERRORINFO_HTTPS_NO_CERT | 클라이언트가 상호 TLS 인증 중에 유효하고 적절하게 구성된 TLS 인증서를 보내지 않음을 나타냅니다. |
| 5XX 오류 | 설명 |
|---|---|
| ERRORINFO_UPSTREAM_NO_LIVE | 애플리케이션 게이트웨이가 들어오는 요청을 처리할 활성 또는 연결 가능한 백 엔드 서버를 찾을 수 없습니다. |
| ERRORINFO_UPSTREAM_CLOSED_CONNECTION | 백 엔드 서버가 예기치 않게 또는 요청이 완전히 처리되기 전에 연결을 닫았습니다. 이 오류는 백 엔드 서버가 한계에 도달하거나 충돌하는 등으로 인해 발생할 수 있습니다. |
| ERRORINFO_UPSTREAM_TIMED_OUT | 서버와 설정된 TCP 연결은 구성된 시간 제한 값보다 오래 걸리기 때문에 닫혔습니다. |
성능 로그
이전 단계에서 설명한 대로 성능 로그는 각 Application Gateway 인스턴스에서 이러한 로그를 사용하도록 설정한 경우에만 생성됩니다. 데이터는 로깅을 사용하도록 설정할 때 지정한 스토리지 계정에 저장됩니다. 성능 로그 데이터는 1분 간격으로 생성됩니다. v1 SKU에만 사용할 수 있습니다. v2 SKU의 경우 성능 데이터에 대한 메트릭을 사용합니다. 다음 데이터가 로깅됩니다.
| 값 | 설명 |
|---|---|
| instanceId | 성능 데이터가 생성되는 Application Gateway 인스턴스입니다. 다중 인스턴스 애플리케이션 게이트웨이의 경우 인스턴스마다 하나의 행이 있습니다. |
| healthyHostCount | 백 엔드 풀의 정상 호스트 수. |
| unHealthyHostCount | 백 엔드 풀의 비정상 호스트 수. |
| requestCount | 처리된 요청 수 |
| 대기 시간 | 인스턴스와 요청을 처리하는 백 엔드 사이의 평균 요청 대기 시간(밀리초)입니다. |
| failedRequestCount | 실패한 요청 수 |
| throughput | 마지막 로그 이후의 평균 처리량(초당 바이트 수로 측정됨) |
{
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayPerformance",
"time": "2016-04-09T00:00:00Z",
"category": "ApplicationGatewayPerformanceLog",
"properties":
{
"instanceId":"ApplicationGatewayRole_IN_1",
"healthyHostCount":"4",
"unHealthyHostCount":"0",
"requestCount":"185",
"latency":"0",
"failedRequestCount":"0",
"throughput":"119427"
}
}
참고 항목
대기 시간은 HTTP 요청의 첫 번째 바이트를 받은 시간부터 HTTP 응답의 마지막 바이트를 보낸 시간까지 계산됩니다. 즉 Application Gateway 처리 시간, 백 엔드로의 네트워크 사용 시간 및 백 엔드에서 요청을 처리하는 데 걸린 시간의 합계입니다.
방화벽 로그
이전 단계에서 설명한 대로 방화벽 로그는 각 애플리케이션 게이트웨이에서 이러한 로그를 사용하도록 설정한 경우에만 생성됩니다. 또한 이 로그를 사용하려면 애플리케이션 게이트웨이에서 웹 애플리케이션 방화벽을 구성해야 합니다. 데이터는 로깅을 사용하도록 설정할 때 지정한 스토리지 계정에 저장됩니다. 다음 데이터가 로깅됩니다.
| 값 | 설명 |
|---|---|
| instanceId | 방화벽 데이터가 생성되는 Application Gateway 인스턴스입니다. 다중 인스턴스 애플리케이션 게이트웨이의 경우 인스턴스마다 하나의 행이 있습니다. |
| clientIp | 요청에 대한 원래 IP |
| clientPort | 요청에 대한 원래 포트 |
| requestUri | 받은 요청의 URL |
| ruleSetType | 규칙 집합 유형이며, 사용 가능한 값은 OWASP입니다. |
| ruleSetVersion | 사용된 규칙 집합 버전이며, 사용 가능한 값은 2.2.9 및 3.0입니다. |
| ruleId | 트리거 이벤트의 규칙 ID |
| message | 사용자에게 친숙한 트리거 이벤트에 대한 메시지이며, 자세한 내용은 세부 정보 섹션에서 제공됩니다. |
| 작업 | 요청에서 수행되는 동작이며, 사용 가능한 값은 차단 및 허용(사용자 지정 규칙의 경우), 일치(규칙이 요청의 일부와 일치하는 경우), 및 검색되고 차단(WAF가 검색 또는 방지 모드에 있는지에 따라 둘 다 필수 규칙임)됩니다. |
| 사이트 | 로그를 생성한 사이트이며, 현재 규칙이 전역이므로 Global만 나열됩니다. |
| details | 트리거 이벤트의 세부 정보 |
| details.message | 규칙에 대한 설명 |
| details.data | 규칙과 일치하는 요청 내 특정 데이터 |
| details.file | 규칙이 포함된 구성 파일 |
| details.line | 이벤트를 트리거한 구성 파일의 줄 번호 |
| hostname | Application Gateway의 호스트 이름 또는 IP 주소입니다. |
| transactionId | 동일한 요청 내에서 발생한 여러 규칙 위반을 그룹화하는 데 도움이 되는 지정된 트랜잭션의 고유 ID입니다. |
{
"timeStamp": "2021-10-14T22:17:11+00:00",
"resourceId": "/SUBSCRIPTIONS/{subscriptionId}/RESOURCEGROUPS/{resourceGroupName}/PROVIDERS/MICROSOFT.NETWORK/APPLICATIONGATEWAYS/{applicationGatewayName}",
"operationName": "ApplicationGatewayFirewall",
"category": "ApplicationGatewayFirewallLog",
"properties": {
"instanceId": "appgw_2",
"clientIp": "185.42.129.24",
"clientPort": "",
"requestUri": "\/",
"ruleSetType": "OWASP_CRS",
"ruleSetVersion": "3.0.0",
"ruleId": "920350",
"message": "Host header is a numeric IP address",
"action": "Matched",
"site": "Global",
"details": {
"message": "Warning. Pattern match \\\"^[\\\\d.:]+$\\\" at REQUEST_HEADERS:Host .... ",
"data": "20.110.30.194:80",
"file": "rules\/REQUEST-920-PROTOCOL-ENFORCEMENT.conf",
"line": "791"
},
"hostname": "20.110.30.194:80",
"transactionId": "592d1649f75a8d480a3c4dc6a975309d",
"policyId": "default",
"policyScope": "Global",
"policyScopeName": "Global"
}
}
활동 로그 보기 및 분석
다음 방법 중 하나를 사용하여 활동 로그 데이터를 확인하고 분석할 수 있습니다.
- Azure 도구 - Azure PowerShell, Azure CLI, Azure REST API 또는 Azure Portal을 통해 활동 로그에서 정보를 검색합니다. 각 방법에 대한 단계별 지침은 Resource Manager의 활동 작업 문서에 자세히 나와 있습니다.
- Power BI - Power BI 계정이 아직 없는 경우 무료로 사용해볼 수 있습니다. Power BI 템플릿 앱을 사용하여 데이터를 분석할 수 있습니다.
액세스, 성능 및 방화벽 로그 보기 및 분석
Azure Monitor 로그는 Blob Storage 계정에서 카운터 및 이벤트 로그 파일을 수집할 수 있습니다. 여기에는 로그를 분석하는 시각화 및 강력한 검색 기능이 포함되어 있습니다.
스토리지 계정에 연결하고 액세스 및 성능 로그에 대한 JSON 로그 항목을 검색할 수도 있습니다. JSON 파일을 다운로드한 후 CSV로 변환하여 Excel, Power BI 또는 기타 데이터 시각화 도구에서 볼 수 있습니다.
팁
Visual Studio를 익숙하게 사용할 수 있고 C#에서 상수 및 변수에 대한 값 변경에 대한 기본 개념이 있는 경우 GitHub에서 제공하는 로그 변환기 도구를 사용할 수 있습니다.
GoAccess를 통해 액세스 로그 분석
Application Gateway 액세스 로그에 대해 널리 사용되는 GoAccess 로그 분석기를 설치하고 실행하는 Resource Manager 템플릿을 게시했습니다. GoAccess는 고유 방문자, 요청한 파일, 호스트, 운영 체제, 브라우저, HTTP 상태 코드 및 기타 유용한 HTTP 트래픽 통계를 제공 합니다. 자세한 내용은 GitHub의 Resource Manager 템플릿 폴더에 대한 추가 정보 파일을 참조하세요.
다음 단계
- Azure Monitor 로그를 사용하여 카운터 및 이벤트 로그를 시각화합니다.
- Power BI를 사용하여 Azure 활동 로그 시각화 블로그 게시물
- Power BI 등에서 Azure 활동 로그 보기 및 분석 블로그 게시물