개요

HTTP 테스트를 사용하면 애플리케이션의 API 엔드포인트에 HTTP 요청을 보내 응답 및 전체 응답 시간, 예상 상태 코드, 헤더 또는 본문 콘텐츠와 같은 응답과 정의된 조건을 검증할 수 있습니다.

HTTP 테스트는 네트워크 외부 또는 내부에서 테스트를 실행하려는 사용자의 선호도에 따라 관리형 위치와 프라이빗 위치 모두에서 실행될 수 있습니다. HTTP 테스트는 일정에 따라, 온디맨드로 또는 CI/CD 파이프라인 내에서 직접 실행할 수 있습니다.

구성

다음 옵션 중 하나를 사용하여 테스트를 생성할 수 있습니다.

• 템플릿에서 테스트 생성하기:

  1. 사전에 채워진 템플릿 중 하나에 마우스를 올리고 템플릿 보기를 클릭합니다. 테스트 세부 정보, 요청 세부 정보, 어설션, 알림 조건 및 모니터링 설정이 포함된, 사전에 채워진 설정 정보가 표시되는 사이드 패널이 열립니다.

  2. +Create Test를 클릭하여 Define Request 페이지를 열고, 사전에 채워진 구성 옵션을 검토하고 편집할 수 있습니다. 표시되는 필드는 테스트 처음 생성 시 제공되는 필드와 동일합니다.

  3. Save Details를 클릭하여 API 테스트를 제출합니다.
     
     

• 처음부터 테스트 빌드하기:

  1. 처음부터 테스트를 빌드하려면 + Start from scratch 템플릿을 클릭한 다음 HTTP요청 유형을 선택하고 쿼리할 URL을 지정합니다. 사용 가능한 방법은 GET, POST, PATCH, PUT, HEAD, DELETE 및 OPTIONS입니다. http 및 https URL이 둘 다 지원됩니다.

     자세한 옵션은 고급 옵션을 참조하세요.

  2. Name your HTTP test.

  3. Add Environment Tags as well as any other tag to your HTTP test. You can then use these tags to filter through your Synthetic tests on the Synthetic Monitoring & Continuous Testing page.

  4. Click Send to try out the request configuration. A response preview is displayed on the right side of your screen.
     
     

  5. Click Create Test to submit your API test.

스니펫

When setting up a new Synthetic Monitoring API test, use snippets to automatically fill in basic auth, performance, and regions, rather than selecting these options manually. The following snippets are available:

• Basic Auth: Automatically test your APIs using pre-populated basic auth headers, JavaScript, bearer token, and API/app key auth variables.

• Performance: Automatically configure a test with the shortest frequency (one minute), perform a gRPC health check, and test for overall response time latency with a breakdown of network timing.

• Regions: Automatically test your API endpoint against a location in each of the three primary geographic regions (AMER, APAC and EMEA).
  
  

  

고급 옵션

• HTTP 버전: HTTP/1.1 only, HTTP/2 only 또는 HTTP/2 fallback to HTTP/1.1을(를) 선택합니다.
• 리디렉션 따르기: 선택하면 요청을 수행할 때 HTTP 테스트에서 최대 10개의 리디렉션을 팔로우합니다.
• 서버 인증서 오류 무시하기: 선택하면 SSL 인증서를 확인할 때 오류가 발생하더라도 HTTP 테스트가 연결을 계속합니다.
• 타임아웃: 테스트 시간 초과로 간주하기까지의 시간을 초단위로 지정합니다.
• 요청 헤더: HTTP 요청에 추가할 헤더를 정의합니다. 기본 헤더(예: user-agent 헤더)를 재정의할 수도 있습니다.
• 쿠키: HTTP 요청에 추가할 쿠키를 정의합니다. <COOKIE_NAME1>=<COOKIE_VALUE1>; <COOKIE_NAME2>=<COOKIE_VALUE2> 형식을 사용하여 여러 개의 쿠키를 설정합니다.

• 클라이언트 인증서: 클라이언트 인증서(.crt) 및 연결된 개인 키(.key)를 PEM 형식으로 업로드하여 mTLS를 통해 인증합니다. 인증서를 변환하기 위해 openssl 라이브러리를 사용할 수 있습니다. 예를 들어 PKCS12 인증서를 PEM 형식의 개인 키 및 인증서로 변환합니다.

  openssl pkcs12 -in <CERT>.p12 -out <CERT_KEY>.key -nodes -nocerts
  openssl pkcs12 -in <CERT>.p12 -out <CERT>.cert -nokeys
  

• HTTP 기본 인증: HTTP 기본 인증 자격 증명을 추가합니다.

• Digest 인증: Digest 인증 자격 증명을 추가합니다.

• NTLM: NTLM 인증 자격 증명을 추가합니다. NTLMv2와 NTLMv1을 모두 지원합니다.

• AWS Signature v4: 액세스 키 ID와 시크릿 액세스 키를 입력합니다. Datadog은 요청에 대한 서명을 생성합니다. 이 옵션은 SigV4의 기본 구현을 사용합니다. Amazon S3와 같은 특정 서명은 기본적으로 지원되지 않습니다. Amazon S3 버킷에 대한 ‘단일 청크’ 전송 요청의 경우, 요청 본문의 SHA-256 해시값을 인코딩한 x-amz-content-sha256을(를) 헤더에 추가합니다(본문이 비어 있는 경우: x-amz-content-sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855).

• OAuth 2.0: 클라이언트 자격 증명 또는 리소스 소유자 비밀번호를 부여하고 액세스 토큰 URL을 입력합니다. 선택에 따라 클라이언트 ID와 시크릿, 또는 사용자 이름과 비밀번호를 입력합니다. 드롭다운 메뉴에서 API 토큰을 기본 인증 헤더로 전송하거나 본문에 클라이언트 자격 증명을 전송하는 옵션을 선택합니다. 필요시 대상, 리소스 및 범위와 같은 추가 정보를 제공할 수 있습니다(Resource Owner Password를 선택한 경우 클라이언트 ID 및 시크릿까지 제공).

• 인코딩 파라미터: 인코딩이 필요한 쿼리 파라미터의 이름과 값을 추가합니다.

• 본문 유형: HTTP 요청에 추가하려는 요청 본문 유형(application/json, application/octet-stream, application/x-www-form-urlencoded, multipart/form-data, text/html, text/plain, text/xml, GraphQL 또는 None)을 선택합니다.
• 요청 본문: HTTP 요청 본문의 내용을 추가합니다.
  • 요청 본문은 application/json, application/x-www-form-urlencoded, text/html, text/plain, text/xml, GraphQL에 대해 최대 50KB로 제한됩니다.
  • 요청 본문은 application/octet-stream에 대해 3MB의 파일 1개로 제한됩니다.
  • 요청 본문은 multipart/form-data에 대해 3MB의 파일 3개로 제한됩니다.

• 프록시 URL: HTTP 요청이 통과해야 하는 프록시의 URL을 지정합니다(http://<YOUR_USER>:<YOUR_PWD>@<YOUR_IP>:<YOUR_PORT>).
• 프록시 헤더: 프록시에 대한 HTTP 요청에 포함할 헤더를 추가합니다.

• 응답 본문을 저장하지 않음: 이 옵션을 선택하면 런타임에 응답 본문이 저장되지 않도록 하고 실패한 JavaScript 어설션의 오류 메시지를 잘라냅니다. 이렇게 하면 테스트 결과에 민감한 데이터가 표시되지 않게 할 수 있지만, 실패 시 문제 해결이 더 어려워질 수 있습니다. 전체 보안 권장 사항은 Synthetic Monitoring 데이터 보안을 참조하세요.

JavaScript를 사용하여 HTTP API 테스트용 변수를 정의하세요.

Windows 프라이빗 위치에서는 API 테스트에 대한 JavaScript 기능이 지원되지 않습니다.

어설션 정의

어설션은 예상되는 테스트 결과가 무엇인지 정의합니다. Test URL을 클릭하면 response time, status code, header content-type에 대한 기본 어설션이 응답을 기반으로 추가됩니다. 모니터링할 테스트에 대해 최소한 하나의 어설션을 정의해야 합니다.

유형	연산자	값 유형
본문	contains, does not contain, is, is not, matches, does not match, jsonpath, xpath	문자열 정규식
헤더	contains, does not contain, is, is not, matches, does not match	문자열 정규식
응답 시간	is less than	정수(ms)
상태 코드	is, is not, matches, does not match	정수 정규식

HTTP 테스트는 다음과 같은 content-encoding 헤더로 본문을 압축 해제할 수 있습니다. br, deflate, gzip, 및 identity

New Assertion을 클릭하거나 응답 미리보기를 직접 클릭하여 API 테스트당 최대 20개의 어설션을 생성할 수 있습니다.

어설션에서 OR 논리를 수행하려면 matches regex 비교기를 사용하여 (200|302)와 같은 여러 예상 값으로 정규식을 정의하세요. 예를 들어 서버가 200 또는 302 상태 코드로 응답하는 경우에만 HTTP 테스트가 성공하도록 설정할 수 있습니다. 상태 코드가 200 또는 302인 경우 status code 어설션이 성공합니다. OR 비교기를 사용하여 body 또는 header 어설션에 matches regex 논리를 추가할 수도 있습니다.

테스트에 응답 본문에 대한 어설션이 포함되어 있지 않으면 본문 페이로드가 삭제되고 Synthetics Worker가 설정한 제한 시간 내에서 요청에 대한 관련 응답 시간을 반환합니다.

응답 본문은 해당 내용에 대한 어설션을 추가하고 이러한 어설션이 실패한 경우에만 반환됩니다. 테스트에 응답 본문에 대한 어설션이 포함되어 있고 성공할 경우, 본문 페이로드가 삭제되고 응답 본문의 처음 50자만 표시됩니다.

테스트에 응답 본문에 대한 어설션이 포함되어 있고 시간 초과 제한에 도달할 경우, Assertions on the body/response cannot be run beyond this limit 오류가 나타납니다.

표준 응답 어설션이 유효성 요구 사항을 충족하지 않는 경우 JavaScript 어설션을 사용하세요. Synthetic Monitoring은 dd.expect(), dd.should 및 dd.assert()과 같은 유연한 어설션 스타일을 제공하는 Chai 어설션 라이브러리를 사용합니다.

JSON 응답을 처리할 때는 속성에 접근하기 전에 JSON.parse(dd.response.body)를 사용하여 응답 본문을 구문 분석하세요. JSON 데이터를 검증할 때는 모든 어설션 메서드(dd.assert(), dd.expect(), 및 dd.should)에 이 방식을 적용해야 합니다.

• Windows 프라이빗 위치에서는 API 테스트에 대한 JavaScript 기능이 지원되지 않습니다.
• 실패한 JavaScript 어설션의 오류 메시지에 민감한 데이터가 포함될 수 있는 경우, Advanced Options > Privacy에서 Do not save response body를 활성화하세요. 이렇게 하면 어설션 오류 메시지를 잘라낼 수 있습니다.

dd.assert() 사용

기존 방식의 어설션 구문에는 dd.assert()을 사용하세요.

예를 들어 status.code 필드가 여러 허용된 값 중 하나인지 검증하는 방법은 다음과 같습니다.

Copy

const response = JSON.parse(dd.response.body);
// Assert that the status code is 200, 210, 320, or 330
dd.assert.include([200, 210, 320, 330], response.status.code);

응답 예시:

{
  "status": {
    "code": 200,
    "message": "Success"
  }
}

이 어설션:

• JSON 응답 본문을 구문 분석합니다.
• status.code가 허용된 값의 배열(200, 210, 320 또는 330)에 포함되어 있는지 확인합니다.

이 경우 테스트는 통과합니다. status.code가 200이며, 이는 허용된 값 배열에 포함되어 있기 때문입니다.

assert.include()에 대한 자세한 내용은 Chai assert.include() 문서를 참조하세요.

dd.expect() 사용

중첩 속성 검증이 포함된 어설션을 수행하려면 dd.expect()를 사용하세요.

예를 들어 status.indicator 필드가 여러 예상 값 중 하나와 일치하는지 검증하는 방법은 다음과 같습니다.

Copy

const response = JSON.parse(dd.response.body);
const regex = /^(major|critical|minor|none)$/;

dd.expect(response)
  .to.have.nested.property('status.indicator')
  .that.matches(regex);

응답 예시:

{
  "status": {
    "indicator": "none"
  }
}

이 어설션:

• JSON 응답 본문을 구문 분석합니다.
• 중첩 속성 status.indicator가 존재하는지 검증합니다.
• 값이 정규식 패턴(다음 중 하나: major, critical, minor 또는 none)과 일치하는지 확인합니다.

정규식 /^(major|critical|minor|none)$/의 경우, 테스트는 통과합니다. status.indicator가 "none"이며, 이는 패턴과 일치하기 때문입니다.

정규식 /^(major|critical|minor)$/의 경우, 테스트는 실패합니다. "none"이 허용된 값에 포함되지 않기 때문입니다.

expect()에 대한 자세한 내용은 Chai expect() 문서를 참조하세요.

dd.should 사용

자연어 구문으로 어설션을 작성하려면 dd.should를 사용하세요.

예를 들어 status.indicator 필드가 존재하고 특정 값과 같음을 검증하는 방법은 다음과 같습니다.

Copy

const response = JSON.parse(dd.response.body);
response.status.should.exist();
const indicator = response.status.indicator;
indicator.should.equal('none');

응답 예시:

{
  "status": {
    "indicator": "none"
  }
}

이 어설션:

• JSON 응답 본문을 구문 분석합니다.
• status 속성이 존재하는지 확인합니다.
• 지표 값을 변수로 추출합니다.
• status.indicator가 "none"과 같은지 확인합니다.

테스트는 통과합니다. status가 존재하고 status.indicator가 "none"이기 때문입니다.

should()에 대한 자세한 내용은 Chai should() 문서를 참조하세요.

위치 선택

HTTP 테스트를 실행할 위치를 선택합니다. HTTP 테스트는 네트워크 외부 또는 내부에서 테스트를 실행하려는 사용자의 선호도에 따라 관리형 위치와 프라이빗 위치 모두에서 실행될 수 있습니다.

Datadog’s out-of-the-box managed locations allow you to test public-facing websites and endpoints from regions where your customers are located.

AWS:

GCP:

Azure:

The Datadog for Government site (US1-FED) uses the following managed location:

테스트 주기 지정

HTTP 테스트는 다음과 같이 실행할 수 있습니다.

• 일정에 따라 가장 중요한 엔드포인트가 사용자가 항상 액세스할 수 있도록 합니다. Datadog이 HTTP 테스트를 실행할 빈도를 선택합니다.
• CI/CD 파이프라인 내에서 결함이 있는 코드가 고객 경험에 영향을 미칠지에 대한 염려 없이 전송을 시작할 수 있습니다.
• 온디맨드로 실행하면 팀에 가장 적합한 시간에 테스트를 실행할 수 있습니다.

Define alert conditions

Set alert conditions to determine the circumstances under which you want a test to fail and trigger an alert.

Alerting rule

When you set the alert conditions to: An alert is triggered if any assertion fails for X minutes from any n of N locations, an alert is triggered only if these two conditions are true:

• At least one location was in failure (at least one assertion failed) during the last X minutes;
• At one moment during the last X minutes, at least n locations were in failure.

Fast retry

Your test can trigger retries X times after Y ms in case of a failed test result. Customize the retry interval to suit your alerting sensibility.

Location uptime is computed on a per-evaluation basis (whether the last test result before evaluation was up or down). The total uptime is computed based on the configured alert conditions. Notifications sent are based on the total uptime.

Configure the test monitor

A notification is sent by your test based on the alerting conditions previously defined. Use this section to define how and what to message your team.

1. Similar to how you configure monitors, select users and/or services that should receive notifications either by adding an @notification to the message or by searching for team members and connected integrations with the dropdown menu.

2. Enter the notification message for your test or use pre-filled monitor messages. This field allows standard Markdown formatting and supports the following conditional variables:

Notification messages include the message defined in this section and information about the failing locations. Pre-filled monitor messages are included in the message body section:

3. Specify how often you want your test to re-send the notification message in case of test failure. To prevent renotification on failing tests, check the option Stop re-notifying on X occurrences.

4. Click Save & Start Recording to save your test configuration and monitor.

For more information, see Synthetic Monitoring notifications.

Downtimes

To pause test execution during planned maintenance windows, select an existing Scheduled downtime in the Downtimes section. The test automatically pauses during the downtime’s scheduled time slots.

Note: You cannot create a new downtime from the test creation form. To create one, navigate to Settings > Downtimes.

원클릭

API 테스트 생성은 카탈로그 및 기존 API 테스트에서 엔드포인트를 제안하여 테스트 양식을 관련 옵션으로 미리 채웁니다. APM 트레이스, 카탈로그 엔드포인트 검색 및 사용자가 생성한 기존 유사 Synthetic 테스트와 같은 기존 Datadog 데이터 소스를 사용하세요.

API 테스트 URL 입력값을 입력하여 Synthetic Monitoring에서 엔드포인트 제안 또는 유사한 테스트를 얻습니다.

그런 다음 테스트 미리 채우기 제안을 선택하여 설정(요청 옵션 및 헤더, 인증 및 변수)을 작성합니다.

Create local variables

To create a local variable, click + All steps > Variables. You can select one of the following available builtins to add to your variable string:

{{ numeric(n) }}

Generates a numeric string with n digits.

{{ alphabetic(n) }}

Generates an alphabetic string with n letters.

{{ alphanumeric(n) }}

Generates an alphanumeric string with n characters.

{{ date(n unit, format) }}

Generates a date in one of Datadog’s accepted formats with a value corresponding to the UTC date the test is initiated at + or - n units.

{{ timestamp(n, unit) }}

Generates a timestamp in one of Datadog’s accepted units with a value corresponding to the UTC timestamp the test is initiated at +/- n units.

{{ uuid }}

Generates a version 4 universally unique identifier (UUID).

{{ public-id }}

Injects the Public ID of your test.

{{ result-id }}

Injects the Result ID of your test run.

To obfuscate local variable values in test results, select Hide and obfuscate variable value. After you have defined the variable string, click Add Variable.

Apply filters to variable values

When you reference a variable, you can transform its resolved value by appending a filter with a pipe (|). Use the syntax {{ VARIABLE_NAME | filter }} anywhere a variable is accepted, such as the URL, request body, headers, and assertions. The following filters are available:

{{ VARIABLE_NAME | urlEncode }}

URL-encodes the variable’s value. For example, hello world becomes hello%20world.

{{ VARIABLE_NAME | urlDecode }}

URL-decodes the variable’s value. For example, hello%20world becomes hello world.

{{ VARIABLE_NAME | base64Encode }}

Base64-encodes the variable’s value. For example, hello becomes aGVsbG8=.

{{ VARIABLE_NAME | base64Decode }}

Base64-decodes the variable’s value. For example, aGVsbG8= becomes hello.

Filters apply to both local and global variables. You can apply one filter per reference, and filter names are case-sensitive.

변수 사용

HTTP 테스트의 URL, 고급 옵션 및 어설션에서 Settings 페이지에 정의된 전역 변수를 사용할 수 있습니다.

변수 목록을 표시하려면 원하는 필드에 {{을 입력하세요.

테스트 실패

하나 이상의 어설션을 충족하지 않거나 요청이 초기에 실패한 경우 테스트는 FAILED로 간주됩니다. 경우에 따라 엔드포인트 어설션을 테스트하지 않고도 테스트가 실패할 수 있습니다.

HTTP 및 SSL 오류 코드의 전체 목록은 API 테스트 오류를 참조하세요.

권한

기본적으로, Datadog Admin 및 Datadog Standard 역할을 가진 사용자만 Synthetic HTTP 테스트를 생성, 편집 및 삭제할 수 있습니다. Synthetic HTTP 테스트에 대한 생성, 편집 및 삭제 권한을 얻으려면 사용자를 두 가지 기본 역할 중 하나로 업그레이드하세요.

사용자 정의 역할 기능을 사용하는 경우, synthetics_read 및 synthetics_write 권한이 포함된 사용자 정의 역할에 사용자를 추가하세요.

액세스 제한

Use granular access control to limit who has access to your test based on roles, teams, or individual users:

1. Open the permissions section of the form.
2. Click Edit Access.

3. Click Restrict Access.
4. Select teams, roles, or users.
5. Click Add.
6. Select the level of access you want to associate with each of them.
7. Click Done.

추가 자료

추가 유용한 문서, 링크 및 기사:

Datadog Synthetic Monitoring 소개블로그 Synthetic 테스트 소개학습 센터 HTTP 테스트 시작하기설명서 내부 엔드포인트에서 HTTP 테스트 실행설명서 다단계 HTTP 테스트 실행설명서 Synthetic 테스트 모니터링에 대해 알아보기설명서