Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

アラートの費用を管理する

このドキュメントでは、アラートの費用を削減するために活用できる戦略について説明しています。料金モデルについては、Google Cloud Observability の料金とアラートの料金の例をご覧ください。

UI 内の料金計算ツールを使用して請求額の見積もりを確認する

アラートポリシーを作成または編集すると、Cloud Alerting にポリシーの推定費用が表示されます。この計算ツールを使用すると、アラートポリシーのパラメータを変更したときに推定費用がどのように変化するかを確認できます。

Metrics Explorer を使用して返されるポイント数を確認する

アラートポリシーのクエリによって返されるポイント数は、主にアラートポリシーのクエリの出力のカーディナリティによって異なります。アラートポリシーの推定カーディナリティを確認する手順は次のとおりです。

指標しきい値のアラート条件の場合は、Metrics Explorer を使用して同一のクエリを作成します。セカンダリ変換として [時系列のカウント] を [なし] で追加します。
PromQL アラート条件の場合は、クエリを Metrics Explorer にコピーして、次の操作を行います。
- すべての >, <, >=, <=, ==, !=, AND, OR, および UNLESS 演算子で分割して、クエリを個別の句に分割します。
- 数値しきい値など、指標を含まない句を削除します。
- 各句を count() 関数でラップします。
- 結果を合計します。
MQL アラート条件の場合は、クエリを Metrics Explorer にコピーします。 | condition 行を削除します。末尾に | group_by [], .count 行を追加します。

MQL は非推奨です。Cloud カスタマーケアでは、請求に関する問題のデバッグに関するサポートリクエストに対応できない場合があります。

アラートポリシーを統合して、より多くのリソースに対して動作するようにする

アラートには指標参照ごとに費用が発生し、指標しきい値ポリシーには条件ごとに 1 つの指標参照があります。このため可能であれば、リソースごとにアラートポリシーを作成するのではなく、1 つのアラートポリシーで複数のリソースをモニタリングしてください。

たとえば、100 個の VM があるとします。各 VM では、指標タイプ my_metric に対して 1 分ごとにポイントが生成されます。返されるポイントをモニタリングする方法は次の 2 つです。

1 つの条件を含むアラートポリシーを 1 つ作成します。したがって、指標参照は 1 つです。この条件は my_metric をモニタリングし、データを VM レベルで集計します。集計後、VM ごとに 1 つのポイントが返されます。したがって、この条件では評価ごとに 100 個のポイントが生成されます。
100 個のアラートポリシーを作成し、それぞれに 1 つの条件を指定します。したがって、指標参照は 1 つです。各条件では、VM の 1 つに対応する my_metric 時系列がモニタリングされ、データは VM レベルに集計されます。したがって、各条件では評価ごとに 1 つのポイントが返されます。

100 個の条件（100 個の指標参照）を作成する 2 番目のオプションは、1 個の条件（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 つのポイントのみを返す最初のオプションよりも費用が高くなります。

アラートポリシーを構成する場合は、ユースケースに最適な集計レベルを選択します。たとえば、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 秒間隔のクエリの半分の頻度で実行されます。

[リソースを指定しない] を使用しない（ログベースの指標のみ）

ログベースの指標を使用するアラート条件では、モニタリング対象リソースタイプとして [リソースを指定しない] を設定できます。この場合、アラート条件では、Cloud Monitoring のモニタリング対象リソースタイプごとに個別のクエリが起動されます。各クエリでは、返されるポイントが 1 つ以上の場合に課金されるため、リソースタイプを指定しないと、返されるポイント数が多くなり、請求額が高くなります。

請求額を抑えるには、[リソースを指定しない] を使用するのではなく、特定のリソースタイプを選択します。ほとんどのログベースの指標は 1 つのリソースタイプにのみ表示されるため、この方法で対応できます。ログベースの指標が複数のリソースタイプに表示される場合は、複数のアラートポリシーを作成するか、1 つのアラートポリシーで複数の条件を使用します。