メトリクス作成のルール：要件とヒント

ここでは、イベント、ログ、またはスパンからメトリクスを作成する際の制限、要件、および推奨事項について説明します。

メトリックアグリゲーション

NRQLクエリでは、次のsummary 、 uniqueCount 、またはdistribution関数のいずれかを使用してメトリックを集計する必要があります。

働き	コメントコメント
`summary`	各時間ウィンドウ (現在は 1 分) の概要メトリクスデータポイントを作成します。 NRQLクエリが、`average`、`sum`、`min`、`max`などのサマリーメトリックスタイプでサポートされている集計関数を使用する場合は、これを使用します。 Example rule-creation query: `SELECT summary(duration) AS 'service.responseTime' FROM Transaction WHERE appName = 'Data Points Staging' FACET name, appName, host`
`uniqueCount`	1分の時間枠ごとに`uniqueCount`メトリックデータポイントを作成します。 NRQLクエリが`uniqueCount` アグリゲータータイプを使用する場合は、これを使用します。ルール作成のためのクエリの例 `FROM Transaction SELECT uniqueCount(request.headers.userAgent) AS 'server.request.header.userAgent.uniqueCount' WHERE appName = 'Browser Monitoring Router' FACET http.statusCode, name, appName, host`
`distribution`	1 分間の時間ウィンドウごとに分布メトリックデータポイントを作成します。 NRQL クエリで`percentile` 、 `histogram` 、 `min` 、 `max` 、 `average` 、 `sum` 、 `count`などの集計関数を使用する場合は、これを使用します。関心のある属性のみを引数として使用し、 `percentile`または`histogram`からの残りの引数を破棄します。生成されたメトリクスは、 `percentile`または`histogram`の任意の引数をサポートします。 Example of creating a `distribution` rule: `SELECT distribution(duration) AS 'service.responseTime' FROM Transaction WHERE appName = 'Data Points Staging' FACET name, appName, host`
単純なカウント： `summary(1)`および `sum`	特定の`WHERE`句に一致するイベント、ログ、またはスパンの単純なカウントであるメトリックが必要な場合は、 `summary(1)`メトリックを使用します。このメトリックタイプは、指定されたイベント、ログ、または1分あたりのスパンの数をカウントします。作成されたメトリックを照会するときは、 `sum`メソッドを使用して結果を確認してください。 Example: `foo` という名前のトランザクションをカウントする `foo.count` という名前のメトリックを作成する場合、 NRQLは次のようになります。 `FROM Transaction SELECT summary(1) AS 'foo.count' WHERE name = 'foo'` そして、次のように照会します。 `FROM Metric SELECT sum(foo.count) SINCE 30 minutes ago` メトリクスの詳細については、メトリクスの種類に関するドキュメントを参照してください。

ルール作りの限界

これらの制限は、メトリックルールの作成に影響します。

制限	コメントコメント
アカウント制限	1つのアカウントには、最大1,000個のメトリック作成ルールを設定できます。
メトリックルールの制限	ルールができる。作成する最大10個のメトリクス. 1種類のデータ（イベント、ログ、スパン）のみを使用する。最大20個の属性（ファセット）を選択して、メトリックに含めることができます。
タイムウィンドウの制限	30 秒の時間枠内の 1 つのメトリックに対する一意のメトリック名/属性値の組み合わせに対する 50K の制限。ロールアップの通常のカーディナリティ制限が適用されます。 30秒のウィンドウ制限で50kを超えると、ルールが無効になり、そのアカウントに次のような`NrIntegrationError`イベントが作成されます。ルールの詳細ファセットの数が多すぎることについてのメッセージの`newRelicFeature`属性値 `eventToMetric`

制限

コメントコメント

アカウント制限

1つのアカウントには、最大1,000個のメトリック作成ルールを設定できます。

メトリックルールの制限

ルールができる。

作成する最大10個のメトリクス.
1種類のデータ（イベント、ログ、スパン）のみを使用する。
最大20個の属性（ファセット）を選択して、メトリックに含めることができます。

タイムウィンドウの制限

30 秒の時間枠内の 1 つのメトリックに対する一意のメトリック名/属性値の組み合わせに対する 50K の制限。ロールアップの通常のカーディナリティ制限が適用されます。

30秒のウィンドウ制限で50kを超えると、ルールが無効になり、そのアカウントに次のようなNrIntegrationErrorイベントが作成されます。

ルールの詳細
ファセットの数が多すぎることについてのメッセージ
のnewRelicFeature属性値 eventToMetric

カーディナリティ制限

ルール作成の制限には、メトリック名と属性値のユニークな組み合わせの数の制限が含まれる。この制限が存在するのは、属性や属性値の数が多いと、報告されるデータのサイズが指数関数的に増加する可能性があるためです。

Example metric creation rule that attaches five attributes:

FROM ProcessSample SELECT summary(ioTotalReadBytes) 
WHERE entityType = 'ComputeSample' 
FACET awsRegion, awsAvailabilityZone, commandName, entityName, processId

仮に5つの属性のそれぞれが1分間に10個のユニークな値を報告したとすると、ユニークなメトリック名と属性の組み合わせの数は理論的には最大で10x10x10x10x10、つまり100,000個になります。複数のユニークな値を持つ複数の属性は、多数のユニークなメトリックエントリにつながります。

実際には、属性は関連していることが多いため、これは通常は当てはまりません。たとえば、1つの属性がhostnameで、別の属性がawsRegionの場合、ホスト名Aが表示されると、その属性は常にAWSリージョンBにあります。ホスト名Aやその他のAWSリージョンの値は表示されません。

これが、 NRQLの作成プロセス中に、 uniqueCount関数を使用して、NRQLクエリが生成している一意のメトリック名/属性値の組み合わせの数を確認することが重要である理由です。

1つのルールから複数の評価指標が得られる

1つのルールで作成できるメトリクスは10個までです。1つのルールで1つずつ作成されたメトリクスと、1つのルールで作成されたメトリクスの間には、機能的な違いはありません。1つのルールで複数のメトリクスを作成する理由。

rules-per-account limitに到達する可能性が低い.
複数のメトリクスに同じ属性を追加しやすくなりました。

Example creating multiple metrics with a single rule:

FROM Transaction SELECT uniqueCount(request.headers.userAgent) AS 'server.request.header.userAgent.uniqueCount', 
summary(duration) AS 'server.duration', summary(totalTime) AS 'server.totalTime' 
WHERE appName = 'Browser Monitoring Router' FACET http.statusCode, name, appName, host

メートル単位のネーミング

メトリックには、 NRQLルール作成プロセスの一部として、 AS句で名前が付けられます。次のNRQLの例では、メトリックの名前はio.totalread.bytesです。

FROM ProcessSample SELECT summary(ioTotalReadBytes) AS 'io.totalread.bytes' 
WHERE entityType = 'ComputeSample' FACET awsRegion, awsAvailabilityZone, commandName

AS句で割り当てられた名前がない場合、メトリック名は照会された属性の名前です。この例では、名前が割り当てられていない場合、メトリック名はioTotalReadBytesになります。

メトリック名	要件および推奨
要件	メトリックのネーミングに関する要件 255（UTF-16）以下の16ビットコード単位。制限を確実に守るためには、各文字列を数えやすい127以下にすることです。スペースはありません。手紙から始める。強力なメトリック名の例 `rubyvm.memory.heap_used` `redis.container.cpu.percent` `memcached.process_virtual_memory.bytes`
長さと構造	他の人がこの指標を見つけ、理解し、使用することが容易になるような名称と構造を決定する。読みやすさを考慮して、メートル法の名前は40文字以下にすることをお勧めします。長くなると切れてしまったり、他の名称と重なってしまう可能性があります。メトリックの命名方法は、お客様のビジネスロジックによって異なります。名前空間を使用してメトリック名の前に付けることもできますし、より一般的な名前にする必要があるかもしれません。
名前の中の成分	メトリクス名の中にコンポーネント（メトリクスのソースや測定対象物など）を作りたい場合は、broadからspecificへ（左から右へ）進むことをお勧めします。 New Relic のメトリック名と一致させるために、これらのコンポーネントをドットで区切ります。そして、ドットの中の単語をアンダースコアで区切ります。 Example: `application.page_view.duration`
属性	メトリック名に属性を入れないようにします。属性とは、クラスタやアベイラビリティー・ゾーンのように、データのフィルタリングやファセットに使用できるメトリックの品質です。 Example: メトリクス名に可用性ゾーンを含めると、そのメトリクスではすべての可用性ゾーンにわたる結果を表示できなくなります。
メートル法の名称変更	メトリック名を変更した場合、履歴データは not その新しい名前に更新されます。過去のデータを照会したりグラフ化するには、古いメトリック名を指定する必要があります。