ここでは、イベント、ログ、またはスパンからメトリクスを作成する際の制限、要件、および推奨事項について説明します。
メトリックアグリゲーション
NRQL クエリでは、次の summary
、 uniqueCount
、 distribution
のいずれかの関数を使用してメトリクスを集約する必要があります。
機能 | コメント |
---|---|
| 各時間ウィンドウ (現在は 1 分) のサマリ・メトリック・データ・ポイントを作成します。NRQL クエリが アグリゲータ関数を使用している場合に使用します。 average、sum、min、max など、サマリー メトリック タイプでサポートされています。 ルール作成のためのクエリの例
|
|
ルール作成のためのクエリの例
|
| 1 分間の時間ウィンドウごとに分布測定データポイントを作成します。NRQL クエリで アグリゲータ関数 (percentile、histogram、min、max、average、sum、count など)を使用する場合に使用します。引数として対象となる属性のみを使用し、
|
単純なカウントです。 | 特定の 例:
そして、次のように照会します。
メトリクスの詳細については、 メトリクスの種類に関するドキュメント を参照してください。 |
ルール作りの限界
これらの制限は、メトリックルールの作成に影響します。
制限 | コメント |
---|---|
アカウント制限 | 1つのアカウントには、最大1,000個のメトリック作成ルールを設定できます。 |
メトリックルールの制限 | ルールができる。
|
タイムウィンドウの制限 | 24時間以内に、1つのメトリックに対するユニークなメトリック名と属性値の組み合わせを50Kに制限。 この制限を超えた場合、ルールは無効になり、そのアカウントに
|
メトリック名と属性値の組み合わせの制限 | 1つのアカウントで24時間以内にユニークなメトリック名と属性値の組み合わせの合計数の制限は
|
カーディナリティ制限
ルール作成の制限 には、メトリック名と属性値のユニークな組み合わせの数の制限が含まれる。この制限が存在するのは、属性や属性値の数が多いと、報告されるデータのサイズが指数関数的に増加する可能性があるためです。
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つのルールで複数のメトリクスを作成する理由。
- rules-per-account limitに到達する可能性が低い.
- 複数のメトリクスに同じ属性を追加しやすくなりました。
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
となります。
メトリック名 | 要件および推奨 |
---|---|
要件 | メトリックのネーミングに関する要件
|
長さと構造 | 他の人がこの指標を見つけ、理解し、使用することが容易になるような名称と構造を決定する。
|
名前の中の成分 | メトリクス名の中にコンポーネント(メトリクスのソースや測定対象物など)を作りたい場合は、broadからspecificへ(左から右へ)進むことをお勧めします。
|
属性 | メトリック名に属性を入れないようにします。属性とは、クラスタやアベイラビリティー・ゾーンのように、データのフィルタリングやファセットに使用できるメトリックの品質です。 例: メトリクス名にアベイラビリティー・ゾーンを含めた場合、そのメトリクスでは、すべてのアベイラビリティー・ゾーンの結果を見ることができないことになります。 |
メートル法の名称変更 | メトリック名を変更した場合、履歴データは not その新しい名前に更新されます。過去のデータを照会したりグラフ化するには、古いメトリック名を指定する必要があります。 |