ポリシーを統合し、クエリが返す時系列ポイントの数を制限することで、Cloud Monitoring アラート ポリシーの費用を管理できます。返されるポイントを減らすには、モニタリング対象の時系列を集約してフィルタし、PromQL 評価間隔を調整します。ポリシー パラメータを変更すると、請求額の見積もりの更新も確認できます。
料金モデルについては、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 秒間隔のクエリの半分の頻度で実行されます。
「未指定のリソース」を使用しない（ログベースの指標のみ）
ログベースの指標を使用するアラートの条件では、モニタリング対象リソースタイプとして [Unspecified Resource] を設定できます。この場合、アラートの条件は Cloud Monitoring のモニタリング対象リソースタイプごとに個別のクエリを起動します。各クエリでは、返されたポイントの最小値が課金されるため、リソースタイプを指定しないと、返されたポイントの請求額が高くなります。
請求額を抑えるには、[未指定のリソース] ではなく、特定のリソースタイプを選択します。これは、ほとんどのログベースの指標が 1 つのリソースタイプにのみ表示されるためです。ログベースの指標が複数のリソースタイプに表示される場合は、複数のアラート ポリシーを作成するか、1 つのアラート ポリシーで複数の条件を使用できます。