메트릭 타임슬라이스 데이터 추출

New Relic 데이터의 한 유형은 메트릭 타임슬라이스 데이터 입니다. 메트릭 타임슬라이스 데이터를 쿼리하는 방법에는 여러 가지가 있습니다.

• NRQL을 통해(따라서 NerdGraph API 를 통해) APM 메트릭 타임슬라이스 데이터를 쿼리 할 수 있습니다.
• REST API를 통해 모든 메트릭 타임슬라이스 데이터를 쿼리할 수 있습니다.

이 문서에서는 REST API를 사용하여 이 작업을 수행하는 방법을 설명합니다. API는 분 단위 데이터 포인트의 대량 데이터 추출을 위한 것이 아닙니다.

시간 기반 데이터

REST API 및 API 탐색기에서 반환되는 모든 시간 값은 UTC(협정 세계시)입니다. 필요에 따라 데이터 수집을 위한 시간 값을 조정 해야 합니다.

시간 범위 고려 사항

API는 데이터를 요청하는 데 UI와 동일한 메커니즘을 사용합니다. 요청하는 데이터의 시간 범위에 따라 다릅니다. 목표는 반환되는 데이터 포인트의 수를 최적화하고 쉽게 이해할 수 있는 그래프와 보고서를 제공하는 것입니다.

예를 들어:

• three hours or less 시간 범위의 데이터를 요청하면 API는 원래 수집된 1분 데이터 값을 반환합니다.
• 시간 범위를 greater than three hours 으로 늘리면 반환되는 데이터 값은 2분 동안의 평균이 됩니다.
• 시간 범위를 over six hours 으로 늘리면 반환되는 데이터 값은 5분 동안의 평균이 됩니다.

데이터 집계 일정표

다음은 사용 가능한 시간 범위에 대한 메트릭 값 검색에 대한 요약입니다.

요청된 시간 범위의 시작 시간이 8일보다 오래된 경우 데이터 집계 일정으로 인해 데이터가 1시간 기간으로 집계되거나 평균화되었습니다. 이는 한 시간 동안 단일 데이터 값만 사용할 수 있음을 의미합니다. 시간 범위에서 1시간 미만의 기간에 데이터를 얻으면 오버샘플링이 발생하여 중복 값이 반환됩니다. 10개의 값만 반환하면 오버샘플링이 방지되고 더 부드러운 차트가 표시되므로 오해의 소지가 있는 "고원" 효과가 제거됩니다.

기간 출력 제어

때로는 출력 데이터의 세분성이 너무 미세하거나 반환된 데이터의 기간이 너무 짧을 수도 있습니다. 이를 제어하려면 각 기간에 보고할 seconds 수만큼 쿼리 명령에 period= 조사를 포함합니다. 귀하의 사양이 당사의 데이터 집계 일정을 따르는지 확인하십시오.

Example #1: 수집된 데이터의 세분성을 요약한 뉴렐릭의 테이블에 따라 다음 API 호출은 요청이 4일(from=2018-02-13 및 to=2018-02-17)에 대한 것이므로 일반적으로 30분 기간에 데이터를 반환합니다. period=3600 추가하면 데이터가 60분 기간으로 반환됩니다.

$
curl -X GET "https://api.newrelic.com/v2/applications/$APP_ID/metrics/data.xml" \
>
     -H "Api-Key:$API_KEY" -i \
>
     -d'names[]=CPU/User+Time&from=2018-02-13T04:00:00+00:00&to=2018-02-17T04:00:00+00:00&period=3600'

요청하는 시간 범위의 기본값보다 작은 기간을 지정할 수 없습니다. 예를 들어:

• 위의 명령 예에서 1시간 기간을 요청할 수 있습니다. 이는 시간 범위에 대한 기본(30분) 세분성보다 크기 때문입니다.
• 위의 명령 예에서는 1분 기간을 요청 cannot . 이는 시간 범위의 기본(30분) 단위보다 작기 때문입니다.

Example #2: 7일보다 크고 3주 이하인 범위(기본 기간은 3시간)를 요청하는 경우 6, 12, 24시간 등의 기간을 지정할 수 있습니다. 그러나 1시간은 기본값(3시간)보다 짧으므로 요청할 수 없습니다.

데이터 보존

데이터를 사용할 수 있는 기간은 특정 유형의 데이터에 대한데이터 보존 에 따라 다릅니다.

존재하지 않는 메트릭 타임슬라이스 데이터 추출

존재하지 않는 메트릭 이름이 요청되는 상황이 발생할 수 있습니다. 예를 들어:

• 메트릭 타임슬라이스 데이터는 한 애플리케이션에 대해 생성되지 않았지만 다른 애플리케이션에 대해 존재합니다. 동일한 메트릭 추출 쿼리가 이러한 두 응용 프로그램에서 모두 사용되는 경우 하나의 응용 프로그램에 대해 찾지 않습니다.
• 메트릭 이름이 잘못 지정되었습니다.

성공적인 응답에는 200 상태 코드와 요청에 대한 메타데이터가 포함됩니다. 메타데이터에는 요청된 메트릭의 이름과 해당 이름에 대한 요청 상태가 포함됩니다.

다음은 유효한 측정항목 이름 HttpDispatcher 에 대한 출력의 예입니다.

HTTP/1.1 200 OK
etag: "0dc87c63d8dff6b1a9714bdf7531ec09"
Content-Type: application/json
cache-control: max-age=0, private, must-revalidate
{
  "metric_data": {
    "from": "2016-01-28T18:06:06+00:00",
    "to": "2016-01-28T18:36:06+00:00",
    "metrics_not_found": [], <---<<< INDICATES NO INVALID METRIC NAMES REQUESTED
    "metrics_found": [
      "HttpDispatcher"       <---<<< INDICATES THIS METRIC NAME WAS VALID
    ],
    "metrics": [             <---<<< DATA RETURNED
      {
        "name": "HttpDispatcher",
        "timeslices": [
          {
            "from": "2016-01-28T18:03:00+00:00",
            "to": "2016-01-28T18:04:00+00:00",
            "values": {
              "average_response_time": 364,
              "calls_per_minute": 99800,
              "call_count": 99770,
              "min_response_time": 3.5,
              "max_response_time": 85000,
              "average_exclusive_time": 0,
              "average_value": 0.364,
              "total_call_time_per_minute": 36300,
              "requests_per_minute": 99800,
              "standard_deviation": 1900,
              "average_call_time": 364
            ...

다음은 잘못된 측정항목 이름 Foo 에 대한 출력의 예입니다.

HTTP/1.1 200 OK
etag: "e51782cf7c5a5596139a7f5340c3de23"
Content-Type: application/json
cache-control: max-age=0, private, must-revalidate
{
  "metric_data": {
    "from": "2016-01-28T18:06:33+00:00",
    "to": "2016-01-28T18:36:33+00:00",
    "metrics_not_found": [
      "Foo"                   <---<<< INDICATES THIS METRIC NAME WAS INVALID
    ],
    "metrics_found": [],      <---<<< INDICATES NO VALID METRIC NAMES FOUND
    "metrics": []             <---<<< NO DATA RETURNED
  }
}