Application Insights 가용성 테스트

Application Insights를 사용하면 전 세계 다양한 지점에서 웹 사이트 또는 애플리케이션의 가용성 및 응답성을 모니터링하는 되풀이 웹 테스트를 설정할 수 있습니다. 이러한 가용성 테스트는 정기적으로 애플리케이션에 웹 요청을 보내고 애플리케이션이 응답하지 않거나 응답 시간이 너무 느린 경우 경고합니다.

가용성 테스트는 테스트하는 웹 사이트 또는 애플리케이션을 수정할 필요가 없습니다. 서비스가 종속된 REST API를 포함하여 공용 인터넷에서 액세스할 수 있는 HTTP 또는 HTTPS 엔드포인트에서 작동합니다. 즉, 사용자 고유의 애플리케이션뿐만 아니라 애플리케이션의 기능에 중요한 외부 서비스도 모니터링할 수 있습니다. Application Insights 리소스당 최대 100개의 가용성 테스트를 만들 수 있습니다.

가용성 테스트 유형

가용성 테스트에는 다음 네 가지 형식이 있습니다.

• 표준 테스트: 사용되지 않는 URL ping 테스트와 유사하게 단일 요청을 전송하여 웹 사이트의 가용성을 확인하는 가용성 테스트 유형입니다. 엔드포인트가 응답하는지 확인하고 성능을 측정하는 것 외에도 표준 테스트에는 TLS/SSL 인증서 유효성 검사, 자동 관리 수명 검사, HTTP 요청 동사(예: GET, HEAD 및 POST), 사용자 지정 헤더, HTTP 요청과 연결된 사용자 지정 데이터도 포함됩니다.

  표준 테스트를 만드는 방법을 알아봅니다.

• 사용자 지정 TrackAvailability 테스트: 가용성 테스트를 실행할 사용자 지정 애플리케이션을 만들기로 결정한 경우 TrackAvailability() 메서드를 사용하여 결과를 Application Insights에 보낼 수 있습니다.

  사용자 지정 TrackAvailability 테스트를 만드는 방법을 알아봅니다.

• (사용되지 않음) 다단계 웹 테스트: 이 웹 요청 시퀀스 기록을 재생하여 더 복잡한 시나리오를 테스트할 수 있습니다. 다단계 웹 테스트는 Visual Studio Enterprise에서 만들고 포털에 업로드하여 실행할 수 있습니다.

• (사용되지 않음) URL ping 테스트: Azure Portal에서 이 테스트를 만들어 엔드포인트가 응답하는지 확인하고 해당 응답과 관련된 성능을 측정할 수 있습니다. 종속 요청 구문 분석, 재시도 허용과 같은 고급 기능과 결합된 사용자 지정 성공 조건도 설정할 수 있습니다.

가용성 집합 만들기

가용성 경고

경고는 기본적으로 사용하도록 설정되지만 경고를 완전히 구성하려면 처음으로 가용성 테스트를 만들어야 합니다.

위치 채우기 태그

Azure Resource Manager를 사용하여 표준 테스트 또는 URL ping 테스트를 배포할 때 지리적 위치 특성에 대해 다음과 같은 채우기 태그를 사용할 수 있습니다.

경고 사용

1. 가용성 테스트를 저장한 후 수행한 테스트로 상황에 맞는 메뉴를 연 다음 규칙 열기(경고) 페이지를 선택합니다.

   

2. 경고 규칙 페이지에서 경고를 연 다음 위쪽 탐색 모음에서 편집을 선택합니다. 여기서 이 경고 규칙에 사용할 알림 기본 설정이 있는 심각도 수준, 규칙 설명 및 작업 그룹을 설정할 수 있습니다.

   

경고 조건

자동으로 사용하도록 설정된 가용성 경고는 엔드포인트를 사용할 수 없게 되면 하나의 이메일을 트리거하고 다시 사용할 수 있게 되면 또 다른 이메일을 트리거합니다. 이 환경을 통해 만들어지는 가용성 경고는 상태 기반입니다. 경고 조건이 충족되면 웹 사이트가 사용할 수 없는 것으로 검색될 경우 단일 경고가 생성됩니다. 다음에 경고 조건을 평가할 때 웹 사이트가 여전히 다운된 경우에는 새 경고가 생성되지 않습니다.

예를 들어 웹 사이트가 1시간 동안 중단되고 평가 빈도가 15분인 이메일 경고를 설정한다고 가정합니다. 웹사이트가 다운된 경우에만 이메일을 받게 되며, 다시 온라인 상태가 되면 또 다른 이메일을 받게 됩니다. 15분마다 웹 사이트가 사용할 수 없는 상태임을 알리는 지속적인 경고를 받지는 않습니다.

경고 조건 변경

예를 들어 유지 관리 중에 웹 사이트가 짧은 기간 동안만 다운된 경우 알림을 받지 못할 수 있습니다. 평가 빈도를 예상 가동 중지 시간보다 높은 값(최대 15분)으로 변경할 수 있습니다. 또한 경고 위치 임계값을 증가시켜 특정 수의 지역에서 웹 사이트가 다운된 경우에만 경고를 트리거할 수 있습니다.

위치 임곗값, 집계 기간 및 테스트 빈도를 변경하려면 경고 규칙 편집 페이지(경고 사용 아래의 2단계 참조)로 이동한 다음, 조건을 선택하여 신호 논리 구성 창을 엽니다.

사용자 지정 경고 규칙 만들기

고급 기능이 필요한 경우 경고 탭에서 사용자 지정 경고 규칙을 만들 수 있습니다. 만들기>경고 규칙을 선택합니다. 사용 가능한 모든 신호를 표시하려면 신호 유형에 대해 메트릭을 선택하고 가용성을 선택합니다.

사용자 지정 경고 규칙은 집계 기간(6시간 대신 최대 24시간) 및 테스트 빈도(15분 대신 최대 1시간)에 대해 더 높은 값을 제공합니다. 또한 다양한 연산자, 집계 형식 및 임계값을 선택하여 논리를 추가로 정의하는 옵션을 추가합니다.

• Y 위치에서 오류를 보고하는 X에 대해 경고: Y 위치에서 X 경고 규칙은 새 가용성 테스트를 만들 때 기본적으로 새로 통합된 경고 환경에서 사용하도록 설정됩니다. “클래식” 옵션을 선택하거나 경고 규칙을 사용하지 않도록 선택하여 옵트아웃할 수 있습니다. 앞의 단계에 따라 경고가 트리거될 때 알림을 받으려면 작업 그룹을 구성합니다. 이 단계가 없으면 규칙이 트리거될 때 포털 내 알림만 받게 됩니다.

• 가용성 메트릭에 대한 경고: 새 통합 경고를 사용하면 분할된 집계 가용성 및 테스트 기간 메트릭에 대해서도 경고할 수 있습니다.

  1. 메트릭 환경에서 Application Insights 리소스를 선택하고, 가용성 메트릭을 선택합니다.

  2. 메뉴에서 경고 구성 옵션을 사용하면 경고 규칙을 설정할 특정 테스트 또는 위치를 선택할 수 있는 새 환경으로 이동합니다. 또한 여기에서 이 경고 규칙에 대한 작업 그룹을 구성할 수도 있습니다.

• 사용자 지정 분석 쿼리에 대한 경고: 새 통합 경고를 사용하여 사용자 지정 로그 쿼리에 대해 경고할 수 있습니다. 사용자 지정 쿼리를 통해 임의의 모든 조건에 대해 경고하여 가용성 문제에서 가장 안정적인 신호를 얻을 수 있습니다. 또한 TrackAvailability SDK를 사용하여 사용자 지정 가용성 결과를 보내는 경우에도 이 방식을 적용할 수 있습니다.

  가용성 데이터에 대한 메트릭에는 TrackAvailability SDK를 호출하여 제출할 수 있는 사용자 지정 가용성 결과가 모두 포함됩니다. 사용자 지정 가용성 결과를 경고하려면 메트릭 지원에 대한 경고를 사용할 수 있습니다.

경고 자동화

Azure Resource Manager 템플릿을 사용하여 이 프로세스를 자동화하려면 Azure Resource Manager 템플릿을 사용하여 메트릭 경고 만들기를 참조하세요.

가용성 테스트 결과 참조

이 섹션에서는 Azure Portal에서 가용성 테스트 결과를 검토하고 Log Analytics를 사용하여 데이터를 쿼리하는 방법을 설명합니다. 가용성 테스트 결과는 선 보기와 산점도 보기 모두를 사용하여 시각화할 수 있습니다.

가용성 확인

먼저 Azure Portal의 가용성 환경에서 그래프를 검토합니다.

기본적으로 가용성 환경에는 선 그래프가 표시됩니다. 보기를 산점도(그래프 위 토글)로 변경하여 진단 테스트 단계 세부 정보가 있는 테스트 결과의 샘플을 확인합니다. 테스트 엔진은 실패한 테스트에 대한 진단 정보를 저장합니다. 성공한 테스트의 경우 실행의 하위 집합에 대한 진단 정보가 저장됩니다. 테스트, 테스트 이름 및 위치를 보려면 녹색 점이나 빨간색 십자가를 마우스로 가리킵니다.

특정 테스트 또는 위치를 선택합니다. 또는 기간을 줄여 대상 기간에서 더 많은 결과를 볼 수 있습니다. 검색 탐색기를 사용하여 모든 실행의 결과를 확인합니다. 또는 Log Analytics 쿼리를 사용하여 이 데이터에 대한 사용자 지정 보고서를 실행할 수 있습니다.

엔드투엔드 트랜잭션 세부 정보를 보려면 드릴인에서 성공 또는 실패를 선택합니다. 그런 다음, 샘플을 선택합니다. 그래프에서 데이터 요소를 선택하여 엔드투엔드 트랜잭션 세부 정보를 가져올 수도 있습니다.

테스트 검사 및 편집

테스트를 편집하거나, 일시적으로 사용하지 않도록 설정하거나, 삭제하려면 테스트에서 상황에 맞는 메뉴(줄임표)를 연 다음 편집을 선택합니다. 구성 변경 내용이 모든 테스트 에이전트로 전파되는 데 최대 20분이 걸릴 수 있습니다.

오류가 표시되는 경우

산점도에서 빨간색 십자가를 선택하여 엔드투엔드 트랜잭션 세부 정보 보기를 엽니다.

다음을 수행할 수 있습니다.

• 문제 해결 보고서를 검토하여 테스트가 실패한 원인을 확인합니다.
• 서버로부터 수신한 응답을 검사합니다.
• 실패한 가용성 테스트를 처리하는 동안 수집된 상관 관련된 서버 쪽 원격 분석 데이터로 실패를 진단합니다.
• Git 또는 Azure Boards에서 문제 또는 작업 항목을 기록하여 문제를 추적합니다. 버그에는 Azure Portal의 이벤트에 대한 링크가 포함되어 있습니다.
• 웹 테스트 결과를 Visual Studio에서 엽니다.

엔드투엔드 트랜잭션 진단 환경에 대해 자세히 알아보려면 트랜잭션 진단 설명서를 참조하세요.

가상 가용성 테스트를 실패하게 만든 서버 쪽 예외 세부 정보를 확인하려면 예외 행을 선택합니다. 다양한 코드 수준 진단에 대한 디버그 스냅샷을 가져올 수도 있습니다.

원시 결과 외에도 메트릭 탐색기에서 두 가지 주요 가용성 메트릭을 볼 수도 있습니다.

• 가용성: 모든 테스트 실행에서 성공한 테스트의 비율입니다.
• 테스트 지속 시간: 모든 테스트 실행에서의 평균 테스트 지속 시간입니다.

Log Analytics에서 쿼리

Log Analytics를 사용하여 가용성 결과(availabilityResults), 종속성(dependencies) 등을 볼 수 있습니다. Log Analytics에 대한 자세한 내용을 보려면 로그 쿼리 개요를 참조하세요.

클래식 URL ping 테스트를 표준 테스트로 마이그레이션

다음 단계에서는 URL ping 테스트의 기능을 복제하는 표준 테스트를 만드는 과정을 안내합니다. 이전에 만든 URL ping 테스트를 사용하면 표준 테스트의 고급 기능을 더 쉽게 사용할 수 있습니다.

필수 조건

시작하기

1. Azure PowerShell을 사용하여 구독에 연결합니다(Connect-AzAccount + Set-AzContext).

2. 현재 구독의 모든 URL ping 테스트를 나열합니다.

   Get-AzApplicationInsightsWebTest | `
   Where-Object { $_.WebTestKind -eq "ping" } | `
   Format-Table -Property ResourceGroupName,Name,WebTestKind,Enabled;
   

3. 마이그레이션하려는 URL ping 테스트를 찾아 해당 리소스 그룹과 이름을 기록합니다.

4. HTTP와 HTTPS 엔드포인트 모두에서 작동하는 다음 명령을 사용하여 URL ping 테스트와 동일한 논리로 표준 테스트를 만듭니다.

   $resourceGroup = "pingTestResourceGroup";
   $appInsightsComponent = "componentName";
   $pingTestName = "pingTestName";
   $newStandardTestName = "newStandardTestName";
   
   $componentId = (Get-AzApplicationInsights -ResourceGroupName $resourceGroup -Name $appInsightsComponent).Id;
   $pingTest = Get-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   $pingTestRequest = ([xml]$pingTest.ConfigurationWebTest).WebTest.Items.Request;
   $pingTestValidationRule = ([xml]$pingTest.ConfigurationWebTest).WebTest.ValidationRules.ValidationRule;
   
   $dynamicParameters = @{};
   
   if ($pingTestRequest.IgnoreHttpStatusCode -eq [bool]::FalseString) {
   $dynamicParameters["RuleExpectedHttpStatusCode"] = [convert]::ToInt32($pingTestRequest.ExpectedHttpStatusCode, 10);
   }
   
   if ($pingTestValidationRule -and $pingTestValidationRule.DisplayName -eq "Find Text" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Name -eq "FindText" `
   -and $pingTestValidationRule.RuleParameters.RuleParameter[0].Value) {
   $dynamicParameters["ContentMatch"] = $pingTestValidationRule.RuleParameters.RuleParameter[0].Value;
   $dynamicParameters["ContentPassIfTextFound"] = $true;
   }
   
   New-AzApplicationInsightsWebTest @dynamicParameters -ResourceGroupName $resourceGroup -Name $newStandardTestName `
   -Location $pingTest.Location -Kind 'standard' -Tag @{ "hidden-link:$componentId" = "Resource" } -TestName $newStandardTestName `
   -RequestUrl $pingTestRequest.Url -RequestHttpVerb "GET" -GeoLocation $pingTest.PropertiesLocations -Frequency $pingTest.Frequency `
   -Timeout $pingTest.Timeout -RetryEnabled:$pingTest.RetryEnabled -Enabled:$pingTest.Enabled `
   -RequestParseDependent:($pingTestRequest.ParseDependentRequests -eq [bool]::TrueString);
   

   새로운 표준 테스트에는 기본적으로 경고 규칙이 없으므로 노이즈가 많은 경고가 만들어지지 않습니다. URL ping 테스트는 변경되지 않으므로 계속해서 경고를 받을 수 있습니다.

5. 새 표준 테스트의 기능의 유효성을 검사한 다음 대신 표준 테스트를 참조하도록 URL ping 테스트를 참조하는 경고 규칙을 업데이트합니다.

6. URL ping 테스트를 사용하지 않도록 설정하거나 삭제합니다. Azure PowerShell을 사용하여 이 작업을 수행하려면 다음 명령을 사용하면 됩니다.

   Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
   

방화벽 후방에서 테스트

방화벽 뒤의 엔드포인트 가용성을 보장하려면 공용 가용성 테스트를 사용하도록 설정하거나 연결이 끊겼거나 수신이 없는 시나리오에서 가용성 테스트를 실행합니다.

공용 가용성 테스트 지원

내부 웹 사이트에 공용 DNS(Domain Name System) 레코드가 있는지 확인합니다. DNS를 확인할 수 없으면 가용성 테스트가 실패합니다. 자세한 내용은 내부 애플리케이션을 위한 사용자 지정 도메인 이름 만들기를 참조하세요.

트래픽 인증

표준 테스트에서 사용자 지정 헤더를 설정하여 트래픽의 유효성을 검사합니다 .

1. 공백이 없는 영숫자 문자열을 만들어 이 가용성 테스트(예: MyAppAvailabilityTest)를 식별합니다. 이제부터 이 문자열을 가용성 테스트 문자열 식별자라고 합니다.

2. 가용성 테스트를 만들거나 업데이트할 때 표준 테스트 정보 섹션 아래에 값이 ApplicationInsightsAvailability:<your availability test string identifier>인 사용자 지정 헤더 X-Customer-InstanceId를 추가합니다.

   

3. 서비스에서 수신 트래픽에 이전 단계에서 정의한 헤더와 값이 포함되어 있는지 확인합니다.

또는 가용성 테스트 문자열 식별자를 쿼리 매개 변수로 설정합니다.

예: https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your availability test string identifier>

가용성 테스트에서 들어오는 요청을 허용하도록 방화벽 구성

개별 IP를 권한 부여하거나 최신 IP 목록을 유지하지 않고 Azure 서비스 사용하도록 설정을 간소화하려면 서비스 태그를 사용합니다. Azure Firewall 및 네트워크 보안 그룹 전체에 이러한 태그를 적용하면 가용성 테스트 서비스가 엔드포인트에 액세스할 수 있습니다. 서비스 태그 ApplicationInsightsAvailability는 모든 가용성 테스트에 적용됩니다.

1. Azure 네트워크 보안 그룹을 사용하는 경우 네트워크 보안 그룹 리소스로 이동하고 설정 아래에서 인바운드 보안 규칙 환경을 연 다음 추가를 선택합니다.

2. 그런 다음 서비스 태그를 원본으로 선택하고 ApplicationInsightsAvailability를 원본 서비스 태그로 선택합니다. 서비스 태그에서 들어오는 트래픽에 대한 포트 80(http) 및 443(https) 열기를 사용합니다.

엔드포인트가 Azure 외부에 있거나 서비스 태그를 선택할 수 없는 경우 액세스를 관리하려면 웹 테스트 에이전트의 IP 주소를 허용 목록에 추가합니다. PowerShell, Azure CLI 또는 서비스 태그 API를 통한 REST 호출을 사용하여 IP 범위를 쿼리할 수 있습니다. 현재 서비스 태그와 해당 IP 세부 정보의 전체 목록을 보려면 JSON 파일을 다운로드합니다.

1. 네트워크 보안 그룹 리소스의 설정 아래에서 인바운드 보안 규칙 환경을 연 다음, 추가를 선택합니다.

2. 다음으로, IP 주소를 원본으로 선택합니다. 그런 다음 원본 IP 주소/CIRD 범위에 쉼표로 구분된 목록으로 IP 주소를 추가합니다.

연결 끊김 또는 수신 없음 시나리오

1. Azure Private Link를 사용하여 Application Insights 리소스를 내부 서비스 엔드포인트에 연결합니다.

2. 사용자 지정 코드를 작성하여 내부 서버 또는 엔드포인트를 주기적으로 테스트합니다. 핵심 SDK 패키지의 TrackAvailability() API를 사용하여 결과를 Application Insights로 보냅니다.

지원되는 TLS 구성

동급 최고의 암호화를 제공하기 위해 모든 가용성 테스트에서는 선택한 암호화 메커니즘으로 TLS(전송 계층 보안) 1.2 및 1.3을 사용합니다. 또한 각 버전에서는 다음과 같은 암호 도구 모음 및 타원 곡선도 지원됩니다.

TLS 1.3은 현재 NorthCentralUS, CentralUS, EastUS, SouthCentralUS, WestUS 가용성 테스트 지역에서만 사용할 수 있습니다.

TLS 구성 사용 중단

TLS 1.0 및 TLS 1.1

TLS 1.0 및 TLS 1.1은 사용 중지됩니다.

TLS 1.2 및 TLS 1.3

문제 해결

가동 중지 시간 및 중단 통합 문서

이 섹션에서는 Application Insights 리소스 및 Azure 구독 전체에서 단일 창을 통해 웹 테스트에 대한 SLA(서비스 수준 계약)를 계산하고 보고하는 간단한 방법을 소개합니다. 가동 중지 시간 및 중단 보고서는 미리 작성된 강력한 쿼리 및 데이터 시각화를 제공하여 고객의 연결, 일반적인 애플리케이션 응답 시간 및 경험한 가동 중지 시간에 대한 이해도를 높여줍니다.

다음 두 가지 방법으로 Application Insights 리소스에서 SLA 통합 문서 템플릿에 액세스할 수 있습니다.

• 가용성 환경을 연 다음, 위쪽 탐색 모음에서 SLA 보고서를 선택합니다.

• 통합 문서 환경을 연 다음, 가동 중지 시간 및 중단을 템플릿을 선택합니다.

매개 변수 유연성

통합 문서에 설정된 매개 변수는 보고서의 나머지 부분에 영향을 줍니다.

• Subscriptions, App Insights Resources 및 Web Test: 이러한 매개 변수는 상위 수준 리소스 옵션을 결정합니다. Log Analytics 쿼리를 기반으로 하며 모든 보고서 쿼리에 사용됩니다.
• Failure Threshold 및 Outage Window: 이러한 매개 변수를 사용하여 서비스 중단에 대한 고유한 조건을 결정할 수 있습니다. 예를 들어 선택한 기간 동안 실패한 위치 카운터를 기반으로 하는 Application Insights 가용성 경고에 대한 기준이 있습니다. 일반적인 임계값은 5분 동안 3개의 위치입니다.
• Maintenance Period: 이 매개 변수를 사용하여 일반적인 유지 관리 빈도를 선택할 수 있습니다. Maintenance Window는 예제 유지 관리 기간에 대한 날짜/시간 선택기입니다. 식별된 기간 동안 발생하는 모든 데이터는 결과에서 무시됩니다.
• Availability Target %: 이 매개 변수는 대상 목표를 지정하고 사용자 지정 값을 사용합니다.

개요 페이지

개요 페이지에는 다음 사항에 대한 개략적인 정보가 포함되어 있습니다.

• 총 SLA(정의된 경우 유지 관리 기간 제외)
• 엔드투엔드 중단 인스턴스
• 애플리케이션 가동 중지 시간

중단 인스턴스는 중단 매개 변수에 따라 테스트가 실패하기 시작하는 순간부터 다시 성공적으로 통과할 때까지 결정됩니다. 테스트가 오전 8시에 실패하고 오전 10시에 다시 성공하는 경우 전체 데이터 기간이 동일한 중단으로 간주됩니다. 보고 기간 동안 발생한 가장 긴 중단을 조사할 수도 있습니다.

일부 테스트는 추가 조사를 위해 Application Insights 리소스에 다시 연결할 수 있습니다. 그러나 이는 작업 영역 기반 Application Insights 리소스에서만 가능합니다.

가동 중지 시간, 중단 및 실패

개요 페이지 옆에는 두 개의 탭이 더 있습니다.

• 중단 및 가동 중지 시간 탭에는 테스트별로 세분화된 총 중단 인스턴스 및 총 가동 중지 시간에 대한 정보가 있습니다.

• 위치별 실패 탭에는 잠재적인 문제 연결 영역을 식별하는 데 도움이 되는 실패한 테스트 위치의 지역 지도가 있습니다.

기타 기능

• 사용자 지정: 다른 Azure Monitor 통합 문서 와 마찬가지로 보고서를 편집하고 팀의 요구에 따라 쿼리 또는 시각화를 사용자 지정할 수 있습니다.

• Log Analytics: 쿼리는 모두 Log Analytics에서 실행되고 다른 보고서 또는 대시보드에서 사용할 수 있습니다. 매개 변수 제한을 제거하고 핵심 쿼리를 다시 사용합니다.

• 액세스 및 공유: 보고서를 팀 및 경영진과 공유하거나 대시보드에 고정하여 추가로 사용할 수 있습니다. 사용자는 실제 통합 문서가 저장된 Applications Insights 리소스에 대한 읽기 권한 및 액세스 권한이 있어야 합니다.

자주 묻는 질문

이 섹션에서는 일반적인 질문에 대한 답변을 제공합니다.

일반

인트라넷 서버에서 가용성 테스트를 실행할 수 있나요?

가용성 테스트는 전 세계에 분산된 현재 상태 지점에서 실행됩니다. 두 가지 해결 방법이 있습니다.

• 방화벽 문: 길고 변경 가능한 웹 테스트 에이전트 목록에서 서버에 대한 요청을 허용합니다.
• 사용자 지정 코드: 인트라넷 내부에서 서버에 주기적으로 요청을 보내는 코드를 직접 작성합니다. 이러한 목적으로 Visual Studio 웹 테스트를 실행할 수 있습니다. 테스터는 TrackAvailability() API를 사용하여 결과를 Application Insights에 보낼 수 있습니다.

가용성 테스트를 위한 사용자 에이전트 문자열은 무엇인가요?

사용자 에이전트 문자열은 Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0; AppInsights)입니다.

TLS 지원

이번 사용 중단은 내 웹 테스트 동작에 어떤 영향을 미치나요?

가용성 테스트는 지원되는 각 웹 테스트 위치에서 분산 클라이언트 역할을 합니다. 웹 테스트가 실행될 때마다 가용성 테스트 서비스는 웹 테스트 구성에 정의된 원격 엔드포인트에 연결을 시도합니다. 현재 지원되는 모든 TLS 구성이 포함된 TLS 클라이언트 Hello 메시지가 전송됩니다. 원격 엔드포인트가 가용성 테스트 클라이언트와 공통 TLS 구성을 공유하는 경우 TLS 핸드셰이크가 성공합니다. 그렇지 않으면 TLS 핸드셰이크 실패로 인해 웹 테스트가 실패합니다.

내 웹 테스트가 영향을 받지 않도록 하려면 어떻게 해야 하나요?

영향을 방지하려면 웹 테스트와 상호 작용하는 각 원격 엔드포인트(종속 요청 포함)가 가용성 테스트와 동일한 프로토콜 버전, 암호 도구 모음 및 타원 곡선의 조합을 하나 이상 지원해야 합니다. 원격 엔드포인트가 필요한 TLS 구성을 지원하지 않는 경우 위에서 언급한 사용 중단 후 TLS 구성의 일부 조합을 지원하도록 업데이트해야 합니다. 이러한 엔드포인트는 웹 테스트의 트랜잭션 세부 정보를 확인하여 발견할 수 있습니다(이상적으로는 성공적인 웹 테스트 실행을 위해).

원격 엔드포인트가 지원하는 TLS 구성을 어떻게 유효성 검사하나요?

엔드포인트가 지원하는 TLS 구성을 테스트하는 데 사용할 수 있는 여러 도구가 있습니다. 한 가지 방법은 이 페이지에 자세히 설명된 예를 따르는 것입니다. 공용 인터넷을 통해 원격 엔드포인트를 사용할 수 없는 경우 엔드포인트 호출에 액세스할 수 있는 컴퓨터에서 원격 엔드포인트에서 지원되는 TLS 구성의 유효성을 검사해야 합니다.

2025년 5월 1일 이후에는 영향을 받은 테스트에 대한 웹 테스트 동작은 어떻게 되나요?

이 사용 중단의 영향을 받는 모든 TLS 핸드셰이크 실패에 나타나는 예외 형식은 없습니다. 그러나 웹 테스트가 실패하기 시작하는 가장 일반적인 예외는 The request was aborted: Couldn't create SSL/TLS secure channel입니다. 또한 잠재적으로 영향을 받은 웹 테스트 결과에 대한 TLS 전송 문제 해결 단계에서 TLS 관련 오류를 확인할 수 있습니다.

내 웹 테스트에서 현재 사용 중인 TLS 구성을 볼 수 있나요?

웹 테스트 실행 중에 협상된 TLS 구성은 볼 수 없습니다. 원격 엔드포인트가 가용성 테스트를 통해 공통 TLS 구성을 지원하는 한, 사용 중단 후에도 아무런 영향이 나타나지 않습니다.

가용성 테스트 서비스에서 더 이상 사용되지 않는 구성 요소는 어떤 구성 요소에 영향을 미치나요?

이 문서에 자세히 설명된 TLS 사용 중단은 2025년 5월 1일 이후에 가용성 테스트 웹 테스트 실행 동작에만 영향을 줍니다. CRUD 작업을 위한 가용성 테스트 서비스와의 상호 작용에 대한 자세한 내용은 Azure Resource Manager TLS 지원을 참조하세요. 이 리소스는 TLS 지원 및 사용 중단 일정에 대한 자세한 내용을 제공합니다.

TLS 지원은 어디서 가져올 수 있나요?

레거시 TLS 문제에 대한 일반적인 질문은 TLS 문제 해결을 참조하세요.

다음 단계

• 문제 해결
• 웹 테스트 Azure Resource Manager 템플릿
• 웹 테스트 REST API