👩‍💻

【初心者向け】Cloud Monitoring のアラート設定、思ったよりハマったので記録を残す

に公開
Tips
Google Cloud
初心者向け
備忘録
Cloud Monitoring
tech

本記事の前提

本記事では、Google CloudのCloud Monitoringを用いて、「CloudRunサービスの公開URLに対する4XX/認証失敗の急増」を検知する簡易的な仕組みを紹介してます。

  • Cloud Monitoringでできる範囲で行う
    • 特別な追加課金サービスは利用しない（Cloud Armorサービスは対象外）
    • DDOS対策としてのリアルタイム検知が目的ではなく、最短でも1分後に検知できればよし

Cloud Monitoringサービスとは？

Cloud Monitoring は、Google Cloud 上の各サービスのメトリクスを収集し、可視化（ダッシュボード）、閾値によるアラート、ログ連携などを提供する Google Cloud の監視サービスです。

例えば

  • CPU / Memory / レスポンス時間などの基本メトリクス
  • Cloud Run / Load Balancer / Cloud Functions の各サービスのリクエスト統計
  • カスタムメトリクス
  • アラートポリシー（閾値判定・通知）
  • SLO / uptime check
    サービス運用の監視基盤として標準で利用できるツールです。

料金

Cloud Monitoring の標準メトリクスは基本無料で利用でき、
アラートポリシー作成・通知（メール / Slack 等）も追加料金なしで使用できます。
私がこのサービスを利用したのは基本無料が大きな要因です！無料がありがたい！

ただし、カスタムメトリクスやCloud Logging（log-based metric を使う場合）、Cloud Armorを利用する場合は追加コストが発生するようですので要確認です！

今回は、標準メトリクスのみを取得するため、追加コストは発生しません！

今回やりたかったこと

  • 公開URLにアクセスが集中して、短時間に4XXが連続発生したらアラートを出すこと

具体的には、

  • Google RunサービスでAuth認証失敗や403/404などの4XXが急増したとき
  • DDoS というほどではないが「明らかな異常」は検知したい
  • リアルタイムで検知できなくても、1分後に検知できればOK

という「簡易的な異常検知」をCloud Monitoring で実現しました。

この後、実際の設定画面で設定方法を紹介しつつ、つまずきやすい部分をご紹介していきます。

実際の設定で直面した注意点

Cloud Monitoring で 4XX の急増を検知するには、まず「アラートポリシー」を作成します。

Cloud Monitoring のアラートポリシー構造

Cloud Monitoring のアラートは、まず「アラートポリシー」を作成し、
その中で「アラート条件（Condition）」を設定します。

下記のような構造になっています：

大項目 中項目（画面での場所） 設定内容 これって何？（日本語で説明）
アラート条件（Condition） — どのメトリクスをどう判定してアラートにするかを決める中心部分 今回もっともハマりポイントが多い部分
1. 指標（Metric） 監視したいデータを選ぶ（例：Cloud Run のリクエスト数） 例：Cloud Run のリクエスト数（request_count）など。
2. フィルタ（Filter） レスポンスコードなど、特定のラベルで絞り込む メトリクスに付いている属性（response_code / location など）を使って、対象にしたいデータだけに絞り込むところ
3. 集計（Transform） 過去1分の平均・レート（1/s）など、判定用に数値を整形 メトリクスの生データを、アラート判定に使いやすい統計値（平均・レート）に変換する方法を決めるところ
4. トリガー（Trigger） 閾値・継続時間・違反割合などの設定 「どこから異常と判断して通知するか？」の条件

1.指標（Metric）が一度も発生していないと候補に出てこない

  • Cloud Monitoring は直近データが存在するメトリクスしか UI に表示されないため、
    監視対象サービス：例Cloud Run がリクエストを受けていなかったり、4XX を1度も返していないと、対象メトリクスや response_code の選択肢が出てきません
    これは暗黙的な仕様で、とってもわかりにくく感じました

  • response_code の候補も “実際に出た値” しか表示されない
    4XX をまとめて検知したかったのですが、UI では出現済みのコード（200 など）しか表示されず、4XX が選択できない状態でした。
    response_code のところで、「正規表現 ^4.* 」を直接入れる必要がありました。

2.集計（Transform） のローリングウィンドウは最小 1 分

  • Cloud Monitoring では秒単位の集計ができず、最小 1 分のローリングウィンドウとなります。そのため、数秒間の瞬間的なスパイクはリアルタイムには検知できません。

3.集計（Transform）はrateでの判定になるため直観とズレる

  • Cloud Run のリクエスト系メトリクスは “counter 型” のため、Cloud Monitoring では自動的に rate（1秒あたり何件発生したか）に変換されます。そのため、件数（◯件発生）ではなく「1/s（1秒あたり◯件）」で閾値を決める必要があります。

今回のケースでも、実際には1分間の平均レートが 1/s を超えたらアラート という設定になりました。ただしこの場合、「どの程度のレートが “異常” といえるのか？」の判断が直感的でなく、
件数ベースで考えていた従来の感覚とズレており、"レート換算"に慣れていないためか？閾値の決定にかなり悩みました。

4.1分平均で判定するため、急増してもアラートは最大60秒遅れる

2にも関連しますが、最小1分での検知となるため、3秒だけ1000件/秒のような爆発的スパイクも最終的には平均値に反映されますが、アラートが鳴るのは最大60秒後です。

5. トリガー（Trigger）の「違反している時系列の最小割合」1% の意味が分かりにくい（参考程度の理解でよき）

Cloud Monitoring では、メトリクスが複数の時系列（リージョン別・リビジョン別など）に分かれている場合に、どの程度の割合が閾値を超えたらアラートにするかを指定できます。

ただし、今回のように 例Cloud Run の特定サービス（A）の 4XX だけを対象にしている場合、
時系列は1本だけになるため、この設定は実質的に挙動へ影響しません。

UI に表示されていて少し紛らわしい項目ですが、単一サービスを監視する場合は
デフォルトの「1%」のままで問題ありません。

6. 全体的にUI が抽象的で、どの設定が何を意味しているのか分かりにくい

  • 特に Metric / Filter / Transform / Trigger の用語が抽象的で、目的どおりの設定になるまで試行錯誤が必要でした...

最後に

Google Cloudサービスを利用する機会が増えてきましたが、Googleのドキュメントを見てもわからないことが多く、検証しながら進めております。少しでもお役にたてる場面があればうれしいです。

Discussion