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