## はじめに

Cloud Run でサービスを運用していると、「エラーが起きていたのに気づかなかった」という経験はないでしょうか。ログを毎日目視で確認するのは現実的ではありませんし、障害の検知が遅れればユーザーへの影響も大きくなります。

Google Cloud には Cloud Logging と連携したアラートポリシーの仕組みがあり、特定の条件に合致するログが発生した際に自動で通知を受け取ることができます。実はこのアラートポリシーには3種類の方式があり、それぞれ得意な場面が異なります。

本記事では、Cloud Run を題材に、3種類のアラートポリシーの特徴と設定方法を Google Cloud コンソール（GUI）と Terraform の両面から解説します。

---

## Cloud Logging のアラートポリシーとは

Cloud Logging では、以下の3種類のアラートポリシーを利用できます。

| 種類 | トリガー条件 | ユースケース | 特徴 |
| :----------------------- | :------------------------------- | :----------------------------------------- | :--------------------- |
| ログベースのアラート | 特定のログエントリが出現 | セキュリティイベント、重大エラーの即時検知 | シンプル、即時性が高い |
| ログベースの指標アラート | ログから作成した指標が閾値を超過 | エラー率の監視、一定期間の集計 | 統計的、柔軟な閾値設定 |
| SQL ベースのアラート | SQL クエリの結果 | 複雑なパターン分析、複数ログの結合 | 高度な分析が可能 |

簡単に言えば、「このエラーが出たらすぐ知りたい」ならログベース、「5分間にエラーが10件以上なら知りたい」なら指標ベース、「複雑な条件で集計して判定したい」なら SQL ベースが適しています。

---

## 事前準備：通知チャンネルの設定

アラートポリシーを作成する前に、通知先となるチャンネルを設定しておきましょう。ここではメール通知を設定します。

### コンソールでの設定

1. Google Cloud コンソールで Monitoring > アラート を開く
2. 上部の「通知チャンネルを編集」をクリック
3. Email の「ADD NEW」からメールアドレスと表示名を登録
4. テスト通知を送信して、正しく届くことを確認

> Tips: メール以外にも Slack、PagerDuty、Webhook など[多数の通知チャンネル](https://cloud.google.com/monitoring/support/notification-options?hl=ja)に対応しています。

### Terraform での設定

以降の Terraform コード例で共通で使用する通知チャンネルの定義です。

```hcl
resource "google_monitoring_notification_channel" "email" {
 display_name = "Email - ops-team"
 type = "email"
 labels = {
 email_address = "ops-team@example.com"
 }
}
```

---

## 1. ログベースのアラート

### 概要

最もシンプルなアラート方式です。ログエクスプローラで定義したフィルタに一致するログエントリが発生するたびに通知されます。

向いているケース:

- セキュリティ上重要なイベント（不正アクセスの試行など）
- 発生頻度が低いが見逃せない重大エラー
- 特定のメッセージやステータスコードの検知

制限事項:

- ポリシーごとに5分に1件のインシデントが上限
- ポリシーごとに1日最大20件のインシデント
- フォルダ・請求先アカウント・組織レベルのログは監視不可
- インシデントはデフォルト7日で自動クローズ

### コンソールから作成する

1. Logging > ログエクスプローラ を開く
2. クエリエディタに以下のフィルタを入力して「クエリを実行」をクリック

```
resource.type="cloud_run_revision"
resource.labels.service_name="my-service"
severity>=ERROR
```

3. 結果を確認したら、ヘッダーの「アラートを作成」>「ログエントリに基づくアラートを作成」をクリック
4. アラートの詳細を入力（アラート名: Cloud Run エラーログ検知、説明: 任意でアラートの目的を記載）
5. 通知先にメールを追加
6. 「保存」をクリック

### Terraform で作成する

```hcl
resource "google_monitoring_alert_policy" "cloud_run_log_alert" {
 display_name = "Cloud Run エラーログ検知"
 combiner = "OR"

 conditions {
 display_name = "Cloud Run ERROR ログの検出"
 condition_matched_log {
 filter = <<-EOT
 resource.type="cloud_run_revision"
 AND resource.labels.service_name="my-service"
 AND severity>=ERROR
 EOT
 }
 }

 notification_channels = [
 google_monitoring_notification_channel.email.name,
 ]

 alert_strategy {
 notification_rate_limit {
 period = "300s"
 }
 auto_close = "604800s"
 }
}
```

condition_matched_log がログベースのアラート専用のブロックです。alert_strategy の notification_rate_limit で通知間隔を制御できます（上記は5分間隔）。

---

## 2. ログベースの指標アラート

### 概要

ログからカスタム指標（メトリクス）を作成し、その指標に対して閾値ベースのアラートを設定する方式です。「5分間にエラーが10件以上」のような統計的な条件で通知したい場合に適しています。

設定は2ステップで行います：

1. ログベースの指標を作成 — ログエントリを数値データに変換
2. アラートポリシーを作成 — 指標に対して閾値を設定

### コンソールから作成する

#### ステップ1：ログベースの指標を作成

1. Logging > ログベースの指標 を開く
2. 「指標を作成」をクリック
3. 以下を設定（指標タイプ: カウンター、指標名: cloud-run-error-count）

```
resource.type="cloud_run_revision"
resource.labels.service_name="my-service"
severity>=ERROR
```

4. 「指標を作成」をクリック

#### ステップ2：アラートポリシーを作成

1. Monitoring > アラート を開き、「ポリシーを作成」をクリック
2. 「指標を選択」で logging.googleapis.com/user/cloud-run-error-count を選択
3. トリガーの条件を設定（条件タイプ: Threshold（閾値）、閾値: 10（5分間に10件以上でアラート））
4. 通知チャンネルにメールを追加して保存

### Terraform で作成する

```hcl
# ログベースの指標
resource "google_logging_metric" "cloud_run_error_count" {
 name = "cloud-run-error-count"
 filter = <<-EOT
 resource.type="cloud_run_revision"
 AND resource.labels.service_name="my-service"
 AND severity>=ERROR
 EOT
 metric_descriptor {
 metric_kind = "DELTA"
 value_type = "INT64"
 }
}

# 指標に対するアラートポリシー
resource "google_monitoring_alert_policy" "cloud_run_metric_alert" {
 display_name = "Cloud Run エラー率アラート"
 combiner = "OR"

 conditions {
 display_name = "5分間のエラー数が10件を超過"
 condition_threshold {
 filter = "metric.type=\"logging.googleapis.com/user/${google_logging_metric.cloud_run_error_count.name}\" AND resource.type=\"cloud_run_revision\""
 comparison = "COMPARISON_GT"
 threshold_value = 10
 duration = "300s"
 aggregations {
 alignment_period = "300s"
 per_series_aligner = "ALIGN_SUM"
 }
 }
 }

 notification_channels = [
 google_monitoring_notification_channel.email.name,
 ]
}
```

ログベースのアラートとの違いは、condition_threshold を使っている点です。duration と alignment_period で評価期間を指定し、threshold_value で閾値を設定します。

---

## 3. SQL ベースのアラート

### 概要

Log Analytics（ログ分析）を有効にした状態で、SQL クエリの結果に基づいてアラートを発行する最も高度な方式です。複数のログソースを結合した分析や、GROUP BY を使った集計など、柔軟な条件指定ができます。

前提条件: ログバケットで Log Analytics が有効化されている必要があります。

### コンソールから作成する

1. Logging > ログストレージ でログバケットの「Log Analytics をアップグレード」を有効化
2. Logging > ログ分析 を開く
3. SQL クエリを入力して「クエリを実行」で結果を確認

```sql
SELECT
 resource.labels.service_name AS service_name,
 COUNT(*) AS error_count
FROM
 `PROJECT_ID.global._Default._AllLogs`
WHERE
 resource.type = 'cloud_run_revision'
 AND severity >= 'ERROR'
 AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 10 MINUTE)
GROUP BY
 1
HAVING
 error_count > 20
```

4. クエリ結果が意図通りであれば、「アラートを作成」をクリック
5. 評価間隔や通知先を設定して保存

この例では、10分間にエラーが20件を超えた Cloud Run サービスを検出します。PROJECT_ID は実際のプロジェクト ID に置き換えてください。

### Terraform で作成する

Terraform では condition_sql ブロックを使って SQL ベースのアラートを定義できます。

```hcl
resource "google_monitoring_alert_policy" "cloud_run_sql_alert" {
 display_name = "Cloud Run SQL ベースアラート"
 combiner = "OR"

 conditions {
 display_name = "10分間のエラー数が20件を超過"
 condition_sql {
 query = <<-EOT
 SELECT
 resource.labels.service_name AS service_name,
 COUNT(*) AS error_count
 FROM
 `PROJECT_ID.global._Default._AllLogs`
 WHERE
 resource.type = 'cloud_run_revision'
 AND severity >= 'ERROR'
 AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 10 MINUTE)
 GROUP BY
 1
 HAVING
 error_count > 20
 EOT
 minutes {
 periodicity = 10
 }
 row_count_test {
 comparison = "COMPARISON_GT"
 threshold = "0"
 }
 }
 }

 notification_channels = [
 google_monitoring_notification_channel.email.name,
 ]
}
```

minutes.periodicity でクエリの評価間隔（分単位）を指定し、row_count_test でクエリ結果の行数に対する条件を設定します。

---

## 運用のポイント

アラートポリシーは「設定して終わり」ではなく、運用しながら調整していくものです。以下のポイントを意識すると、効果的な監視体制を構築できます。

### フィルタは具体的に

フィルタが広すぎると大量の通知が届き、重要なアラートが埋もれるアラート疲れの原因になります。service_name や severity は必ず絞り込みましょう。

### テスト通知を忘れずに

アラートポリシーを作成したら、意図的にエラーを発生させて通知が正しく届くか確認しましょう。通知チャンネルの設定ミスは意外と多いものです。

### ポリシーの一時停止を活用する

メンテナンス時は、コンソールからアラートポリシーをワンクリックで無効化できます。作業完了後に有効に戻すのを忘れないようにしましょう。

### 3種類の使い分け

| やりたいこと | おすすめの方式 |
| :------------------------------------- | :----------------------- |
| 特定のエラーが出たらすぐ知りたい | ログベースのアラート |
| 一定期間のエラー数で判断したい | ログベースの指標アラート |
| 複雑な条件や複数ログの結合で判断したい | SQL ベースのアラート |

迷ったら、まずはログベースのアラートから始めて、必要に応じて指標ベースや SQL ベースに移行するのがおすすめです。

---

## まとめ

本記事では、Cloud Logging の3種類のアラートポリシーについて、Cloud Run を題材に設定方法を解説しました。

- ログベースのアラート: 特定のログ出現を即座に検知。設定がシンプルで導入しやすい
- ログベースの指標アラート: ログをメトリクスに変換し、閾値で監視。統計的な判断が可能
- SQL ベースのアラート: SQL クエリによる高度な分析。複雑な条件も柔軟に対応

おすすめのフローは、まず GUI で試して動作を確認し、本番運用では Terraform でコード化することです。これにより設定の再現性が担保され、チームでのレビューも容易になります。

Cloud Run に限らず、GCE や Cloud SQL など他のサービスでも同様の仕組みでアラートを設定できるので、ぜひ自分のプロジェクトに合った監視設定を構築してみてください。

---

## 参考リンク

- [ログに基づくアラート ポリシーを構成する - Cloud Logging ドキュメント](https://cloud.google.com/logging/docs/alerting/log-based-alerts?hl=ja)
- [ログベースの指標の概要 - Cloud Logging ドキュメント](https://cloud.google.com/logging/docs/logs-based-metrics?hl=ja)
- [SQL クエリ結果をモニタリングする - Cloud Logging ドキュメント](https://cloud.google.com/logging/docs/analyze/sql-in-alerting?hl=ja)
- [google_monitoring_alert_policy - Terraform Registry](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/monitoring_alert_policy)
- [google_logging_metric - Terraform Registry](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/logging_metric)

large_eyecatch.jpg

medium_eyecatch.jpg

small_eyecatch.jpg

thumbnail_eyecatch.jpg

eyecatch.jpg

Cloud Logging のアラートポリシーを活用して Cloud Run を監視しよう

## はじめに

Google Cloud 上でバッチ処理を行う際に、[Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)を使用したので紹介します。
本記事では、他サービスとの比較と[Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)の使い方について説明します。

## Google Cloud でバッチ処理できるサービス

Cloud Run jobs を使用するにあたって、他のサービスについても調べたのでそれぞれの特徴をまとめました。

### [Cloud Functions](https://cloud.google.com/functions)

様々なイベントをトリガーにできるので、特定のイベントが発生したときに動かしたいバッチ処理の場合は Cloud Functions を使うと良さそうです。
例えば [Cloud Storage](https://cloud.google.com/storage) に画像がアップロードされた際に、自動的にサムネイルを作成したり、画像にフィルターをかけたりする処理が簡単に作れます。
しかし、最大実行時間に制限(60 分)があるため長時間の処理には適さない場合があります。

### [Batch](https://cloud.google.com/batch)

大規模なバッチ処理ワークロードを効率的に実行するためのフルマネージドなサービスです。
高性能コンピューティング（HPC）、機械学習、データ処理など、さまざまな種類のバッチジョブをスケーラブルかつ柔軟に実行できます。
また、最大実行時間に制限が無いので長時間の処理に適しています。
しかし、Cloud Functions や Cloud Run jobs よりも設定が複雑になってしまうので採用しませんでした。

### [Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)

Cloud Run の一機能で、バッチ処理や非同期タスクの実行に特化したサービスです。
最大実行時間に制限がありますが、24 時間実行できるのでほとんどのバッチ処理は問題ないでしょう。

## Cloud Run jobs の基本要素

### Cloud Run jobs のリソース構造

Cloud Run jobs は以下のようなリソースで構成されています。 
 ![リソース構造](https://cont.sterfield.co.jp/uploads/resource_a778e2a692.jpg) 

### ジョブ (Job)

実行したいタスクの全体像を定義するルートリソースです。

ジョブでは以下の項目を設定できます。

- コンテナイメージ
- タスク数
- 並列実行数
- リソース(各タスクに割り当てる CPU やメモリなどのリソース量)
- 環境変数
- サービスアカウント

### タスク (Task)

ジョブによって定義されたタスクのインスタンスです。
タスクはジョブに設定された数だけ実行されます。コンテナインスタンスを 1:1 で用意し、コンテナインスタンスごとの進捗を管理します。タスクがエラーで終了した場合は、タスク単位で再実行もできます。

### 実行 (Execution)

タスクの実行履歴です。
ジョブの設定に応じてタスクを実行し、全てのタスクが完了するまでの状態を管理します。1 度作成した実行は、何度でも再実行が可能です。

## Cloud Run jobs の作成・実行方法

### サンプルアプリケーションの用意

以下のコードを適当なフォルダに作成します

環境変数に`SLEEP_MS`を設定すると、設定した時間だけスリープするようになり、時間のかかる処理を再現できます。
`FAIL_RATE`を設定すると、指定した確率でジョブがエラーになり、エラー時の挙動を確認できます。

main.js

```js
// Retrieve Job-defined env vars
const { CLOUD_RUN_TASK_INDEX = 0, CLOUD_RUN_TASK_ATTEMPT = 0 } = process.env;
// Retrieve User-defined env vars
const { SLEEP_MS, FAIL_RATE } = process.env;

// Define main script
const main = async () => {
 console.log(
 `Starting Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT}...`
 );
 // Simulate work
 if (SLEEP_MS) {
 await sleep(SLEEP_MS);
 }
 // Simulate errors
 if (FAIL_RATE) {
 try {
 randomFailure(FAIL_RATE);
 } catch (err) {
 err.message = `Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT} failed.\n\n${err.message}`;
 throw err;
 }
 }
 console.log(`Completed Task #${CLOUD_RUN_TASK_INDEX}.`);
};

// Wait for a specific amount of time
const sleep = (ms) => {
 return new Promise((resolve) => setTimeout(resolve, ms));
};

// Throw an error based on fail rate
const randomFailure = (rate) => {
 rate = parseFloat(rate);
 if (!rate || rate < 0 || rate > 1) {
 console.warn(
 `Invalid FAIL_RATE env var value: ${rate}. Must be a float between 0 and 1 inclusive.`
 );
 return;
 }

 const randomFailure = Math.random();
 if (randomFailure < rate) {
 throw new Error("Task failed.");
 }
};

// Start script
main().catch((err) => {
 console.error(err);
 process.exit(1); // Retry Job Task by exiting the process
});
```

package.json

```json
{
 "main": "main.js",
 "scripts": {
 "start": "node main.js"
 },
 "engines": {
 "node": ">=20.0.0"
 }
}
```

Dockerfile

```Dockerfile
FROM node:20
WORKDIR /app
COPY . .
RUN npm install
CMD [ "npm", "start" ]
```

### コンテナをプッシュ

次のコマンドで [Artifact Registry](https://cloud.google.com/artifact-registry) にコンテナをプッシュします。`${REGION}`と`${PROJECT_ID}`は各自で置き換えてください。

```
gcloud builds submit --tag ${REGION}-docker.pkg.dev/${PROJECT_ID}/gcr.io/job-sample
```

### ジョブを作成

今回は、以下の Cloud Run のコンソールから作成します。 
https://console.cloud.google.com/run/jobs

「ジョブの作成」をクリックします。 
 ![ジョブの作成ボタン](https://cont.sterfield.co.jp/uploads/job_create_1_691d934c36.png) 

「コンテナ イメージの URL」に先ほど作成したコンテナを選択します。
イメージ名が自動的に設定されます。
リージョンやタスク数はお好みで設定して下さい。 
 ![ジョブの詳細](https://cont.sterfield.co.jp/uploads/job_create_2_c2c65e6a14.png) 

### ジョブの実行

「実行」をクリックし、ジョブを開始します。 
 ![実行ボタン](https://cont.sterfield.co.jp/uploads/job_create_3_3049895faf.png)

しばらく経つと、全てのタスクが完了し、実行が完了します。実行の詳細を開くとタスクが完了していることが確認でき、各タスクのログ等が確認できます。 
 ![タスク](https://cont.sterfield.co.jp/uploads/job_create_4_6281075873.png) 

### 作成した Job を定期実行する方法

「トリガー」タブを選択し、「スケジューラ トリガーを追加」をクリックします。 
 ![トリガー追加ボタン](https://cont.sterfield.co.jp/uploads/scheduler_1_1e1f8511c4.png) 

頻度を unix-cron 形式で選択します。
今回は 5 分ごと(`*/5****`)に実行してみます。 
 ![トリガー詳細](https://cont.sterfield.co.jp/uploads/scheduler_2_f70181ea5b.png) 

指定した通り、5 分ごとにジョブが実行されました。 
 ![ジョブ一覧](https://cont.sterfield.co.jp/uploads/scheduler_3_69acf4aa19.png) 

## まとめ

今回は Cloud Run jobs について説明しましたが、各サービスのメリット・デメリットを比較し、要件に合った最適なサービスを選択することが重要です。
今後、他サービスにも触れる機会がありましたら紹介したいです。

## 参考

- https://speakerdeck.com/satohjohn/gcptenohatutichu-li-hatanwokao-etemiru
- https://zenn.dev/google_cloud_jp/articles/cloudrun-jobs-basic
- https://cloud.google.com/run/docs/quickstarts/jobs/build-create-nodejs

small_cloud-run.png

thumbnail_cloud-run.png

cloud-run.png

Cloud Run jobs を利用したバッチ処理

Company

Our Solutions

Support

News

Blog

Blogブログ

カテゴリーから探す

年別から見る

記事一覧 - タグ: #CloudRun

2026/04/10

2024/08/02