このドキュメントでは、アラートの費用を削減するために活用できる戦略について説明します。
アラート ポリシーを統合して、より多くのリソースに対して動作するようにする
条件ごとに $1.50 の費用がかかるため、1 つのアラート ポリシーを使用して各リソースをモニタリングするよりも、1 つのアラート ポリシーを使用して複数のリソースをモニタリングするほうが費用対効果が高くなります。以下の例を考えてみましょう。
例 1
データ
- 100 VM
- 各 VM は 1 つの指標
metric_nameを出力します metric_nameには 10 個の値を持つ 1 つのラベルがあります
- 1 つのアラート条件
- VM レベルへの条件の集計
- 30 秒の実行期間
- 条件費用: 1 条件 * 1 か月あたり $1.50 = 1 か月あたり $1.50
- 時系列費用: 期間ごとに返される時系列が 100 件 * 1 か月あたり 86,400 の期間 = 1 か月あたりに返される時系列が 860 万件 * 100 万件の時系列あたり $0.35 = 1 か月あたり $3.02
- 合計費用: 月あたり $4.52
例 2
データ
- 100 VM
- 各 VM は 1 つの指標
metric_nameを出力します metric_nameには 10 個の値を持つ 1 つのラベルがあります
- 100 個の条件
- 各条件がフィルタされ、1 つの VM に集計されます
- 30 秒の実行期間
- 条件費用: 100 条件 * 1 か月あたり $1.50 = 1 か月あたり $150
- 時系列費用: 100 の条件 * 条件ごと、期間ごとに返される時系列が 1 件 * 1 か月あたり 86,400 の期間 = 1 か月あたりに返される時系列が 860 万件 * 100 万件の時系列あたり $0.35 = 1 か月あたり $3.02
- 合計費用: 月あたり $153.02
どちらの例でも、同じ数のリソースをモニタリングします。ただし、例 2 では 100 アラート ポリシーを使用していますが、例 1 では 1 つのアラート ポリシーのみを使用しています。その結果、例 1 の月額料金は $150 近く安くなります。
アラートが必要なレベルのみに集計する
より高いレベルの粒度に集計すると、低い粒度に集計する場合よりもコストが高くなります。たとえば、Google Cloud プロジェクト レベルへの集約はクラスタレベルへの集約よりも費用が安く、クラスタレベルへの集約はクラスタレベルと名前空間レベルへの集約よりも費用が安くなります。
以下の例を考えてみましょう。
例 1
データ
- 100 VM
- 各 VM は 1 つの指標
metric_nameを出力します metric_nameには 10 個の値を持つ 1 つのラベルがあります
- 1 つのアラート条件
- VM レベルへの条件の集計
- 30 秒の実行期間
- 条件費用: 1 条件 * 1 か月あたり $1.50 = 1 か月あたり $1.50
- 時系列費用: 期間ごとに返される時系列が 100 件 * 1 か月あたり 86,400 の期間 = 1 か月あたりに返される時系列が 860 万件 * 100 万件の時系列あたり $0.35 = 1 か月あたり $3.02
- 合計費用: 月あたり $4.52
例 4
データ
- 100 台の VM。各 VM は 1 つのサービスに属します
- 合計で 5 つのサービス
- 各 VM は 1 つの指標
metric_nameを出力します metric_nameには 10 個の値を持つ 1 つのラベルがあります
- 1 つの条件
- サービスレベルへの条件の集計
- 30 秒の実行期間
- 条件費用: 1 条件 * 1 か月あたり $1.50 = 1 か月あたり $1.50
- 時系列費用: 期間ごとに返される時系列が 5 件 * 1 か月あたり 86,400 の期間 = 1 か月あたりに返される時系列が 432,000 件 * 100 万件の時系列あたり $0.35 = 1 か月あたり $0.14
- 合計費用: 月あたり $1.64
例 5
データ
- 100 VM
- 各 VM は 1 つの指標
metric_nameを出力します metric_nameには 100 個のラベルがあり、それぞれに 1,000 個の値があります。
- 1 つの条件
- VM レベルへの条件の集計
- 30 秒の実行期間
- 条件費用: 1 条件 * 1 か月あたり $1.50 = 1 か月あたり $1.50
- 時系列費用: 期間ごとに返される時系列が 100 件 * 1 か月あたり 86,400 の期間 = 1 か月あたりに返される時系列が 850 万件 * 100 万件の時系列あたり $0.35 = 1 か月あたり $3.02
- 合計費用: 月あたり $4.52
例 1 と例 4 を比較すると、どちらの例も、同じ基になるデータに対して動作し、また、アラート ポリシーが 1 つだけあります。ただし、例 4 のアラート ポリシーはサービスに集約されるため、VM に詳細に集約される例 1 のアラート ポリシーよりも費用が安いです。
また、例 1 と例 5 を比較すると、例 5 の指標のカーディナリティは例 1 の指標のカーディナリティの 10,000 倍です。ただし、例 1 と例 5 のアラート ポリシーは両方とも VM に集約され、どちらの例でも VM の数が同じであるため、料金は同じです。
アラート ポリシーを構成する場合は、ユースケースに最適な集計レベルを選択します。たとえば、CPU 使用率に関するアラートを重視する場合は、VM と CPU のレベルに集約できます。エンドポイントごとのレイテンシに関するアラートを重視する場合は、エンドポイント レベルに集約できます。
未集計の元データに関するアラートを発生させない
Monitoring はディメンション指標システムを使用します。このシステムでは、指標の合計 [cardinality][cardinality] は、モニタリング対象リソースの数にその指標のラベルの組み合わせを掛けた数と等しくなります。たとえば、指標を出力する VM が 100 個あり、その指標にそれぞれ 10 個の値を持つ 10 個のラベルがある場合、合計カーディナリティは 100 * 10 * 10 = 10,000 です。
カーディナリティのスケーリングによっては、元データに対するアラートが非常にコストが高くなることがあります。上記の例では、実行期間ごとに 10,000 個の時系列が返されます。ただし、VM に集計する場合は、基になるデータのラベル カーディナリティに関係なく、実行期間ごとに 100 の時系列のみが返されます。
また、元データに対するアラートを行うと、指標に新しいラベルが付けられたときに時系列が増加するリスクもあります。上記の例では、ユーザーが指標に新しいラベルを追加すると、合計カーディナリティが 100 * 11 * 10 = 11,000 の時系列に増加します。この場合、アラート ポリシーが変更されないにもかかわらず、実行期間ごとに返される時系列の数が 1,000 増加します。代わりに VM に集計すると、基になるカーディナリティが増加しても、返される時系列は 100 のみになります。
不要なレスポンスをフィルタで除外する
アラートのニーズに必要なデータのみを評価するように条件を構成します。何かしらの修正を行わない場合は、アラート ポリシーから除外します。たとえば、インターンの開発用 VM に関してアラートを出す必要はないでしょう。
不要なアラートや費用を削減するために、重要でない時系列を除外できます。Google Cloud のメタデータ ラベルを使用すると、アセットにカテゴリでタグ付けし、不要なメタデータ カテゴリを除外できます。
トップストリーム演算子を使用して、返される時系列の数を減らす
条件で PromQL または MQL クエリを使用する場合は、トップ ストリーム演算子を使用して、最も高い値で返される時系列の数を選択できます。
たとえば、PromQL クエリの topk(metric, 5) 句は、各実行期間で返される時系列の数を 5 に制限します。
時系列の数に制限を加えると、次のようなデータの欠落やアラートの不具合が発生する可能性があります。
- N 個以上の時系列がしきい値を超えた場合、上位 N 個の時系列外のデータが失われます。
- 違反する時系列が上位 N 個の時系列外で発生した場合は、除外された時系列がしきい値をまたいでもインシデントが自動的にクローズされる可能性があります。
- 条件クエリで、想定通りに機能しているベースライン時系列などの重要なコンテキストが示されない場合があります。
このようなリスクを軽減するには、N に大きい値を選択し、多数の時系列を評価するアラート ポリシー（個々の Kubernetes コンテナのアラートなど）でのみトップストリーム演算子を使用します。
実行期間の長さを延長する（PromQL のみ）
条件で PromQL クエリを使用する場合、条件の evaluationInterval フィールドを設定して、実行期間の長さを変更できます。
評価間隔が長いほど、1 か月間に返される時系列は少なくなります。たとえば、15 秒間隔の条件クエリは、30 秒間隔のクエリの 2 倍の頻度で実行され、1 分間隔のクエリは、30 秒間隔のクエリの半分の頻度で実行されます。