Metric APIによるメトリクスの報告

Metric API を使用して、New Relic プラットフォームにカスタムメトリックを送信します。このドキュメントには、最初のカスタムメトリックを送信するためのクイックスタートと、メトリックデータをフォーマットして送信する方法についての詳細な情報が含まれています。

クイックスタート測定データの送信

count, gauge, summary というメトリックタイプを報告します。メトリクスの詳細については、当社のドキュメントを参照してください。

メトリックデータは、HTTP POST リクエストで New Relic に送信されます。各リクエストは1つ以上のメトリックデータで構成され、メトリック名、タイムスタンプ、値で構成されます。

この例に従って、最初のメトリックデータポイントをNew Relicに送信します。

データを報告したいアカウントのライセンスキーを取得します。
ライセンスキーを以下のJSONに挿入し、そのJSONを当社のエンドポイントに送信します。
タイムスタンプ を有効なエポック・タイムスタンプで更新します。 fix(Metric API)。不要なインデントの削除この例では、 memory.heap という名前のメトリックのデータポイントを1つ作成していますが、メトリックタイプを指定したり、オプション 共通 ブロックを追加したりすることで、追加の属性やデータポイントを作成することができます。
```
curl -vvv -k -H "Content-Type: application/json" \
-H "Api-Key: NEW_RELIC_LICENSE_KEY" \
-X POST https://metric-api.newrelic.com/metric/v1 \
--data '[{ 
        "metrics":[{ 
           "name":"memory.heap", 
           "type":"gauge", 
           "value":2.3, 
           "timestamp":CURRENT_TIME, 
           "attributes":{"host.name":"dev.server.com"} 
           }] 
    }]'
```

メトリックは数秒で New Relic で利用できるようになります。このクエリを使って、任意の NRQL インターフェースからデータを照会することができます。

FROM Metric SELECT max(memory.heap) TIMESERIES

データが表示される場所については、 Find Metric API data を参照してください。

エンドポイントURL

メトリックAPIのエンドポイントにメトリックデータを送信する場合は、HTTP POSTを使用します。

https://metric-api.newrelic.com/metric/v1

ヒント

お使いのアカウントがEUデータセンターでデータをホストする場合は、適切なEU地域アカウント向けAPIエンドポイントを使用していることを確認してください。

HTTPリクエストヘッダ

POSTリクエストには、以下のHTTPリクエストヘッダを含めてください。一部のパラメーターは、リクエストヘッダーではなく、クエリパラメーターとして送信できます。

ヘッダー	クエリのパラメータとして送信しますか？	詳細
`コンテンツタイプ`	いいえ	必須.Must be `application/json`.
`Content-Length`	いいえ	必須（通常、HTTP クライアントが自動的に設定します）.リクエストボディの長さをオクテット(8ビットバイト)で表します(チャンクされたエンコーディングで送信された場合を除く)。このヘッダーは、通常、データを送信する基礎となるHTTPクライアントによってデフォルトで設定され、ほとんどの場合、エンドユーザーが追加の努力をする必要はありません。
`Api-Key`	はい	必須。データを報告したいアカウントのライセンスキー。これがヘッダとクエリパラメータの両方として提供されている場合、値が一致している必要があります。
`Content-Encoding`	いいえ	GZIPの場合は必須です。値は `GZIP` または `Identity です。` 値がない場合は `Identity` を想定しています。
`x-request-id`	いいえ	Optional - Reserved for future use. The value must be a valid `UUID4`.この値は、各リクエストに対して一意であることが期待されます。

HTTPリクエストボディ

HTTP POSTリクエストのボディは、JSON形式である必要があります。以下に、JSONペイロードの要件と推奨事項を記載します。

ペイロードは UTF-8 としてエンコードする必要があります。

構造

JSONペイロードはこの構造体を使用しています。

JSONのペイロードは、マップの配列です。
各マップには、1つ以上のメトリックデータポイントを含む配列を値とする metrics キーを含める必要があります。
メトリックデータポイントは、 名前 、 値 、 タイムスタンプ と、オプションの属性セットによって識別されます。

このペイロードの例では、2つのメトリックを作成しています。 service.errors.all は3つの属性を持つカウントメトリックで、 service.memory は2つの属性を持つゲージメトリックです。

[
  {
    "metrics": [
      {
        "name": "service.errors.all",
        "type": "count",
        "value": 15,
        "timestamp": [CURRENT_TIME](#optional-map-attributes),
        "interval.ms": 10000,
        "attributes": {
          "service.response.statuscode": "400",
          "host.name": "dev.server.com",
          "service.name": "foo"
        }
      },
      {
        "name": "service.memory",
        "type": "gauge",
        "value": 2.7,
        "timestamp": CURRENT_TIME,
        "attributes": {
          "host.name": "dev.server.com",
          "app.name": "foo"
        }
      }
    ]
  }
]

必要なキー・バリュー・ペア

metrics 配列内の各メトリックデータポイントマップは、以下のキー・バリュー構造を使用しています。

キー	説明
`name` 文字列	必須.メトリックの名前です。値は255文字以下でなければなりません。
`value` 数字 or 地図	必須.この値は、メトリックの種類によって異なります。。 `gauge` および `count` については、値は単一の数値である必要があります。 `summary` の場合、値は、count、sum、min、maxを指定するkey-valueペアを持つマップでなければなりません。
`タイムスタンプ` ロング	必須.メトリックの開始時刻を Unix時間で表示.デフォルトではUTCタイムゾーンを使用します。このフィールドは、秒、マイクロ秒、およびナノ秒もサポートしています。ただし、データは保存や検索のためにミリ秒に変換されます。報告されたタイムスタンプが48時間前よりも古いものや、報告された時点から24時間後よりも新しいものは、メトリクスが削除されます。
`インターバル.ms` ポジティブロング	`count` and `summary` metric types に必要です。タイム・ウィンドウの長さを指定します。
`種類`	推奨。これは、サポートされているメートル法のタイプの一つでなければなりません。タイプを指定しない場合は、デフォルトで `ゲージ` になります。
`属性` 文字列, JSON 数字, またはブーリアン	推奨.この特定のメトリックに関連するキー・バリュー・ペアのマップ。値は、文字列、JSON の数値、またはブーリアンです。キーは大文字と小文字を区別し、255文字以下でなければなりません。

以下は、各メトリックタイプの1つのメトリックデータポイントを含むペイロードの例です。

[
  {
    "metrics": [
      {
        "name": "cache.misses",
        "type": "count",
        "value": 15,
        "timestamp": [CURRENT_TIME](#optional-map-attributes),
        "interval.ms": 10000,
        "attributes": {
          "cache.name": "myCache",
          "host.name": "dev.server.com"
        }
      },
      { 
        "name": "temperature", 
        "type": "gauge", 
        "value": 15, 
        "timestamp": CURRENT_TIME, 
        "attributes": { 
          "city": "Portland", 
          "state": "Oregon" 
        } 
      },
      {
        "name": "service.response.duration",
        "type": "summary",
        "value": {
          "count": 5, 
          "sum": 0.004382655, 
          "min": 0.0005093, 
          "max": 0.001708826
        },
        "interval.ms": 10000, 
        "timestamp": CURRENT_TIME,
        "attributes": {
          "host.name": "dev.server.com",
          "app.name": "foo"
        }
      }
    ]
  }
]

`共通のメトリクスで属性を共有`

一連の属性を複数のメトリックに含めたい（各メトリックに同じ属性を追加したくない）場合は、 共通の ブロックを使用できます。これはオプションのマップで、関連するすべてのメトリックデータポイントに適用される情報を指定します。共通セクションの値は、同じキーがメトリックのデータポイントに存在する場合、上書きされます。

ブロックを含むことができます。

属性	説明
`タイムスタンプ` ロング	メトリックの開始時刻を Unix時間で表したものです。デフォルトでは、UTCタイムゾーンの現在の時刻になります。このフィールドは、秒、マイクロ秒、およびナノ秒もサポートしています。ただし、データは保存や後のクエリのためにミリ秒に変換されます。
`インターバル.ms` ポジティブロング	`count` and `summary`.時間ウィンドウの長さ。
`属性` 文字列、JSONの数値、またはブーリアン	この特定のメトリックに関連するキーと値のペアのマップ。値には、文字列、JSONの数値、またはブーリアンを使用できます。

属性

説明

タイムスタンプ

ロング

メトリックの開始時刻を Unix時間で表したものです。デフォルトでは、UTCタイムゾーンの現在の時刻になります。このフィールドは、秒、マイクロ秒、およびナノ秒もサポートしています。ただし、データは保存や後のクエリのためにミリ秒に変換されます。

インターバル.ms

ポジティブロング

count and summary.時間ウィンドウの長さ。

属性

文字列、JSONの数値、またはブーリアン

この特定のメトリックに関連するキーと値のペアのマップ。値には、文字列、JSONの数値、またはブーリアンを使用できます。

以下のペイロードの例では、3つのメトリクスが送信されています。3つのメトリクスはすべて、 app.name と host.name の属性を共有しており、これは common ブロックで指定されています。また、各メトリクスは、 server.response.statuscode という別の属性にも固有の値を持っています。

[
  {
    "common" : {
      "timestamp": 1531414060739,
      "interval.ms": 10000,
      "attributes": {
        "app.name": "foo",
        "host.name": "dev.server.com"
      }
    },
    "metrics": [
      {
        "name": "service.errors.all",
        "type": "count",
        "value": 9,
        "attributes": {
          "service.response.statuscode": "400"
        }
      },
      {
        "name": "service.errors.all",
        "type": "count",
        "value": 4,
        "attributes": {
          "service.response.statuscode": "500"
        }
      },
      {
        "name": "service.response.duration",
        "type": "summary",
        "value": {
          "count": 5,
          "sum": 0.004382655,
          "min": 0.0005093,
          "max": 0.001708826
        },
        "attributes": {
          "service.response.statuscode": "200"
        }
      }
    ]
  }
]

レスポンスの検証とステータスコード

Metric APIは、リクエストに成功すると、 202 レスポンスコードを返します。データが受理されると、HTTP 202 応答コードが、以下のような応答構造で返されます。

HTTP/1.1 202 Accepted
Content-Type: application/json; charset=UTF-8
Content-Length: 52
Access-Control-Allow-Methods: GET, POST, PUT, HEAD, OPTIONS
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Connection: keep-alive

{"requestId":"f0e7bfff-001a-b000-0000-01682bcf4565"}

`202` の回答がある欠落データ

202 のコードは、API がデータを受信し、データが基本的な検証チェックに合格したことを示します。通常であれば、数秒以内にデータを照会できるようになります。しかし、New Relic はデータを受け取った後、非同期に追加の検証を行います。 202 レスポンスを受け取ったにもかかわらず、メトリックが見つからない場合は、New Relic がこの非同期の検証中にエラーを発見したことを示しています。

これらのエラーは、 NrIntegrationError イベントを、使用した Insert API キーに関連付けられたアカウントで照会することで見つけることができます。各リクエストの requestId は、 NrIntegrationError イベントにタグ付けされます。詳細については、 Troubleshoot an NRIntegrationError event を参照してください。

ステータスコード

Metric APIは、以下のHTTPステータスコードを返すことができます。

ステータスコード	定義
`202`	データを受け付けました。
`400`	リクエストの構造が無効です。
`403`	認証に失敗しました。
`404`	リクエストパスが正しくありません。
`405`	POST以外のリクエストメソッドを使用しました。
`408`	リクエストがエンドポイントに到達するまでに時間がかかりすぎました。
`411`	`Content-Length` ヘッダが含まれていませんでした。
`413`	ペイロードが大きすぎました。ペイロードは1MB（10^6バイト）以下でなければなりません。
`414`	リクエストURIが長すぎました。
`415`	`Content-Type` または `Content-Encoding` が無効であることを示しています。
`429`	リクエストレートのクォータを超えてしまいました。
`431`	リクエストヘッダーが長すぎます。
`5xx`	サーバーエラーが発生しました（再試行してください）。

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

Metric APIによるメトリクスの報告

クイックスタート測定データの送信

エンドポイントURL

ヒント

HTTPリクエストヘッダ

HTTPリクエストボディ

構造

2つのメトリクスを作成するJSONペイロード

必要なキー・バリュー・ペア

3つのメトリックタイプを持つJSONペイロード

`共通のメトリクスで属性を共有`

`共通` 属性の例

レスポンスの検証とステータスコード

`202` の回答がある欠落データ

ステータスコード

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

Metric APIによるメトリクスの報告

クイックスタート測定データの送信

エンドポイントURL

ヒント

HTTPリクエストヘッダ

HTTPリクエストボディ

構造

必要なキー・バリュー・ペア

3つのメトリックタイプを持つJSONペイロード

共通のメトリクスで属性を共有

共通 属性の例

レスポンスの検証とステータスコード

202 の回答がある欠落データ

ステータスコード

`共通のメトリクスで属性を共有`

`共通` 属性の例

`202` の回答がある欠落データ