• /
  • ログイン
  • 無料アカウント

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

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

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

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

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

NRQL クエリでは、次の summaryuniqueCountdistribution のいずれかの関数を使用してメトリクスを集約する必要があります。

機能

コメント

概要

各時間ウィンドウ (現在は 1 分) のサマリ・メトリック・データ・ポイントを作成します。NRQL クエリが アグリゲータ関数を使用している場合に使用します。 average、sum、min、max など、サマリー メトリック タイプでサポートされています。

ルール作成のためのクエリの例

SELECT summary(duration) AS 'service.responseTime' FROM Transaction
WHERE appName = 'Data Points Staging' FACET name, appName, host

uniqueCount

uniqueCount メトリック・データ・ポイントを 1 分の時間窓ごとに作成します。NRQL クエリで uniqueCount aggregator type を使用している場合に使用します。

ルール作成のためのクエリの例

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

ディストリビューション

1 分間の時間ウィンドウごとに分布測定データポイントを作成します。NRQL クエリで アグリゲータ関数 (percentile、histogram、min、max、average、sum、count など)を使用する場合に使用します。引数として対象となる属性のみを使用し、 percentile または histogram からの残りの引数は破棄します。生成されたメトリックは、 percentile または histogram の任意の引数をサポートします。

配信 ルールの作成例。

SELECT distribution(duration) AS 'service.responseTime' FROM Transaction
WHERE appName = 'Data Points Staging' FACET name, appName, host

単純なカウントです。 summary(1) and sum

特定の WHERE 句にマッチするイベント、ログ、またはスパンを単純にカウントするメトリックが必要な場合は、 summary(1) メトリックを使用します。このメトリック・タイプは、指定したイベント、ログ、またはスパンの数を1分ごとにカウントします。作成されたメトリックをクエリするときは、 sum メソッドを使用して結果を確認します。

例: foo.count という名前のメトリックを作成して、 foo という名前のトランザクションをカウントしたい場合、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個の属性(ファセット)を選択して、メトリックに含めることができます。

タイムウィンドウの制限

24時間以内に、1つのメトリックに対するユニークなメトリック名と属性値の組み合わせを50Kに制限。

この制限を超えた場合、ルールは無効になり、そのアカウントに NrIntegrationError イベント が作成されます。

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

メトリック名と属性値の組み合わせの制限

1つのアカウントで24時間以内にユニークなメトリック名と属性値の組み合わせの合計数の制限は

  • 購入した月間平均データポイント数の3倍に相当
  • 最大で10Mまで

カーディナリティ制限

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

5つの属性を付加するメトリック作成ルールの例。

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

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

実際には、属性はしばしば関連しているので、これは通常そうではありません。例えば、ある属性が hostname であり、別の属性が awsRegion である場合、ホスト名Aを見たとき、それは常にAWSリージョンBであり、ホスト名Aと他のAWSリージョンの値を見ることはないでしょう。

このため、 NRQL 作成プロセス において、 uniqueCount 関数を使用して、NRQL クエリが生成しているユニークなメトリック名と属性値の組み合わせの数を確認することが重要です。

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

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

1つのルールで複数のメトリクスを作成する例。

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 httpResponseCode, 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へ(左から右へ)進むことをお勧めします。

  1. New Relic のメトリック名と一致させるために、これらのコンポーネントをドットで区切ります。

  2. そして、ドットの中の単語をアンダースコアで区切ります。

    例:

    application.page_view.duration

属性

メトリック名に属性を入れないようにします。属性とは、クラスタやアベイラビリティー・ゾーンのように、データのフィルタリングやファセットに使用できるメトリックの品質です。

例: メトリクス名にアベイラビリティー・ゾーンを含めた場合、そのメトリクスでは、すべてのアベイラビリティー・ゾーンの結果を見ることができないことになります。

メートル法の名称変更

メトリック名を変更した場合、履歴データは not その新しい名前に更新されます。過去のデータを照会したりグラフ化するには、古いメトリック名を指定する必要があります。

問題を作成する
Copyright © 2023 New Relic Inc.