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

アラートの通知チャネルを構成する

このページでは、アラートを受信するように通知チャンネルを構成するプロセスについて説明します。

通知チャネルは、構成されたアラートの配信メカニズムです。イベントによってアラートがトリガーされると、システムはこれらのチャネルを通じて指定された受信者に通知します。このプロセスにより、重要なアラートが適切な担当者に、希望する連絡手段で確実に届きます。

Google Distributed Cloud（GDC）のエアギャップ環境では、Slack やメールなどの事前定義された通知チャネルは使用できません。アラートを受信するには、少なくとも 1 つのカスタム通知チャネルを構成する必要があります。プロジェクトの Namespace で ObservabilityPipeline カスタムリソースを編集して、チャンネル構成を適用します。

通知チャネルをカスタマイズすることで、管理者は次のことを行えます。

特定の受信者をターゲットにする: 問題の解決を担当する個人、チーム、オンコールローテーションにアラートを直接送信します。
優先するコミュニケーション方法を使用する: SMS、PagerDuty、Webhook、カスタム統合などのチャネルを通じてアラートを配信し、個々の好みや運用ワークフローに対応します。
アラート疲れを防ぐ: ノイズを減らし、対応が必要なユーザーにアラートが確実に届くようにします。

GDC で通知チャンネルを実装するには、管理者がシステム内でチャンネル構成を定義する必要があります。通常、このプロセスでは次のようなパラメータを指定します。

チャネルタイプ: 使用されているチャネルのタイプ。
宛先: システムが通知を送信するエンドポイント。
認証: 宛先にアクセスするために必要な認証情報。

通知チャネルを構成することで、管理者はモニタリングプラットフォームが重要なアラートを効果的に配信し、潜在的な問題に迅速に対応して GDC 環境の安定性とパフォーマンスを維持できるようにします。

始める前に

ObservabilityPipeline カスタムリソースを管理するために必要な権限を取得するには、関連する ObservabilityPipeline ロールのいずれかを付与するよう組織 IAM 管理者またはプロジェクト IAM 管理者に依頼してください。

また、構成ルールを定義するために必要なプロジェクト Namespace の ConfigMap オブジェクトを管理するために必要な権限を取得するには、組織の IAM 管理者またはプロジェクトの IAM 管理者に ConfigMap 作成者のロールを付与するよう依頼してください。

必要なアクセスレベルと権限に応じて、組織またはプロジェクトでこれらのリソースの作成者、編集者、閲覧者のロールを取得できます。詳細については、IAM 権限を準備するをご覧ください。

通知チャンネルを構成する

プロジェクトの Namespace のアラートの通知チャンネルを構成します。

alertmanager.yml という名前の YAML ファイルで、通知チャンネルのカスタム構成を定義します。Alertmanager 仕様と同じ構文に従う必要があります。

https://prometheus.io/docs/alerting/latest/configuration/.
ConfigMap オブジェクトを作成し、alertmanager.yml ファイルのカスタム構成を data フィールドに含めます。

次の例は、alertmanager.yml ファイルを含む ConfigMap オブジェクトの形式を示しています。
```
apiVersion: v1
kind: ConfigMap
metadata:
  name: CONFIGMAP_NAME
  # The namespace must match your project namespace.
  namespace: PROJECT_NAMESPACE
data:
  # The file name must be alertmanager.yml
  alertmanager.yml: |
    # Define your notification channels.
    # Add the custom configuration in the following lines of this file.
    # Follow the same syntax as in https://prometheus.io/docs/alerting/latest/configuration

  [...]
```
次のように置き換えます。
- CONFIGMAP_NAME: ConfigMap 定義ファイルの名前。この名前は、後で ObservabilityPipeline カスタムリソースで使用します。
- PROJECT_NAMESPACE: プロジェクトの Namespace。
構成したアラートと同じ Namespace 内の Management API サーバーに ConfigMap オブジェクトを適用します。
```
kubectl --kubeconfig KUBECONFIG_PATH apply -f CONFIGMAP_NAME.yaml
```
次のように置き換えます。
- KUBECONFIG_PATH: Management API サーバーの kubeconfig ファイルのパス。
- CONFIGMAP_NAME: ConfigMap 定義ファイルの名前。
ObservabilityPipeline カスタムリソース仕様を編集して、構成を alertmanagerConfig フィールドにインポートします。
```
 # Configure the observability pipeline.
apiVersion: observability.gdc.goog/v1
kind: ObservabilityPipeline
metadata:
  # The namespace must match your project namespace.
  namespace: PROJECT_NAMESPACE
  name: OBSERVABILITY_PIPELINE_NAME
spec:
  # Configure alerts.
  alerting:
    # The alerting configuration must be in the ConfigMap.
    # The value must match the ConfigMap name exactly.
    alertmanagerConfig: CONFIGMAP_NAME

  [...]
```
次のように置き換えます。
- PROJECT_NAMESPACE: プロジェクトの Namespace。
- OBSERVABILITY_PIPELINE_NAME: ObservabilityPipeline カスタムリソースの名前。
- CONFIGMAP_NAME: ConfigMap 定義ファイルに使用した名前。名前は完全に一致している必要があります。
注: ObservabilityPipeline カスタムリソースの alerting フィールドで、ボリューム（volumes）やボリュームマウント（volumeMounts）など、プロジェクト Namespace の他の構成を定義することもできます。ボリュームマウント名は alertmanager.yml ファイルで参照します。
ファイルを保存します。
ObservabilityPipeline カスタムリソースの変更を、構成したアラートと同じ Namespace 内の Management API サーバーに適用します。
```
kubectl --kubeconfig KUBECONFIG_PATH apply -f OBSERVABILITY_PIPELINE_NAME.yaml
```
次のように置き換えます。
- KUBECONFIG_PATH: Management API サーバーの kubeconfig ファイルのパス。
- OBSERVABILITY_PIPELINE_NAME: ObservabilityPipeline 定義ファイルの名前。

アラートの通知チャネルを構成する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

始める前に

通知チャンネルを構成する

アラートの通知チャネルを構成する