このページは Cloud Translation API によって翻訳されました。

ログベースのアラートポリシーを構成する

含まれているログに特定のメッセージが現れるたびに通知されるようアラートポリシーを構成できます。たとえば、監査ログに特定のデータアクセスメッセージが記録されたことを知りたい場合は、そのメッセージが現れたときに通知を受け取ることができます。これらのタイプのポリシーは、ログベースのアラートポリシーと呼ばれます。このドキュメントでは、Google Cloud Console と Cloud Monitoring API を使用して、次のことを行う方法について説明します。

ログベースのアラートポリシーを作成してテストする。
ログベースのアラートポリシーを編集する。
ログベースのアラートポリシーを削除する。

始める前に

アラートの比較を確認して、ログベースのアラートがログのデータに適しているかどうかを確認します。次に例を示します。

ログベースのアラートポリシーは、除外されたログに対しては機能しません。
ログベースのアラートポリシーを使用して、ログからカウントを取得することはできません。カウントを取得するには、代わりにログベースの指標を使用する必要があります。

ログベースのアラートポリシーを作成して管理するには、Identity and Access Management のロールに、ログベースのアラートポリシーの権限で説明されている権限が必要です。

ログエクスプローラを使用してログベースのアラートポリシーを作成する

ログベースのアラートポリシーは、Google Cloud コンソールの [ログエクスプローラ] ページで作成するか、Monitoring API を使用して作成できます。このセクションでは、ログエクスプローラを使用してログベースのアラートポリシーを作成する方法について説明します。Monitoring API の詳細については、Monitoring API を使用してログベースのアラートポリシーを作成するをご覧ください。

ログエクスプローラのインターフェースでは、次の手順でアラートの作成、編集が可能です。

アラートポリシーの名前と説明を入力します。
ログを選択します（これらのログに関する通知を受け取ります）。
通知の間隔を設定します。
インシデントの自動クローズまでの時間を設定します。
通知先のユーザーを指定します。

たとえば、アプリケーションがネットワークアドレスを変更したときに、重大度が NOTICE の syslog ログエントリを書き込むアプリケーションがあるとします。ネットワークアドレス変更のログエントリには、次のような JSON ペイロードが含まれています。

"jsonPayload": {
  "type": "Configuration change",
  "action": "Set network address",
  "result": "IP_ADDRESS",
}

無効な IPv4 アドレスが、重大度が NOTICE で syslog のログエントリの jsonPayload.result フィールドに表示された場合に通知するログベースのアラートポリシーを作成します。

アラートポリシーを作成するには、次の手順を行います。

Google Cloud コンソールで、[ログエクスプローラ] ページに移動します。
[ログエクスプローラ] に移動

検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。
[クエリ] ペインを使用して、ログベースのアラートポリシーで使用するメッセージに一致するクエリを作成します。

たとえば、syslog　ログの中の重大度が NOTICE のログエントリのうち、JSON ペイロードに無効な IP アドレスがあるものを見つけるには、次のクエリを使用します。
```
log_id("syslog")
severity = "NOTICE"
jsonPayload.result !~ "^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}$"
```
[クエリを実行] をクリックしてクエリを検証します。
[クエリ結果] ツールバーで [アクション] メニューを開き、 [ログアラートの作成] を選択します。
[アラートの詳細] ペインで、アラートポリシーの名前と説明を入力します。
1. [アラートポリシー名] フィールドにアラートポリシーの名前を入力します。たとえば、「ネットワークアドレス: 無効な IPv4 値」などです。
2. [Policy severity level] メニューからオプションを選択します。インシデントや通知に重大度レベルが表示されます。
3. アラートポリシーに関する説明を入力します。通知の受信者が問題を診断する際に有用な情報を表示することもできます。次の文字列では、アラートの理由を要約しています。
```
Log-based alerting policy in project ${project} detected an invalid IPv4 value.
```
  このフィールドの内容のフォーマットと調整の詳細については、ドキュメントテンプレートでマークダウンと変数を使用するをご覧ください。
次のステップに進むには、[次へ] をクリックします。
[アラートに含めるログを選択] ペインで、[ログをプレビュー] をクリックしてクエリと結果を確認します。

ログエクスプローラの [クエリ] ペインでクエリを作成することをおすすめします。[クエリ] ペインで作成したクエリもこのペインに表示されます。次に例を示します。
```
log_id("syslog")
severity = "NOTICE"
jsonPayload.result !~ "^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\.|$)){4}$"
```
必要に応じて、このペインでクエリを編集できます。クエリを編集する場合は、[ログをプレビュー] をクリックして結果を確認します。
[次へ] をクリックします。
通知間の最小時間を選択します。この値により、この条件が複数回満たされた場合に Monitoring から受信する通知の数を制御できます。この例では、オプションから [5 minute] を選択します。
省略可: インシデントの自動クローズ期間を選択します。デフォルトでは、インシデントの自動クローズ期間は 7 日に設定されています。
[次へ] をクリックします。
アラートポリシーの通知チャンネルを 1 つ以上選択します。この例では、メール通知チャンネルを選択します。

すでにメール通知チャンネルを構成している場合は、リストからそれを選択できます。そうでない場合は、[通知チャンネルを管理] をクリックしてメールチャンネルを追加します。通知チャンネルの作成については、通知チャンネルの作成と管理をご覧ください。
[保存] をクリックします。

これで、ログベースのアラートポリシーをテストできるようになりました。

ログベースのアラートポリシーの例をテストする

作成したアラートポリシーをテストするには、クエリに一致するログエントリを手動で記述します。ログエントリを記述するには、次のようにします。

次のログエントリを、PROJECT_ID 変数はプロジェクト ID に変更して構成します。

{
  "entries": [
  {
    "logName": "projects/PROJECT_ID/logs/syslog",
    "jsonPayload": {
      "type": "Configuration change",
      "action": "Set network address",
      "result": "999.027.405.1",
    },
    "severity": "NOTICE",
    "resource": {
      "type": "generic_task",
      "labels" : {
        "project_id": "PROJECT_ID",
        "location": "us-east1",
        "namespace": "fake-task-2",
        "job": "write-log-entry",
        "task_id": "11",
      },
    },
  },
  ],
}

logEntries.write リファレンスページに移動するか、次のボタンをクリックします。

logEntries.write に移動
構成したログエントリをコピーします。
[この API を試す] ペインで、次の手順を行います。
1. API Explorer の [リクエスト本文] フィールドの内容を、前の手順でコピーしたログエントリに置き換えます。
2. [実行] をクリックします。入力を求めるメッセージが表示されたら、認証フローに従います。
  
  logEntries.write の呼び出しが成功すると、HTTP 200 レスポンスコードと空のレスポンスの本文 {} が返されます。API Explorer の詳細については、Monitoring のドキュメントの API Explorer の使用をご覧ください。 API Explorer の動作は Logging API と同じです。

ログエントリは、次の方法でアラートポリシーに指定されたフィルタと一致します。

logName 値は、Google Cloud プロジェクトにある syslog ログを指定します。
このログエントリの severity 値は NOTICE です。
jsonPayload.result 値が有効な IPv4 アドレスではありません。

ログエントリを書き込むと、次のシーケンスが発生します。

新しいログエントリがログエクスプローラに表示されます。ログエントリがアラートポリシーの条件を満たしている。
インシデントが Cloud Monitoring で開かれます。
インシデントの通知が届きます。メール通知チャネルを構成した場合、通知は次のスクリーンショットのようになります。

メール内の [インシデントを表示] をクリックすると、Cloud Monitoring でインシデントを確認できます。インシデントの詳細については、ログベースのアラートポリシーのインシデントを管理するをご覧ください。

その他のシナリオ: 監査ログに関するアラート

ログベースのアラートポリシーの作成というタイトルのセクションの例は人為的なものです。通常、アラートポリシーを作成して、アラートポリシーの条件を満たすログエントリを手動で書き込むことはありません。たいていログエントリは、アプリケーションか、他のサービスによって書き込まれます。ただし、ログエントリの発生元は重要ではありません。ログベースのアラートポリシーでは、ログエントリの選択に使用するクエリが重要です。

以降のセクションでは、ログベースのアラートポリシーの現実的なシナリオを、監査ログの内容に基づいて説明します。各シナリオでは、適切な監査ログエントリを選択するクエリを作成する方法を説明します。それ以外の場合、ログベースのアラートポリシーの作成手順は、ログベースのアラートの作成と同じです。

シークレットの人的アクセスをモニタリングするアラートポリシー

たとえば、プロジェクト内でシークレットを Secret Manager に保存し、一部のシークレットがサービスアカウント専用で使用されるとします。特殊な状況を除き、人間のユーザーがこれらのシークレットにアクセスすることはありません。

Secret Manager の監査ロギングが有効になっていると、シークレットへのアクセスが試されるたびに、監査ログエントリが作成されます。各エントリには、シークレットの名前と呼び出し元の ID が含まれています。

人間のユーザーがシークレットにアクセスしたときに通知されるログベースのアラートポリシーを作成できます。

以下は、Secret Manager によって書き込まれた監査ログエントリの抜粋です。この抜粋は、ログベースのアラートのクエリの作成に役立つフィールドを示しています。

{
  "protoPayload": {
    "@type": "type.googleapis.com/google.cloud.audit.AuditLog",
    "serviceName": "secretmanager.googleapis.com",
    "methodName": "google.cloud.secretmanager.v1.SecretManagerService.AccessSecretVersion",
    "authenticationInfo": {
      "principalEmail": "my-svc-account@PROJECT_ID.iam.gserviceaccount.com",
      "serviceAccountDelegationInfo": [],
      "principalSubject": "serviceAccount:my-svc-account@PROJECT_ID.iam.gserviceaccount.com"
    },
    ...
  },
  ...
}

次の protoPayload サブフィールドが、特に重要です。

@type: このログエントリが監査ログエントリであることを示します。
serviceName: 監査ログエントリを書き込んだサービスを記録します。このフィールドは、Secret Manager によって書き込まれたエントリを識別するために使用します。
methodName: この監査ログエントリが書き込まれたメソッドを識別します。このフィールドを使用して、このエントリが作成されるアクションを識別します。この例では、AccessSecretVersion メソッドです。
authenticationInfo.principalEmail: メソッドを呼び出したアカウントを methodName フィールドに記録します。このフィールドの想定値はサービスアカウントであり、末尾は gserviceaccount.com です。

人間のユーザーによる Secret アクセスのログエントリを見つけるには、Secret Manager によって書き込まれた監査ログエントリを探します。gserviceaccount.com で終わるプリンシパルによって AccessSecretVersion メソッドが呼び出されたログエントリを確認する必要があります。次のクエリは、これらのログエントリを分離します。

protoPayload.@type = "type.googleapis.com/google.cloud.audit.AuditLog"
protoPayload.serviceName = "secretmanager.googleapis.com"
protoPayload.methodName =~ "AccessSecretVersion$"
protoPayload.authenticationInfo.principalEmail !~ "gserviceaccount.com$"

シークレットの人間によるアクセスに関するログベースのアラートポリシーを作成するには、[アラートに含めるログを選択する] ペインでこのクエリを使用します。

復号イベントをモニタリングするアラートポリシー

前の例の分析は、他のサービスにも適用できます。たとえば、Cloud Key Management Service を使用して機密データを暗号化および復号する場合、Cloud KMS によって生成された監査ログを使用して、人間のユーザーによる値の復号を検出します。

人間のユーザーが復号したことを示すログエントリを見つけるには、Cloud KMS によって書き込まれた監査ログエントリを探します。見つける必要があるログエントリは、末尾が gserviceaccount.com（サービスアカウント）以外のプリンシパルが呼び出した Decrypt メソッドのログエントリです。次のクエリは、これらのログエントリを分離します。

protoPayload.@type = "type.googleapis.com/google.cloud.audit.AuditLog"
protoPayload.serviceName = "cloudkms.googleapis.com"
protoPayload.methodName = "Decrypt"
protoPayload.authenticationInfo.principalEmail !~ "gserviceaccount.com$"

人間のユーザーが行う復号に対するログベースのアラートポリシーを作成するには、[アラートに含めるログを選択する] ペインでこのクエリを使用します。

Monitoring でログベースのアラートポリシーを管理する

Monitoring 用の Google Cloud コンソールまたは Monitoring API を使用して、ログベースのアラートポリシーの表示、編集、削除を行うことができます。このドキュメントでは、Google Cloud コンソールを使用してアラートポリシーを管理する方法について説明します。Monitoring API を使用してアラートポリシーを管理する方法については、API によるアラートポリシーの管理をご覧ください。

Google Cloud プロジェクトのすべてのアラートポリシーを一覧表示するには、次のいずれかを行います。

Logging から移動するには:
1. Google Cloud コンソールで、[ログエクスプローラ] ページに移動します。
  [ログエクスプローラ] に移動
  
  検索バーを使用してこのページを検索する場合は、小見出しが [Logging] の結果を選択します。
2. [クエリ結果] ツールバーで [アクション] メニューを開き、 [ログアラートを管理] を選択します。
Monitoring から移動するには:
1. Google Cloud コンソールで、 [アラート] ページに移動します。
  [アラート] に移動
  
  検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。
2. すべてのポリシーを表示してフィルタを有効にするには、[ポリシー] ペインで [すべてのポリシーを表示] をクリックします。

どちらの操作でも Monitoring の [ポリシー] ページが表示され、Google クラウドプロジェクトのすべてのアラートポリシーが一覧表示されます。

一覧表示されるアラートポリシーを制限するには、フィルタを追加します。各フィルタは、名前と値で構成されています。たとえば、値をポリシー名の完全一致か、部分一致に設定できます。一致の判定で、大文字と小文字は区別されません。複数のフィルタを指定すると、OR フィルタを挿入しない限り、暗黙的に論理 AND で結合されます。次のスクリーンショットは、2021 年 1 月 1 日以降に作成され、有効になっているアラートポリシーを示しています。

2021 年 1 月 1 日以降に作成された有効なアラートポリシーのリスト。

[ポリシー] ページでは、アラートポリシーを編集、削除、コピー、有効化、無効化できます。

ポリシーを編集またはコピーするには、 [その他のオプション] をクリックして、オプションを選択します。ポリシーを編集してコピーする方法は、ログベースのアラートポリシーを作成する方法と似ています。フィールドの値を変更したり、場合によっては削除したりできます。完了したら、[Save] をクリックします。

ログベースのアラートポリシーは、ポリシーのリストの名前をクリックして編集することもできます。
ポリシーを削除するには、[その他のオプション] をクリックし、[削除] を選択します。確認ダイアログで [削除] を選択します。
アラートポリシーを有効または無効にするには、[有効] 項目下にある切り替えボタンをクリックします。

Monitoring API を使用してログベースのアラートポリシーを作成する

ログベースのアラートポリシーは、Monitoring API を使用して作成できます。Google Cloud コンソールでログエクスプローラを使用する場合と同じ情報を Monitoring API に渡します。

アラートポリシーの名前と説明。
通知を受け取るログ。
通知の間隔。
インシデントの自動クローズまでの時間。
通知するユーザ。

Monitoring API を使用してアラートポリシーを作成するには、AlertPolicy オブジェクトを作成し、alertPolicies.create メソッドに送信します。

Monitoring API を使用する前に、API を有効にし、その使用を承認する必要があります。詳細については、以下のドキュメントをご覧ください。

アラートポリシーの構造

Monitoring API では、AlertPolicy 構造を使用してアラートポリシーを表します。AlertPolicy 構造には、アラートポリシーの条件の説明など、いくつかの埋め込み構造があります。ログベースのアラートポリシーは、以下の点で指標ベースのアラートポリシーと異なります。

条件を記述するには、LogMatch 条件タイプを使用します。指標ベースのアラートポリシーでは、異なる条件タイプが使用されます。
ログベースのアラートポリシーに含めることができる条件は 1 つのみです。
通知から自動インシデント終了までの時間は、AlertStrategy 構造体を追加して指定します。指標ベースのアラートポリシーには、通知間の時間は含まれません。

このセクションでは、ログベースのアラートポリシーの作成方法について説明します。これらのポリシーは、使用する条件のタイプにおいて、指標ベースのアラートポリシーと異なります。ログベースのアラートポリシーの場合、条件タイプは LogMatch です。Monitoring API を使用してアラートポリシーを管理する場合、指標ベースとログベースのポリシーを一覧表示、編集、削除する方法に違いはありません。API によってアラートポリシーを管理するでは、Monitoring API を使用してアラートポリシーを作成、一覧表示、編集、削除する方法について説明しています。

通知ルール

ログベースのアラートポリシーを作成すると、Logging によって通知ルールという内部オブジェクトが作成されます。ロギングでは、通知ルールを使用して受信ログエントリをアラートポリシーのフィルタと照合し、エントリがフィルタ条件と一致すると通知を作成します。通知ルールを直接操作することはありません。ただし、ログベースのアラートポリシーを作成するには、logging.notificationRules.create 権限が必要です。

アラートポリシーを設計する

ログエクスプローラを使用してログベースのアラートポリシーを作成するという題名のセクションでは、ログベースのアラートポリシーを作成する方法の 1 つが説明されています。このセクションでは、syslog ログエントリの重大度が NOTICE で、jsonPayload.result に無効な IPv4 アドレスがある場合に通知するログベースのアラートポリシーを作成する方法を示しています。

Monitoring API を使用して同じログベースのアラートポリシーを作成するには、次の JSON 構造のような AlertPolicy オブジェクトを作成します。

{
  "displayName": "Network address: invalid IPv4 value (API)",
  "documentation": {
    "content": "Log-based alerting policy in project ${project} detected an invalid IPv4 value.",
    "mimeType": "text/markdown"
  },

  "conditions": [
    {
      "displayName": "Log match condition: invalid IP addr (API)",
      "conditionMatchedLog": {
        "filter": "log_id(\"syslog\") severity = \"NOTICE\" jsonPayload.result !~ \"^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\\.|$)){4}$\"",
      },
    }
  ],
  "combiner": "OR",

  "alertStrategy": {
    "notificationRateLimit": {
      "period": "300s"
    },
    "autoClose": "604800s",
  },

  "notificationChannels": [
    "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
  ]
}

この JSON コードは、ログエクスプローラを使用したログベースのアラートポリシーの作成で指定するものと同じ情報を指定します。次のセクションでは、この AlertPolicy 構造の内容を、ログエクスプローラを使用してログベースのアラートを作成する手順にマッピングします。conditionMatchedLog フィールドの値は LogMatch 構造です。

名前と説明を入力する

アラートポリシーには、応答者に役立つ通知を提供する表示名と関連するドキュメントがあります。ログエクスプローラでは、これらの項目を、アラート名とアラートの説明と呼んでいます。これらの値は、AlertPolicy 構造で次のように表現します。

{
  "displayName": "Network address: invalid IPv4 value (API)",
  "documentation": {
    "content": "Log-based alerting policy in project ${project} detected an invalid IPv4 value.",
    "mimeType": "text/markdown"
  },
  ...
}

この例では、Cloud Console でポリシーのリストを表示するときに 2 つのサンプルポリシーが区別できるように、displayName の値に「(API)」が含まれています。Monitoring の [ポリシー] ページには、表示名でポリシーが表示され、ポリシーが指標とログのどちらに基づくかが表示されます。詳細については、Monitoring でログベースのアラートポリシーを管理するをご覧ください。

documentation フィールドの content サブフィールドには、ログエクスプローラを使用する際に指定する説明が含まれます。documentation フィールドの値を指定する場合、2 番目のサブフィールド mimeType は必須です。有効な値は "text/markdown" のみです。

通知を受け取るログを選択する

ログベースのアラートポリシーには単一の条件があります。ログエクスプローラの [アラート対象のログエントリを定義する] フィールドにクエリを指定するときに、条件を指定します。これらの値は、AlertPolicy 構造で次のように表現します。

{ ...
  "conditions": [
    {
      "displayName": "Log match condition: invalid IP addr (API)",
      "conditionMatchedLog": {
        "filter": "log_id(\"syslog\" severity = \"NOTICE\" jsonPayload.result !~ \"^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\\.|$)){4}$\"",
      },
    }
  ],
  "combiner": "OR",
  ...
}

conditions フィールドは Condition 構造のリストを受け取りますが、ログベースの指標には条件が 1 つのみ必要です。各 Condition には、条件の表示名と説明があります。

displayName フィールドの値は、条件の簡単な説明です。ログエクスプローラを使用してログベースのアラートポリシーを作成する場合、表示名は常に「Log match condition」です。Monitoring API を使用すると、より正確な表示名を指定できます。値を指定する必要があります。
conditionMatchedLog フィールドの値は LogMatch 構造であり、filter フィールドの値はログエクスプローラで指定したクエリです。このクエリは JSON フィールドの値として指定されるため、クエリ全体が引用符で囲まれており、クエリ自体の引用符は \（バックスラッシュ）文字でエスケープする必要があります。
LogMatch 構造には、オプションの labelExtractors フィールドも含まれています。ラベルの抽出式を使用すると、ログエントリからカスタムラベルを作成し、通知でラベルを参照できます。

注: timestamp ラベルは抽出しないでください。このラベルを抽出すると、アラートポリシーはインシデントを作成したり通知を送信したりしません。
たとえば、ログエントリからラベル labels."compute.googleapis.com/resource_id" の値を vm_identifier というラベルに抽出するには、前の条件が次のようになります。
```
"conditions": [
  {
    "displayName": "Log match condition: invalid IP addr (API)",
    "conditionMatchedLog": {
      "filter": "log_id(\"syslog\" severity = \"NOTICE\" jsonPayload.result !~ \"^((25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)(\\.|$)){4}$\")",
      "labelExtractors": {
        "vm_identifier": "EXTRACT(labels.\"compute.googleapis.com/resource_id\")"
      }
    },
  }
],
```
EXTRACT 関数を使用して値全体を照合するか、REGEXP_EXTRACT を使用して正規表現に基づいて部分文字列を照合します。これらは、ログベースの指標でラベル抽出に使用されるものと同じ関数です。詳細については、ラベルの作成をご覧ください。

これらの抽出したラベルはアラートポリシーのドキュメントで使用することができ、通知で報告されます。アラートポリシーの documentation フィールドでは、${log.extracted_label.KEY} という形式の変数を使用して抽出されたラベルを参照します。ここで、KEY は、抽出されたラベルに付与した名前です。

次の例は、抽出されたラベル vm_identifier のキーを参照する方法を示します。これにより、ログラベル labels."compute.googleapis.com/resource_id" の値が通知に含まれるようになります。
```
"documentation": {
  "content": "Log-based alerting policy in project ${project} detected an
   invalid IPv4 value on VM with ID ${log.extracted_label.vm_identifier}.",
  "mimeType": "text/markdown"
},
```

combiner フィールドの値は、指標ベースのアラートポリシーで複数の条件の結果を組み合わせる方法を指定します。ログベースのアラートポリシーでは 1 つの条件のみを使用できます。また、combiner フィールドに値 "OR" を指定する必要があります。複数の条件でログベースのアラートポリシーを作成できません。

通知と自動クローズの値を設定する

ログベースのアラートポリシーは、通知間の最小時間を指定します。ログエクスプローラでは、[通知間の時間] メニューから値を選択します。AlertPolicy 構成のこの値は、AlertStrategy 構造体に埋め込まれた NotificationRateLimit 構造体の period フィールドに、値（秒）を指定することで表します。

同様に、アラートポリシーには、インシデントを自動的にクローズする期間が含まれています。デフォルト値は 7 日です。ログエクスプローラでは、[インシデントの自動クローズ期間] メニューから別の値を選択できます。このオプションは、AlertStrategy API 構造の autoclose フィールドに対応します。このフィールドを使用する場合は、値を秒単位で指定します。最小値は 1,800 秒（30 分）です。

{ ...
  "alertStrategy": {
    "notificationRateLimit": {
      "period": "300s"
    },
    "autoClose": "604800s",
  },
  ...
}

この例の period フィールドの値 300s は、5 分に相当します。autoclose の値（604800s）は、7 日間に相当します。

通知するユーザーを指定する

アラートポリシーには、通知チャネルのリストを含めることができます。ログエクスプローラで、メニューからチャネルを選択します。これらの値を AlertPolicy 構造で表すには、構成済み NotificationChannel オブジェクトの 1 つ以上のリソース名のリストを指定します。

{ ...
  "notificationChannels": [
    "projects/PROJECT_ID/notificationChannels/CHANNEL_ID"
  ]
}

通知チャンネルを作成すると、リソース名が割り当てられます。リソース名を含む使用可能な通知チャンネルのリストを取得する方法については、Monitoring ドキュメントのチャンネルの取得をご覧ください。Google Cloud コンソールでチャンネル ID を取得することはできません。

Monitoring API にアラートポリシーを送信する

Monitoring API を使用してアラートポリシーを作成するには、AlertPolicy オブジェクトを作成し、それを alertPolicies.create メソッドに送信します。alertPolicies.create を呼び出すには、Google Cloud CLI を使用し、Monitoring API を直接呼び出します。

C#、Go、Java、Python、Ruby のクライアントライブラリを使用して、ログベースのアラートポリシーを作成することもできます。他のクライアントライブラリを使用できる場合もあります。言語のライブラリには、LogMatch 条件タイプが含まれている必要があります。

gcloud CLI を使用してアラートポリシーを作成するには、次の操作を行います。

アラートポリシーの JSON 表現をテキストファイル（例: alert-invalid-ip.json）に追加します。
次のコマンドを使用して、この JSON ファイルを gcloud CLI に渡します。
```
gcloud alpha monitoring policies create --policy-from-file="alert-invalid-ip.json"
```
このコマンドが成功すると、新しいポリシーのリソース名を返します。次に例を示します。
```
Created alerting policy [projects/PROJECT_ID/alertPolicies/POLICY_ID].
```

alertPolicies.create を直接呼び出してアラートポリシーを作成するには、次のように API Explorer ツールを使用します。

alertPolicies.create リファレンスページに移動します。
[この API を試す] ペインで、次の手順を行います。
1. name フィールドに次の値を入力します。
```
projects/PROJECT_ID
```
2. アラートポリシーの JSON 表現をコピーし、API Explorer の [Request body] フィールドの内容を、コピーしたアラートポリシーに置き換えます。
3. [実行] をクリックします。
  
  alertPolicies.create の呼び出しが成功すると、HTTP 200 レスポンスコードと空のレスポンスの本文 {} が返されます。API Explorer の詳細については、Monitoring のドキュメントの API Explorer の使用をご覧ください。

Monitoring API を使用したアラートポリシーの作成の詳細については、ポリシーの作成をご覧ください。このドキュメントの例では、指標ベースのアラートポリシーの条件タイプが使用されていますが原理は同じです。

アラートポリシーをテストする

新しいアラートポリシーをテストするには、ログベースのサンプルアラートのテストと同じ手順を使用できます。

例: ログエントリにテキスト文字列が含まれている場合にアラートポリシーを作成する

この例では、Google Cloud コンソールを使用してアラートポリシーを作成し、ログエクスプローラを使用してログエントリを表示し、Google Cloud CLI を使用してログエントリを書き込みます。

Google Cloud コンソールで、[ログエクスプローラ] ページに移動します。
[ログエクスプローラ] に移動

検索バーを使用してこのページを検索する場合は、小見出しが [Logging] の結果を選択します。
PROJECT_ID の値を更新したら、[クエリ] ペインで次のクエリを入力します。
```
logName="projects/PROJECT_ID/logs/test-log"
textPayload:"Oops"
```
このクエリは、test-log という名前のログを検索して、textPayload フィールドに文字列「Oops」が含まれているログエントリを探します。
[クエリ結果] ツールバーで [アクション] メニューを開き、 [ログアラートの作成] を選択します。ダイアログの項目をすべて入力します。

ポリシーの名前（Alert on Oops など）を入力する必要があります。前のステップで入力したクエリがアラートポリシーに自動的に含まれます。
アラートポリシーをテストするには、Cloud Shell を開いて次のコマンドを実行します。
```
gcloud logging write test-log --severity=ERROR --payload-type=text 'This log entry contains Oops'
```
前のコマンドは、test-log という名前のログにエントリを書き込みます。エントリの重大度は ERROR で、textPayload フィールドがあります。
ログエクスプローラで [クエリを実行] をクリックします。

表示が更新されると、前の手順で書き込んだログエントリの詳細が表示されます。
Google Cloud コンソールで、 [アラート] ページに移動します。
[アラート] に移動

検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

[インシデント] ペインに、インシデントと、アラートポリシーの詳細が表示されます。

[アラート] ページを開いてもインシデントが表示されない場合は、数分待ってからページを更新してください。

Google Cloud CLI コマンドを直ちに繰り返すと、別のインシデントが表示されないか、別の通知が表示されます。アラートポリシーの設定では、インシデント間の最小期間を指定します。これらの設定は、ポリシーを編集することで表示、変更できます。

ログベースのアラート ポリシーを構成する

始める前に

ログ エクスプローラを使用してログベースのアラート ポリシーを作成する

ログベースのアラート ポリシーの例をテストする

その他のシナリオ: 監査ログに関するアラート

シークレットの人的アクセスをモニタリングするアラート ポリシー

復号イベントをモニタリングするアラート ポリシー

Monitoring でログベースのアラート ポリシーを管理する

Monitoring API を使用してログベースのアラート ポリシーを作成する

アラート ポリシーの構造