メトリックタイムスライスデータを抽出する

New Relicデータの1つのタイプは、 メトリックタイムスライスデータです。メトリックタイムスライスデータをクエリする方法はいくつかあります。

• NRQLを介して（したがって、 NerdGraph APIを介して） APMメトリックタイムスライスデータをクエリできます。
• RESTAPIを介して任意のメトリックタイムスライスデータをクエリできます

このドキュメントでは、RESTAPIを使用してこれを行う方法について説明します。 APIは、分単位のデータポイントのバルクデータ抽出を目的としていないことに注意してください。

時間ベースのデータ

RESTAPIとAPIExplorerによって返されるすべての時間値はUTC（協定世界時）です。必要に応じて、データ収集の時間値を調整してください。

時間範囲の考慮事項

APIは、UIと同じメカニズムを使用してデータをリクエストします。これは、リクエストするデータの時間範囲によって異なります。目的は、返されるデータポイントの数を最適化し、簡単に消化できるグラフとレポートを提供することです。

例えば：

• three hours or less

  の時間範囲からデータを要求すると、API は最初に収集された 1 分間のデータ値を返します。

• 時間範囲を

  greater than three hours

  に増やすと、返されるデータ値は 2 分間の平均になります。

• 時間範囲を

  over six hours

  に増やすと、返されるデータ値は 5 分間の平均になります。

データ集計スケジュール表

これは、利用可能な時間範囲のメトリック値検索の要約です。

要求された時間範囲の開始時刻が 8 日より古い場合、データは、データ集約スケジュールにより、1 時間の期間に集約または平均化されています。これは、任意の 1 時間で、単一のデータ値のみが利用可能であることを意味します。時間範囲内で 1 時間未満の期間でデータを取得すると、オーバーサンプリングが発生し、重複した値が返されます。10 個の値のみを返すことで、オーバーサンプリングが防止され、より滑らかなグラフが表示されるため、誤解を招く可能性のある "プラトー" 効果が排除されます。

期間出力の制御

場合によっては、出力データの粒度が細かすぎたり、返されるデータの期間が短すぎたりすることがあります。 これを制御するには、各期間にレポートするsecondsの数として、クエリ コマンドにperiod=引数を含めます。 仕様が当社のデータ集約スケジュールに従っていることを確認してください。

Example #1: 収集されたデータの粒度をまとめたNew Relicの表に従うと、リクエストは 4 日間 (from=2018-02-13 と to=2018-02-17) であるため、次のAPI呼び出しは通常 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分）の粒度よりも大きいためです。

• 上記のコマンド例では、時間範囲のデフォルト (30 分) の粒度よりも短いため、1 分間の期間を要求してい

  cannot

  。

Example #2: デフォルトの期間が 3 時間である 7 日以上 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
  }
}