Metrics Insights のトラブルシューティング

結果に、実際には使用していない「Other」というディメンションが含まれている

これは、このクエリに含まれる GROUP BY 句で指定されているラベルキーが、このクエリによって返されるメトリクスの一部で使用されていないことを意味します。この場合、Other という名前の NULL グループは返されません。そのラベルキーを含まないメトリクスは、おそらく、そのラベルキーの値すべてから集約された値を返す、集計メトリクスです。

例えば、次のようなクエリがあるとします:

SELECT AVG(Faults) 
FROM MyCustomNamespace 
GROUP BY Operation, ServiceName

返されたメトリクスの一部に、ディメンションとして ServiceName が含まれない場合、これらのメトリクスは、ServiceName の値として Other が割り当てられて表示されます。

結果に「Other」が表示されないようにするには、FROM 句で SCHEMA を使用します。以下にその例を示します。

SELECT AVG(Faults) 
FROM SCHEMA(MyCustomNamespace, Operation)
GROUP BY Operation, ServiceName

これにより、結果として返されるメトリクスは、Operation と ServiceName 両方のディメンションを持つもののみに制限されます。

グラフ内の最も古いタイムスタンプは、他のメトリクスよりも低いメトリクス値を持っています

CloudWatch Metrics Insights は、最大 2 週間の履歴データをサポートしています。1 分を超える周期でグラフを作成する場合、最も古いデータポイントが、想定される値とは異なることがあります。これは、CloudWatch Metrics Insights クエリが 2 週間の保持期間内のデータのみを返すためです。この場合、クエリ内の最も古いデータポイントは、そのデータポイントの期間内のすべての観測値を返すのではなく、2 週間の境界内に測定された観測値のみを返します。

タグベースのクエリを使用する際に、異なる期間にわたってメトリクス値が一貫していない

CloudWatch Metrics Insights クエリでタグを持つ WHERE または GROUP BY 句を使用すると、選択した期間に応じて異なるメトリクス値が表示される場合があります。例えば、6 時間の期間はピーク値 20 を示す場合があり、1 時間の期間は同じ時間枠で 2 のみを示します。

これは、タグタイムスタンプが第 2 レベルの解像度で保存され、メトリクスデータポイントが期間境界 (例: 1 分または 1 時間ごとの開始) に調整されているために発生します。どのデータポイントがタグ時間範囲に一致するかを決定するために、CloudWatch は 1 つの期間を減算して範囲の開始を調整します。期間が大きいほど、この調整でタグタイムスタンプと最も早く含まれるデータポイントの間のギャップが広くなり、範囲の開始に近いデータポイントが除外される可能性があります。

次の例は、これがクエリ結果にどのように影響するかを示しています。メトリクスには、 env=beta (00:00～01:30) と env=gamma (01:30～03:00) の 2 つのタグ値があります。各タグは 90 分のデータをカバーし、合計は 270 です。

1 分の期間では、アラインメント調整は小さく (1 分)、タグごとに 1 つの追加データポイントのみが含まれます。3 時間の期間では、調整はクエリ範囲全体に及びます:

3 時間の期間では、単一の集計データポイントのタイムスタンプが両方の調整された範囲内に収まるため、両方のタグはデータセット全体 (SUM=540、SAMPLE_COUNT=180) を返します。タグの境界は効果的に消去されます。

この動作の影響を減らすには、次の方法を試してください: