Application Insights 가용성 테스트

아티클
07/19/2024

웹앱이나 웹 사이트를 배포한 후 가용성과 응답성을 모니터링하도록 반복 테스트를 설정할 수 있습니다. Application Insights는 전 세계 지점에서 정기적인 간격으로 애플리케이션에 웹 요청을 보냅니다. 애플리케이션이 응답하지 않거나 응답이 너무 느린 경우 사용자에게 경고할 수 있습니다. Application Insights 리소스당 최대 100개의 가용성 테스트를 만들 수 있습니다.

가용성 테스트에는 테스트 중인 웹 사이트를 변경할 필요가 없으며 퍼블릭 인터넷에서 액세스할 수 있는 HTTP 또는 HTTPS 엔드포인트에 대해 작업합니다. 서비스에서 사용하는 REST API의 가용성을 테스트할 수도 있습니다.

참고 항목

가용성 테스트는 Azure 미사용 데이터 암호화 정책에 따라 암호화되어 저장됩니다.

가용성 테스트 유형

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

표준 테스트: 사용되지 않는 URL ping 테스트와 유사하게 단일 요청을 전송하여 웹 사이트의 가용성을 확인하는 가용성 테스트 유형입니다. 엔드포인트가 응답하는지 확인하고 성능을 측정하는 것 외에도 표준 테스트에는 TLS/SSL 인증서 유효성 검사, 자동 관리 수명 검사, HTTP 요청 동사(예: GET, HEAD 및 POST), 사용자 지정 헤더, HTTP 요청과 연결된 사용자 지정 데이터도 포함됩니다.
사용자 지정 TrackAvailability 테스트: 가용성 테스트를 실행할 사용자 지정 애플리케이션을 만들기로 결정한 경우 TrackAvailability() 메서드를 사용하여 결과를 Application Insights에 보낼 수 있습니다.
(사용되지 않음) 다단계 웹 테스트: 이 웹 요청 시퀀스 기록을 재생하여 더 복잡한 시나리오를 테스트할 수 있습니다. 다단계 웹 테스트는 Visual Studio Enterprise에서 만들고 포털에 업로드하여 실행할 수 있습니다.
(사용되지 않음) URL ping 테스트: Azure Portal에서 이 테스트를 만들어 엔드포인트가 응답하는지 확인하고 해당 응답과 관련된 성능을 측정할 수 있습니다. 종속 요청 구문 분석, 재시도 허용과 같은 고급 기능과 결합된 사용자 지정 성공 조건도 설정할 수 있습니다.

Important

두 가지 가용성 테스트 사용 중지가 예정되어 있습니다.

다단계 웹 테스트: 2024년 8월 31일 Application Insights의 다단계 웹 테스트가 사용 중지됩니다. 이러한 테스트의 사용자는 사용 중지 날짜 전에 대체 가용성 테스트로 전환하는 것이 좋습니다. 이 날짜 이후에는 기본 인프라를 중단하므로 남은 다단계 테스트도 중단됩니다.
URL ping 테스트: 2026년 9월 30일에 Application Insights의 URL ping 테스트는 사용 중지될 예정입니다. 기존 URL ping 테스트는 리소스에서 제거될 것입니다. 표준 테스트에 대한 가격 책정을 검토하고 2026년 9월 30일 이전에 사용하도록 전환하여 Application Insights 리소스에서 단일 단계 가용성 테스트를 계속 실행할 수 있는지 확인합니다.

팁

현재 URL ping 테스트와 같은 다른 가용성 테스트를 사용하는 경우 표준 테스트를 다른 테스트와 함께 추가할 수 있습니다. 다른 테스트 중 하나 대신 표준 테스트를 사용하려면 표준 테스트를 추가하고 이전 테스트를 삭제합니다.

필수 조건

작업 영역 기반 Application Insights 리소스

시작하기

Application Insights 리소스로 이동하고 가용성 창을 선택합니다.
표준 테스트 추가를 선택합니다.

다음 표에 설명된 테스트 이름, URL 및 기타 설정을 입력합니다. 그런 다음 만들기를 선택합니다.

설정	설명
URL	URL은 테스트하려는 웹 페이지일 수 있지만 공용 인터넷에서 볼 수 있어야 합니다. URL에 쿼리 문자열을 포함할 수 있습니다. 따라서 데이터베이스 사용 등을 연습해 볼 수 있습니다. URL이 리디렉션으로 확인되면 최대 10개의 리디렉션을 따릅니다.
종속 요청 구문 분석	테스트에서 테스트 대상 웹 페이지의 일부인 이미지, 스크립트, 스타일 파일 및 기타 파일을 요청합니다. 기록된 응답 시간에는 이러한 파일을 가져오는 데 걸리는 시간이 포함됩니다. 전체 테스트의 시간 제한 내에서 이러한 모든 리소스를 성공적으로 다운로드할 수 없는 경우 테스트에 실패합니다. 옵션을 선택하지 않으면 테스트는 지정한 URL에서만 파일을 요청합니다. 이 옵션을 사용하면 더 엄격한 검사를 실시할 수 있습니다. 수동으로 사이트를 검색할 때 눈에 띄지 않는 경우에는 테스트가 실패할 수 있습니다. 종속 요청은 최대 15개까지만 구문 분석합니다.
재시도 사용	테스트에 실패하면 잠시 후에 다시 시도합니다. 연속 된 세 번의 시도가 실패하는 경우에 실패가 보고됩니다. 후속 테스트는 일반적인 테스트 빈도로 수행됩니다. 다음 성공까지 다시 시도는 일시적으로 중단됩니다. 이 규칙은 각 테스트 위치에서 독립적으로 적용됩니다. 이 옵션을 권장합니다. 평균 실패의 약 80%는 다시 시도에서 사라집니다.
SSL 인증서 유효성 검사	웹 사이트에서 SSL 인증서를 확인하여 올바르게 설치되고, 유효하고, 신뢰할 수 있으며, 사용자에게 오류를 제공하지 않는지 확인할 수 있습니다.
자동 관리 수명 검사	이 설정을 사용하면 SSL 인증서가 만료되기 전에 설정된 기간을 정의할 수 있습니다. 만료되면 테스트가 실패합니다.
테스트 빈도	각 테스트 위치에서 테스트를 실행하는 빈도를 설정합니다. 5분에 5번의 테스트를 하는 기본 빈도로 사이트를 평균 1분마다 테스트합니다.
테스트 위치	서버는 이러한 위치에서 URL로 웹 요청을 보냅니다. 웹 사이트 문제를 네트워크 문제와 구분할 수 있도록 적어도 5개 이상의 테스트 위치를 권장합니다. 최대 16 개의 위치를 선택할 수 있습니다.
사용자 지정 헤더	운영 매개 변수를 정의하는 키 값 쌍
HTTP 요청 동사	요청으로 수행하려는 작업을 나타냅니다.
요청 본문	HTTP 요청과 연결된 사용자 지정 데이터 사용자 고유의 파일을 업로드하거나, 콘텐츠를 입력하거나, 이 기능을 비활성화할 수 있습니다.

성공 기준

설정	설명
테스트 시간 제한	느린 응답에 대한 알림을 받으려면 이 값을 감소시킵니다. 해당 기간 내에 사이트에서 응답을 받지 못한 경우 테스트는 실패로 계산됩니다. 종속 요청 구문 분석을 선택한 경우 모든 이미지, 스타일 파일, 스크립트 및 다른 종속된 리소스도 해당 기간 내에 받아야 합니다.
HTTP 응답	성공으로 계산되어 반환된 상태 코드입니다. 숫자 200은 일반적인 웹 페이지가 반환되었음을 나타내는 코드입니다.
콘텐츠 일치	“Welcome!”과 같이 문자열에 대한 정확한 대/소문자 구분 일치가 모든 응답에서 발생하는지 테스트합니다. 와일드카드 없는 일반 문자열이어야 합니다. 페이지 내용이 변경되면 업데이트해야 할 수 있습니다. 콘텐츠 일치에서는 영어 문자만 지원됩니다.

Important

TrackAvailability()를 사용하려면 개발자가 잠재적으로 복잡한 사용자 지정 코드를 작성하고 유지 관리하는 데 투자해야 합니다.

가능한 경우 투자, 유지 관리가 필요 없고 필수 조건이 거의 없으므로 표준 테스트를 항상 사용해야 합니다.

필수 조건

작업 영역 기반 Application Insights 리소스
Azure Functions에서 함수 앱의 소스 코드에 액세스
특정 비즈니스 요구 사항에 맞게 조정된 TrackAvailability()에 대한 사용자 지정 코드를 작성할 수 있는 개발자 전문 지식

기본 코드 샘플

참고 항목

이 예제는 Azure Function 내에서 TrackAvailability() API 호출이 작동하는 방식에 대한 메커니즘을 보여 주기 위해서만 설계되었습니다. 이 예제를 완전한 기능 가용성 테스트로 전환하는 데 필요한 기본 HTTP 테스트 코드 또는 비즈니스 논리를 작성하는 방법은 표시되지 않습니다.

기본적으로 이 예제를 진행하는 경우 기본 가용성 HTTP GET 테스트를 만듭니다. 이러한 지침을 따르려면 전용 계획을 사용하여 App Service 편집기에서 코드 편집을 허용해야 합니다.

타이머 트리거 함수 만들기

Azure Functions 리소스를 만듭니다.
- Application Insights 리소스가 이미 있는 경우:
  
  기본적으로 Azure Functions는 Application Insights 리소스를 만듭니다. 이전에 만든 리소스를 사용하려면 만드는 동안 해당 리소스를 지정해야 합니다.
  
  다음 수정과 함께 Azure Functions 리소스 만들기 방법에 대한 지침을 따릅니다.
  
  모니터링 탭에서 Application Insights 드롭다운 상자를 선택한 다음, 리소스의 이름을 입력하거나 선택합니다.
- 타이머 트리거 함수에서 사용할 Application Insights 리소스가 아직 생성되지 않은 경우:
  
  기본적으로 Azure Functions 애플리케이션을 만들 때 Application Insights 리소스를 만들게 됩니다. Azure Functions 리소스 만들기 방법에 대한 지침을 따릅니다.
참고 항목

소비, 프리미엄 또는 App Service 요금제에서 함수를 호스트할 수 있습니다. 가상 네트워크 뒤에서 테스트하거나 비퍼블릭 엔드포인트를 테스트하는 경우 소비 플랜 대신 프리미엄 플랜을 사용해야 합니다. 호스팅 탭에서 플랜을 선택합니다. 함수 앱을 만들 때 최신 .NET 버전이 선택되어 있는지 확인하세요.
타이머 트리거 함수를 만듭니다.
1. 함수 앱에서 함수 탭을 선택합니다.
2. 추가를 선택합니다. 함수 추가 창에서 다음 구성을 선택합니다.
  - 개발 환경: 포털에서 개발
  - 템플릿 선택: 타이머 트리거
3. 추가를 선택하여 타이머 트리거 함수를 만듭니다.

App Service 편집기에서 코드 추가 및 편집

배포된 함수 앱으로 이동하고 개발 도구에서 App Service 편집기 탭을 선택합니다.

새 파일을 만들려면 타이머 트리거 함수(예: TimerTrigger1)를 마우스 오른쪽 단추로 클릭하고 새 파일을 선택합니다. 그런 다음, 파일 이름을 입력하고 Enter 키를 선택합니다.

function.proj라는 파일을 만들고 다음 코드를 붙여넣습니다.

<Project Sdk="Microsoft.NET.Sdk"> 
    <PropertyGroup> 
        <TargetFramework>netstandard2.0</TargetFramework> 
    </PropertyGroup> 
    <ItemGroup> 
        <PackageReference Include="Microsoft.ApplicationInsights" Version="2.15.0" /> <!-- Ensure you’re using the latest version --> 
    </ItemGroup> 
</Project>

runAvailabilityTest.csx라는 새 파일을 만들고 다음 코드를 붙여넣습니다.

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 
    } 
}

REGION_NAME 환경 변수를 유효한 Azure 가용성 위치로 정의합니다.

Azure CLI에서 다음 명령을 실행하여 사용 가능한 지역을 나열합니다.
```
az account list-locations -o table
```

다음 코드를 run.csx 파일에 복사합니다. (기존 코드를 바꿉니다.)

#load "runAvailabilityTest.csx" 

using System; 

using System.Diagnostics; 

using Microsoft.ApplicationInsights; 

using Microsoft.ApplicationInsights.Channel; 

using Microsoft.ApplicationInsights.DataContracts; 

using Microsoft.ApplicationInsights.Extensibility; 

private static TelemetryClient telemetryClient; 

// ============================================================= 

// ****************** DO NOT MODIFY THIS FILE ****************** 

// Business logic must be implemented in RunAvailabilityTestAsync function in runAvailabilityTest.csx 

// If this file does not exist, please add it first 

// ============================================================= 

public async static Task Run(TimerInfo myTimer, ILogger log, ExecutionContext executionContext) 

{ 
    if (telemetryClient == null) 
    { 
        // Initializing a telemetry configuration for Application Insights based on connection string 

        var telemetryConfiguration = new TelemetryConfiguration(); 
        telemetryConfiguration.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING"); 
        telemetryConfiguration.TelemetryChannel = new InMemoryChannel(); 
        telemetryClient = new TelemetryClient(telemetryConfiguration); 
    } 

    string testName = executionContext.FunctionName; 
    string location = Environment.GetEnvironmentVariable("REGION_NAME"); 
    var availability = new AvailabilityTelemetry 
    { 
        Name = testName, 

        RunLocation = location, 

        Success = false, 
    }; 

    availability.Context.Operation.ParentId = Activity.Current.SpanId.ToString(); 
    availability.Context.Operation.Id = Activity.Current.RootId; 
    var stopwatch = new Stopwatch(); 
    stopwatch.Start(); 

    try 
    { 
        using (var activity = new Activity("AvailabilityContext")) 
        { 
            activity.Start(); 
            availability.Id = Activity.Current.SpanId.ToString(); 
            // Run business logic 
            await RunAvailabilityTestAsync(log); 
        } 
        availability.Success = true; 
    } 

    catch (Exception ex) 
    { 
        availability.Message = ex.Message; 
        throw; 
    } 

    finally 
    { 
        stopwatch.Stop(); 
        availability.Duration = stopwatch.Elapsed; 
        availability.Timestamp = DateTimeOffset.UtcNow; 
        telemetryClient.TrackAvailability(availability); 
        telemetryClient.Flush(); 
    } 
}

다단계 웹 테스트 코드 샘플

위와 동일한 지침을 따르고 대신 다음 코드를 runAvailabilityTest.csx 파일에 붙여넣습니다.

using System.Net.Http; 

public async static Task RunAvailabilityTestAsync(ILogger log) 
{ 
    using (var httpClient = new HttpClient()) 
    { 
        // TODO: Replace with your business logic 
        await httpClient.GetStringAsync("https://www.bing.com/"); 

        // TODO: Replace with your business logic for an additional monitored endpoint, and logic for additional steps as needed
        await httpClient.GetStringAsync("https://www.learn.microsoft.com/"); 
    } 
}

가용성 경고

설정	설명
근 실시간	거의 실시간 경고를 사용하는 것이 좋습니다. 이 유형의 경고 구성은 가용성 테스트를 만든 후에 수행됩니다.
경고 위치 임계값	최소 3/5 위치를 사용하는 것이 좋습니다. 경고 위치 임계값과 테스트 위치 수 사이의 최적 관계는 경고 위치 임계값 = 테스트 위치 수 - 2이고, 최소 테스트 위치 수는 5입니다.

위치 채우기 태그

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

Azure

표시 이름	채우기 이름
오스트레일리아 동부	emea-au-syd-edge
브라질 남부	latam-br-gru-edge
미국 중부	us-fl-mia-edge
동아시아	apac-hk-hkn-azr
미국 동부	us-va-ash-azr
프랑스 남부(이전 프랑스 중부)	emea-ch-zrh-edge
프랑스 중부	emea-fr-pra-edge
일본 동부	apac-jp-kaw-edge
북유럽	emea-gb-db3-azr
미국 중북부	us-il-ch1-azr
미국 중남부	us-tx-sn1-azr
동남아시아	apac-sg-sin-azr
영국 서부	emea-se-sto-edge
서유럽	emea-nl-ams-azr
미국 서부	us-ca-sjc-azr
영국 남부	emea-ru-msa-edge

Azure Government

표시 이름	채우기 이름
USGov 버지니아	usgov-va-azr
USGov 애리조나	usgov-phx-azr
USGov 텍사스	usgov-tx-azr
미국 국방부 동부	usgov-ddeast-azr
미국 국방부 중부	usgov-ddcentral-azr

21Vianet에서 운영하는 Microsoft Azure

표시 이름	채우기 이름
중국 동부	mc-cne-azr
중국 동부 2	mc-cne2-azr
중국 북부	mc-cnn-azr
중국 북부 2	mc-cnn2-azr

경고 사용

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

참고 항목

새로 통합된 경고를 사용하여 경고 규칙 심각도 및 작업 그룹이 포함된 알림 기본 설정은 경고 환경에서 구성되어야 합니다. 다음 단계 없이도 포털 내 알림을 받게 됩니다.

가용성 테스트를 저장한 후 세부 정보 탭에서 사용자가 만든 테스트 옆에 있는 줄임표를 선택합니다. 규칙 열기(경고) 페이지를 선택합니다.
심각도 수준, 규칙 설명, 이 경고 규칙에 대해 사용하려는 알림 기본 설정을 보유한 작업 그룹을 설정합니다.

경고 조건

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

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

예를 들어 유지 관리 중에 웹 사이트가 짧은 기간 동안만 다운된 경우 알림을 받지 못할 수 있습니다. 평가 빈도를 예상 가동 중지 시간보다 높은 값(최대 15분)으로 변경할 수 있습니다. 또한 경고 위치 임계값을 증가시켜 특정 수의 지역에서 웹 사이트가 다운된 경우에만 경고를 트리거할 수 있습니다. 예약된 가동 중지 시간이 긴 경우 경고 규칙을 일시적으로 비활성화하거나 사용자 지정 규칙을 만듭니다. 이렇게 하면 가동 중지 시간을 설명할 수 있는 더 많은 옵션이 제공됩니다.

경고 조건 변경

위치 임계값, 집계 기간, 테스트 빈도를 변경하려면 경고 규칙의 편집 페이지에서 조건을 선택하여 "신호 논리 구성" 창을 엽니다.

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

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

사용자 지정 경고 규칙은 집계 기간(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를 사용하여 데이터를 쿼리하는 방법을 설명합니다. 가용성 테스트 결과는 선 보기와 산점도 보기 모두를 사용하여 시각화할 수 있습니다.

가용성 확인

먼저 Application Insights 리소스의 가용성 탭에서 그래프를 검토합니다.

표준 테스트
TrackAvailability

새로 고침 단추가 강조 표시된 가용성 페이지를 보여 주는 스크린샷.

산점도 보기에서는 진단 테스트 단계의 세부 정보가 포함된 테스트 결과 샘플을 보여줍니다. 테스트 엔진은 실패한 테스트에 대한 진단 정보를 저장합니다. 성공한 테스트의 경우 실행의 하위 집합에 대한 진단 정보가 저장됩니다. 녹색/빨간색 점 위로 마우스를 이동하면 테스트, 테스트 이름 및 위치를 볼 수 있습니다.

꺾은선형 보기를 보여 주는 스크린샷.

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

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

샘플 가용성 테스트 선택을 보여 주는 스크린샷

테스트 검사 및 편집

테스트를 편집하거나 일시적으로 비활성화하거나 삭제하려면 테스트 이름 옆에 있는 줄임표를 선택합니다. 구성 변경 내용이 모든 테스트 에이전트로 전파되는 데 최대 20분이 걸릴 수 있습니다.

테스트 세부 정보 보기를 보여 주는 스크린샷. 웹 테스트를 편집하고 사용하지 않도록 설정합니다.

서비스에 대한 유지 관리를 수행하는 동안 가용성 테스트 또는 관련된 경고 규칙을 사용하지 않도록 설정할 수 있습니다.

오류가 표시되는 경우

빨간 점을 클릭합니다.

엔드투엔드 트랜잭션 세부 정보 탭을 보여주는 스크린샷

가용성 테스트 결과에서 모든 구성 요소에서 트랜잭션 세부 정보를 볼 수 있습니다. 다음을 수행할 수 있습니다.

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

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

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

서버 쪽 진단을 보여 주는 스크린샷.

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

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

Log Analytics에서 쿼리

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

마이그레이션 가용성 테스트

이 문서에서는 클래식 URL ping 테스트에서 최신적이고 효율적인 표준 테스트로 마이그레이션하는 과정을 안내합니다.

원활한 전환을 보장하고 애플리케이션에 최신 모니터링 기능을 제공하기 위해 명확한 단계별 지침을 제공하여 이 프로세스를 간소화합니다.

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

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

Important

표준 테스트 실행에는 비용이 발생합니다. 표준 테스트를 만들면 테스트 실행에 대한 요금이 청구됩니다. 이 프로세스를 시작하기 전에 Azure Monitor 가격 책정을 참조하세요.

필수 조건

Application Insights 내의 모든 URL ping 테스트
Azure PowerShell 액세스

시작하기

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

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

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

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

다음 명령은 URL ping 테스트와 동일한 논리를 사용하여 표준 테스트를 만듭니다.

참고 항목

다음 명령은 URL ping 테스트에 사용되는 HTTP 및 HTTPS 엔드포인트 모두에서 작동합니다.

$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 테스트는 변경되지 않으므로 계속해서 경고를 받을 수 있습니다.
새 표준 테스트의 기능의 유효성을 검사한 후에는 URL ping 테스트를 참조하는 경고 규칙을 업데이트하여 대신 표준 테스트를 참조하세요. 그런 다음 URL ping 테스트를 사용하지 않도록 설정하거나 삭제합니다.
Azure PowerShell을 사용하여 URL ping 테스트를 삭제하려면 다음 명령을 사용할 수 있습니다.
```
Remove-AzApplicationInsightsWebTest -ResourceGroupName $resourceGroup -Name $pingTestName;
```

방화벽 후방에서 테스트

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

공용 가용성 테스트 지원

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

Warning

가용성 테스트 서비스에서 사용되는 IP 주소는 공유되며 방화벽으로 보호되는 서비스 엔드포인트를 다른 테스트에 노출할 수 있습니다. IP 주소 필터링만으로는 서비스 트래픽을 보호할 수 없으므로 웹 요청의 원본을 확인하기 위해 추가 사용자 지정 헤더를 추가하는 것이 좋습니다. 자세한 내용은 가상 네트워크 서비스 태그를 참조하세요.

트래픽 인증

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

가용성 테스트에서 트래픽을 식별하려면 토큰 또는 GUID를 생성합니다.
가용성 테스트를 만들거나 업데이트할 때 "표준 테스트 정보" 섹션 아래에 값이 ApplicationInsightsAvailability:<GUID generated in step 1>인 사용자 지정 헤더 "X-Customer-InstanceId"를 추가합니다.
서비스에서 수신 트래픽에 이전 단계에서 정의한 헤더와 값이 포함되어 있는지 확인합니다.

또는 토큰을 쿼리 매개 변수로 설정합니다. 예들 들어 https://yourtestendpoint/?x-customer-instanceid=applicationinsightsavailability:<your guid>입니다.

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

참고 항목

이 예는 네트워크 보안 그룹 서비스 태그 사용과 관련된 것입니다. 많은 Azure 서비스는 각각 다른 구성 단계가 필요한 서비스 태그를 허용합니다.

개별 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 주소를 추가합니다.

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

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

지원되는 TLS 구성

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

참고 항목

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

TLS 1.2

암호 그룹

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

타원형 곡선

NistP384
NistP256

TLS 1.3

암호 그룹

TLS_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA256

타원형 곡선

NistP384
NistP256

TLS 구성 사용 중단

Warning

2024년 10월 31일에 Azure 전체 레거시 TLS 사용 중단에 따라 TLS 1.0/1.1 프로토콜 버전 및 아래에 나열된 TLS 1.2/1.3 레거시 암호화 그룹 및 타원 곡선이 Application Insights 가용성 테스트에서 사용 중지됩니다.

TLS 1.0 및 TLS 1.1

프로토콜 버전은 더 이상 지원되지 않습니다.

TLS 1.2

암호 그룹

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA

타원형 곡선

curve25519

TLS 1.3

타원형 곡선

curve25519

문제 해결

Warning

최근에 가용성 테스트에서 TLS 1.3을 사용하도록 설정했습니다. 결과적으로 새 오류 메시지가 표시되는 경우 TLS 1.3을 사용하도록 설정한 상태로 Windows Server 2022에서 실행되는 클라이언트가 엔드포인트에 연결할 수 있는지 확인하세요. 이 작업을 수행할 수 없는 경우 가용성 테스트가 이전 TLS 버전으로 대체되도록 엔드포인트에서 TLS 1.3을 일시적으로 사용하지 않도록 설정하는 것이 좋습니다.
자세한 내용은 문제 해결 문서를 참조하세요. 전용 문제 해결 문서를 참조하세요.

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

이 문서에서는 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 구성의 유효성을 검사해야 합니다.

참고 항목

웹 서버에서 필요한 TLS 구성을 사용하도록 설정하는 단계는 프로세스를 알 수 없는 경우 웹 서버가 실행되는 호스팅 플랫폼을 소유한 팀에 문의하는 것이 가장 좋습니다.

2024년 10월 31일 이후에는 영향을 받는 테스트에 대한 웹 테스트 동작이 어떻게 되나요?

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

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

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

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

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

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

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

다음을 통해 공유

Application Insights 가용성 테스트

가용성 테스트 유형

가용성 집합 만들기

필수 조건

시작하기

성공 기준

가용성 경고

위치 채우기 태그

Azure

Azure Government

21Vianet에서 운영하는 Microsoft Azure

경고 사용

경고 조건

경고 조건 변경

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

경고 자동화

가용성 테스트 결과 참조

가용성 확인

테스트 검사 및 편집

오류가 표시되는 경우

Log Analytics에서 쿼리

마이그레이션 가용성 테스트

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

필수 조건

시작하기

방화벽 후방에서 테스트

공용 가용성 테스트 지원

트래픽 인증

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

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

지원되는 TLS 구성

TLS 1.2

TLS 1.3

TLS 구성 사용 중단

TLS 1.0 및 TLS 1.1

TLS 1.2

TLS 1.3

문제 해결

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

매개 변수 유연성

개요 페이지

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

보고서 편집

Log Analytics

액세스 및 공유

자주 묻는 질문

일반

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

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

TLS 지원

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

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

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

2024년 10월 31일 이후에는 영향을 받는 테스트에 대한 웹 테스트 동작이 어떻게 되나요?

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

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

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

다음 단계

피드백

피드백

추가 리소스