New Relicデータの1つのタイプは、 メトリックタイムスライスデータです。メトリックタイムスライスデータをクエリする方法はいくつかあります。
- NRQLを介して（したがって、 NerdGraph APIを介して） APMメトリックタイムスライスデータをクエリできます。
- RESTAPIを介して任意のメトリックタイムスライスデータをクエリできます
このドキュメントでは、RESTAPIを使用してこれを行う方法について説明します。 APIは、分単位のデータポイントのバルクデータ抽出を目的としていないことに注意してください。
時間ベースのデータ
RESTAPIとAPIExplorerによって返されるすべての時間値はUTC（協定世界時）です。必要に応じて、データ収集の時間値を調整してください。
時間範囲の考慮事項
重要
データ要求の最小時間範囲は1分（60秒）です。それ以下のリクエストは422ステータスコードになり、データは返されません。 New Relicは、1分間隔でのみデータを収集します。
APIは、UIと同じメカニズムを使用してデータをリクエストします。これは、リクエストするデータの時間範囲によって異なります。目的は、返されるデータポイントの数を最適化し、簡単に消化できるグラフとレポートを提供することです。
例えば：
- 3時間以下の時間範囲のデータをリクエストすると、APIは最初に収集された1分のデータ値を返します。
- 時間範囲を3時間より長くすると、返されるデータ値は2分間の平均になります。
- 時間範囲を6時間以上に増やすと、返されるデータ値は5分間の平均になります。
ヒント
要求された時間範囲の初期時間が8日より古い場合、長さが4日未満の任意の時間範囲で10個の等間隔のデータポイントが返されます。
データ集計スケジュール表
これは、利用可能な時間範囲のメトリック値検索の要約です。
この時間範囲の間... | そしてこの時間範囲 | 収集されたデータの粒度 | |
|---|---|---|---|
データ年齢≤8日 | データ年齢>8日 | ||
≤3時間 | 1分 | 10等間隔 | |
>3時間 | ≤6時間 | 2分 | |
>6時間 | ≤14時間 | 5分 | |
>14時間 | ≤24時間 | 10分 | |
> 1日（24時間） | ≤4日（96時間） | 30分 | |
>4日 | ≤7日 | 1時間 | 1時間 |
>7日 | ≤3週間 | 3時間 | 3時間 |
>3週間 | ≤6週間 | 6時間 | 6時間 |
>6週間 | ≤9週間 | 12時間 | 12時間 |
>63日 | 3日 | 3日 | |
要求された時間範囲の開始時刻が 8 日より古い場合、データは、データ集約スケジュールにより、1 時間の期間に集約または平均化されています。これは、任意の 1 時間で、単一のデータ値のみが利用可能であることを意味します。時間範囲内で 1 時間未満の期間でデータを取得すると、オーバーサンプリングが発生し、重複した値が返されます。10 個の値のみを返すことで、オーバーサンプリングが防止され、より滑らかなグラフが表示されるため、誤解を招く可能性のある "プラトー" 効果が排除されます。
期間出力の制御
出力データの粒度が細かすぎる場合や、返されるデータの期間が短すぎる場合があります。これを制御するには、クエリ コマンドにperiod=パラメータを含めて、期間ごとにレポートする秒数を指定します。仕様がデータ集計スケジュールに従っていることを確認してください。
例 #1:収集されたデータの粒度をまとめた New Relic の表に従って、次の API 呼び出しは通常 30 分間隔でデータを返します。これは、リクエストが 4 日間 ( from=2018-02-13およびto=2018-02-17 ) であるためです。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分間の期間を要求することはできません。これは、時間範囲のデフォルト（30分）の粒度よりも小さいためです。
例2： 7日を超え3週間以下の範囲をリクエストする場合、デフォルトの期間は3時間ですが、6、12、24時間などの期間を指定できます。ただし、デフォルト（3時間）よりも短いため、1時間の期間を要求することはできません。
データ保持
データが利用できる期間は、特定の種類のデータのデータ保持によって異なります。
存在しないメトリックタイムスライスデータの抽出
存在しないメトリック名が要求される状況が発生する可能性があります。例えば：
- メトリックタイムスライスデータは、あるアプリケーションでは作成されていませんが、別のアプリケーションでは作成されています。これらのアプリケーションの両方で同じメトリック抽出クエリが使用されている場合、一方のアプリケーションは検索されません。
- メトリック名が誤って指定されました。
重要
過去に存在したが収集されなくなったメトリック値は、ゼロ値を返します。
正常な応答には、リクエストに関する200ステータスコードとメタデータが含まれます。メタデータには、要求されたメトリックの名前とそれらの名前の要求のステータスが含まれます。
応答メタデータ | 説明 | 応答メトリックデータ |
|---|---|---|
| 要求された期間に一致するデータが見つからなかったすべてのメトリック名を一覧表示します。 | これらのメトリックのメトリックタイムスライスデータは返されません |
| 要求された期間に一致するデータが見つかったすべてのメトリック名を一覧表示します。 | これらのメトリックのメトリックタイムスライスデータが返されます |
有効なメトリック名HttpDispatcherの出力例を次に示します。
HTTP/1.1 200 OKetag: "0dc87c63d8dff6b1a9714bdf7531ec09"Content-Type: application/jsoncache-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 OKetag: "e51782cf7c5a5596139a7f5340c3de23"Content-Type: application/jsoncache-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 }}