1.6. アラートの管理


ハブクラスターとマネージドクラスターの変更が通知されるように、可観測性サービスのアラートを受信および定義します。

1.6.1. 前提条件

  • ハブクラスターで可観測性を有効化する。
  • open-cluster-management-observability namespace 内のシークレットリソースに対する作成権限がある。
  • MultiClusterObservability リソースに対する編集権限がある。

1.6.2. Alertmanager の設定

メール、Slack、PagerDuty などの外部メッセージングツールを統合し、Alertmanager から通知を受信します。open-cluster-management-observability namespace で alertmanager-config シークレットを上書きして、統合を追加し、Alertmanager のルートを設定します。以下の手順を実行して、カスタムのレシーバールールを更新します。

  1. alertmanager-config シークレットからデータを抽出します。以下のコマンドを実行します。

    oc -n open-cluster-management-observability get secret alertmanager-config --template='{{ index .data "alertmanager.yaml" }}' |base64 -d > alertmanager.yaml
  2. 以下のコマンドを実行し、alertmanager.yaml ファイル設定を編集して保存します。

    oc -n open-cluster-management-observability create secret generic alertmanager-config --from-file=alertmanager.yaml --dry-run -o=yaml |  oc -n open-cluster-management-observability replace secret --filename=-

    更新したシークレットは以下の内容のようになります。

    global
      smtp_smarthost: 'localhost:25'
      smtp_from: 'alertmanager@example.org'
      smtp_auth_username: 'alertmanager'
      smtp_auth_password: 'password'
    templates:
    - '/etc/alertmanager/template/*.tmpl'
    route:
      group_by: ['alertname', 'cluster', 'service']
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 3h
      receiver: team-X-mails
      routes:
      - match_re:
          service: ^(foo1|foo2|baz)$
        receiver: team-X-mails

変更内容は、変更後すぐに適用されます。Alertmanager の例は、prometheus/alertmanager を参照してください。

1.6.2.1. Alertmanager Pod 内でのシークレットのマウント

任意のコンテンツを含む Secret リソースを作成して、そのリソースを alertmanager Pod 内にマウントして認可認証情報にアクセスすることができます。

Alertmanager 設定内のシークレットを参照するには、open-cluster-management-observability namespace 内に Secret リソースコンテンツを追加し、alertmanager Pod 内にコンテンツをマウントします。たとえば、TLS シークレットを作成してマウントするには、次の手順を実行します。

  1. TLS 証明書を使用して TLS シークレットを作成するには、次のコマンドを実行します。

    oc create secret tls tls --cert=</path/to/cert.crt> --key=</path/to/cert.key> -n open-cluster-management-observability
  2. tls シークレットを MultiClusterObservability リソースにマウントするには、それを advanced セクションに追加します。リソースは以下の内容のようになります。

    ...
    advanced:
     alertmanager:
       secrets: ['tls']
  3. Alertmanager 設定内に tls シークレットの参照を追加するには、シークレットのパスを設定に追加します。リソースは、以下の設定のようになります。

    tls_config:
     cert_file: '/etc/alertmanager/secrets/tls/tls.crt'
     key_file: '/etc/alertmanager/secrets/tls/tls.key'
  4. シークレットが alertmanager Pod 内にあることを確認するには、次のコマンドを実行します。

    oc -n open-cluster-management-observability get secret alertmanager-config --template='{{ index .data "alertmanager.yaml" }}' |base64 -d > alertmanager.yaml

    YAML の内容は次のようになります。

    "global":
      "http_config":
        "tls_config":
          "cert_file": "/etc/alertmanager/secrets/storyverify/tls.crt"
          "key_file": "/etc/alertmanager/secrets/storyverify/tls.key"
  5. alertmanager.yaml 設定を alertmanager-config シークレットに保存するには、以下のコマンドを実行します。

    oc -n open-cluster-management-observability create secret generic alertmanager-config --from-file=alertmanager.yaml --dry-run -o=yaml
  6. 以前のシークレットを新しいシークレットに置き換えるには、次のコマンドを実行します。

    oc -n open-cluster-management-observability replace secret --filename=-

1.6.3. アラートの転送

可観測性を有効にした後には、OpenShift Container Platform マネージドクラスターからのアラートは自動的にハブクラスターに送信されます。alertmanager-config YAML ファイルを使用して、外部通知システムでアラートを設定できます。

alertmanager-config YAML ファイルの例を以下に示します。

global:
  slack_api_url: '<slack_webhook_url>'

route:
  receiver: 'slack-notifications'
  group_by: [alertname, datacenter, app]

receivers:
- name: 'slack-notifications'
  slack_configs:
  - channel: '#alerts'
    text: 'https://internal.myorg.net/wiki/alerts/{{ .GroupLabels.app }}/{{ .GroupLabels.alertname }}'

アラート転送用のプロキシーを設定する場合は、alertmanager-config YAML ファイルに次の global エントリーを追加します。

global:
  slack_api_url: '<slack_webhook_url>'
  http_config:
    proxy_url: http://****

1.6.3.1. マネージドクラスターのアラート転送の無効化

マネージドクラスターのアラート転送を無効にするには、次のアノテーションを MultiClusterObservability カスタムリソースに追加します。

metadata:
      annotations:
        mco-disable-alerting: "true"

アノテーションを設定すると、マネージドクラスターのアラート転送設定が元に戻ります。openshift-monitoring namespace の ocp-monitoring-config config map に加えられた変更も元に戻ります。アノテーションを設定すると、ocp-monitoring-config config map が可観測性 Operator のエンドポイントによって管理または更新されなくなります。設定を更新すると、マネージドクラスターの Prometheus インスタンスが再起動します。

重要: メトリクス用の永続ボリュームを持つ Prometheus インスタンスがある場合、マネージドクラスターのメトリクスは失われ、Prometheus インスタンスが再起動されます。ハブクラスターからのメトリクスは影響を受けません。

変更が元に戻ると、cluster-monitoring-reverted という名前の ConfigMap が open-cluster-management-addon-observability namespace に作成されます。手動で追加された新しいアラート転送設定は、ConfigMap から元に戻りません。

ハブクラスターアラートマネージャーがマネージドクラスターアラートをサードパーティーのメッセージングツールに伝達していないことを確認します。前のセクション Alertmanager の設定 を参照してください。

1.6.4. アラートをサイレントにする

受信したくないアラートを追加します。アラート名、一致ラベル、または期間によってアラートをサイレントにすることができます。サイレントにしたいアラートを追加すると、ID が作成されます。サイレントにしたアラートの ID は、文字列 d839aca9-ed46-40be-84c4-dca8773671da のようになります。

アラートをサイレントにする方法は、引き続きお読みください。

  • Red Hat Advanced Cluster Management アラートをオフにするには、open-cluster-management-observability namespace の alertmanager Pod にアクセスできる必要があります。たとえば、SampleAlert をオフにするには、observability-alertmanager-0 Pod ターミナルで次のコマンドを実行します。

    amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" alertname="SampleAlert"
  • 複数の一致ラベルを使用してアラートをサイレントにします。次のコマンドは match-label-1match-label-2 を使用します。

    amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" <match-label-1>=<match-value-1> <match-label-2>=<match-value-2>
  • 特定の期間アラートをサイレントにする場合は、--duration フラグを使用します。次のコマンドを実行して、SampleAlert を 1 時間サイレントにします。

    amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" --duration="1h" alertname="SampleAlert"

    消音アラートの開始時刻または終了時刻を指定することもできます。次のコマンドを入力して、特定の開始時刻に SampleAlert をサイレントにします。

    amtool silence add --alertmanager.url="http://localhost:9093" --author="user" --comment="Silencing sample alert" --start="2023-04-14T15:04:05-07:00" alertname="SampleAlert"
  • 作成されたサイレント化されたアラートをすべて表示するには、次のコマンドを実行します。

    amtool silence --alertmanager.url="http://localhost:9093"
  • アラートをサイレントにしたくない場合は、次のコマンドを実行してアラートのサイレントを終了します。

    amtool silence expire --alertmanager.url="http://localhost:9093" "d839aca9-ed46-40be-84c4-dca8773671da"
  • すべてのアラートをサイレントにするのを終了するには、次のコマンドを実行します。

    amtool silence expire --alertmanager.url="http://localhost:9093" $(amtool silence query --alertmanager.url="http://localhost:9093" -q)

1.6.4.1. 可観測性ストレージの移行

アラートサイレンサーを使用する場合は、サイレンサーを以前の状態のまま保持しながら、可観測性ストレージを移行できます。これを行うには、選択した StorageClass リソースを使用する新しい StatefulSets および PersistentVolumes (PV) リソースを作成して、Red Hat Advanced Cluster Management の可観測性ストレージを移行します。

注記: PV のストレージは、クラスターから収集されたメトリクスを保存するために使用されるオブジェクトストレージとは異なります。

StatefulSet と PV を使用して可観測性データを新しいストレージに移行すると、次のデータコンポーネントが保存されます。

  • Observatorium または Thanos: データを受信してオブジェクトストレージにアップロードします。一部のコンポーネントは PV にデータを保存します。このデータは、Observatorium または Thanos が起動時にオブジェクトストレージを自動的に再生成するため、このデータを失っても影響はありません。
  • Alertmanager: サイレント化されたアラートのみを保存します。これらのサイレントアラートを保持する場合は、そのデータを新しい PV に移行する必要があります。

可観測性ストレージを移行するには、次の手順を実行します。

  1. MultiClusterObservability で、.spec.storageConfig.storageClass フィールドを新しいストレージクラスに設定します。
  2. PersistentVolumeClaim を削除しても以前の PersistentVolumes のデータが保持されるようにするために、既存のすべての PersistentVolumes に移動します。
  3. reclaimPolicy"Retain": `oc patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' に変更します。
  4. オプション: データの損失を回避するには、Migrate persistent data to another Storage Class in DG 8 Operator in OCP 4 を参照してください。
  5. 次の StatefulSet の場合、StatefulSetPersistentVolumeClaim の両方を削除します。

    1. alertmanager-db-observability-alertmanager-<REPLICA_NUMBER>
    2. data-observability-thanos-<COMPONENT_NAME>
    3. data-observability-thanos-receive-default
    4. data-observability-thanos-store-shard
    5. 重要: 新しい StatefulSet を作成するには、MultiClusterObservability Operator Pod を削除してから再作成する必要がある場合があります。
  6. 同じ名前で正しい StorageClass を使用して新しい PersistentVolumeClaim を再作成します。
  7. 古い PersistentVolume を参照する新しい PersistentVolumeClaim を作成します。
  8. 新しい StatefulSetPersistentVolumes が、選択した新しい StorageClass を使用していることを確認します。

1.6.5. アラートの抑制

重大度の低い Red Hat Advanced Cluster Management アラートをクラスター全体でグローバルに抑制します。アラートを抑制するには、open-cluster-management-observability namespace の alertmanager-config で抑制ルールを定義します。

抑制ルールは、既存のマッチャーの別のセットと一致する一連のパラメーター一致がある場合にアラートをミュートします。ルールを有効にするには、ターゲットアラートとソースアラートの両方で、equal リスト内のラベル名のラベル値が同じである必要があります。Inhibit_rules は次のようになります。

global:
  resolve_timeout: 1h
inhibit_rules:1
  - equal:
      - namespace
    source_match:2
      severity: critical
    target_match_re:
      severity: warning|info
1 1
hibit_rules パラメーターセクションは、同じ namespace のアラートを検索するために定義されています。critical アラートがネームスペース内で開始し、その namespace に重大度レベルの warning または info を含む他のアラートがある場合は、critical アラートのみが Alertmanager レシーバーにルーティングされます。一致するものがあった場合、次のアラートが表示される場合があります。
ALERTS{alertname="foo", namespace="ns-1", severity="critical"}
ALERTS{alertname="foo", namespace="ns-1", severity="warning"}
2 2
source_match パラメーターと target_match_re パラメーターの値が一致しない場合、アラートはレシーバーにルーティングされます。
ALERTS{alertname="foo", namespace="ns-1", severity="critical"}
ALERTS{alertname="foo", namespace="ns-2", severity="warning"}
  • Red Hat Advanced Cluster Management で抑制されたアラートを表示するには、次のコマンドを入力します。
amtool alert --alertmanager.url="http://localhost:9093" --inhibited

1.6.6. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.