Container Service for Kubernetes:登録済みクラスターのアラートを設定する

onectl の使用

1. オンプレミスマシンに onectl をインストールします。詳細については、「onectl を使用して登録済みクラスターを管理する」をご参照ください。

2. Cloud Monitor コンポーネントに Resource Access Management (RAM) 権限を付与します。

   onectl ram-user grant --addon alicloud-monitor-controller

   予想される出力:

   Ram policy ack-one-registered-cluster-policy-alicloud-monitor-controller granted to ram user ack-one-user-ce313528c3 successfully.

コンソールの使用

登録済みクラスターにコンポーネントをインストールする前に、Alibaba Cloud サービスにアクセスするための AccessKey ペアを取得する必要があります。AccessKey ペアを作成するには、まず RAM ユーザーを作成し、その RAM ユーザーにクラウドリソースにアクセスするために必要な権限を付与する必要があります。

1. RAM ユーザーの作成。

2. カスタムポリシーの作成。次のコードは例です。

   {
               "Action": [
                   "log:*",
                   "arms:*",
                   "cms:*",
                   "cs:UpdateContactGroup"
               ],
               "Resource": [
                   "*"
               ],
               "Effect": "Allow"
   }

3. RAM ユーザーへの権限付与。

4. RAM ユーザーの AccessKey ペアを作成します。

   警告

   ネットワークアクセス制御のために AccessKey ペアベースのポリシーを設定し、AccessKey の呼び出し元を信頼できるネットワーク環境に限定して AccessKey のセキュリティを強化することをお勧めします。

5. AccessKey ペアを使用して、登録済みクラスターに alibaba-addon-secret という名前の Secret を作成します。

   Cloud Monitor コンポーネントをインストールすると、システムはこの AccessKey ペアを自動的に使用して、必要なクラウドリソースにアクセスします。

   kubectl -n kube-system create secret generic alibaba-addon-secret --from-literal='access-key-id=<your access key id>' --from-literal='access-key-secret=<your access key secret>'

   説明

   <your access key id> と <your access key secret> を、取得した AccessKey ペアに置き換えてください。

onectl の使用

Cloud Monitor コンポーネントをインストールします。

onectl addon install alicloud-monitor-controller

予想される出力:

Addon alicloud-monitor-controller, version **** installed.

コンソールの使用

コンソールは、アラート設定が要件を満たしているかどうかを自動的にチェックし、コンポーネントのアクティブ化、インストール、またはアップグレードをガイドします。

1. ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。

2. クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のペインで、[運用] > [アラート] を選択します。

3. [アラート] ページで、画面の指示に従ってコンポーネントをインストールまたはアップグレードします。

4. インストールまたはアップグレードが完了したら、[アラート] ページに移動してアラート情報を設定します。

   タブ	説明
   アラートルール管理	ステータス: ターゲットのアラートルールセットをオンまたはオフにします。 通知オブジェクトの編集: アラート通知の連絡先グループを設定します。 これを設定する前に、連絡先とグループを作成し、連絡先をグループに追加します。通知オブジェクトとして選択できるのは連絡先グループのみです。個人に通知するには、その連絡先のみを含むグループを作成し、そのグループを選択します。
   アラート履歴	過去 24 時間の最新 100 件のアラートレコードを表示できます。 [アラートルール] 列のリンクをクリックして、対応する監視システムに移動し、詳細なルール設定を表示します。 [トラブルシューティング] をクリックして、異常が発生したリソース (異常イベントまたはメトリック) をすばやく特定します。 [インテリジェント分析] をクリックして、AI アシスタントを使用して問題を分析し、トラブルシューティングのガイダンスを提供します。
   連絡先管理	連絡先を管理します。連絡先の作成、編集、削除ができます。 連絡方法: 電話/ショートメッセージ: 連絡先に携帯電話番号を設定すると、連絡先は電話とショートメッセージでアラート通知を受信できます。 電話通知を受信するために使用できるのは、認証済みの携帯電話番号のみです。携帯電話番号の認証方法の詳細については、「携帯電話番号を認証する」をご参照ください。 メール: 連絡先にメールアドレスを設定すると、連絡先はメールでアラート通知を受信できます。 ロボット: DingTalk ロボット、WeCom ロボット、Lark ロボット。 DingTalk ロボットの場合、セキュリティキーワードとして「Alerting」、「Dispatch」を追加する必要があります。 メールとロボットの通知を設定する前に、CloudMonitor コンソールでそれらを検証します。[アラートサービス] > [アラート連絡先] を選択して、アラート情報を受信できることを確認します。
   連絡先グループ管理	連絡先グループを管理します。連絡先グループの作成、編集、削除ができます。[通知オブジェクトの編集] では、連絡先グループのみを選択できます。 連絡先グループが存在しない場合、コンソールは Alibaba Cloud アカウント情報に基づいてデフォルトの連絡先グループを作成します。

コンソール

1. ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。

2. クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のペインで、[運用] > [アラート] を選択します。

3. [アラートルール管理] タブで、右上隅にある [アラート設定の編集] をクリックします。次に、ターゲットルールの [アクション] 列にある [YAML] をクリックして、現在のクラスターの AckAlertRule リソース設定を表示します。

4. 必要に応じて YAML ファイルを変更します。詳細については、「デフォルトのアラートルールテンプレート」をご参照ください。

   次のコードは、アラートルールの YAML 設定のサンプルを示しています。

   アラートルール設定 YAML

   apiVersion: alert.alibabacloud.com/v1beta1
   kind: AckAlertRule
   metadata:
     name: default
   spec:
     groups:
       # 次のコードは、クラスターイベントアラートルールのサンプル設定です。
       - name: pod-exceptions                             # アラートルールグループの名前。これは、アラートテンプレートの Group_Name フィールドに対応します。
         rules:
           - name: pod-oom                                # アラートルールの名前。
             type: event                                  # アラートルールのタイプ (Rule_Type)。有効な値: event (イベントタイプ) と metric-cms (CloudMonitor メトリックタイプ)。
             expression: sls.app.ack.pod.oom              # アラートルール式。ルールタイプが event の場合、このパラメーターの値は、このトピックのデフォルトのアラートルールテンプレートの Rule_Expression_Id の値です。
             enable: enable                               # アラートルールのステータス。有効な値: enable と disable。
           - name: pod-failed
             type: event
             expression: sls.app.ack.pod.failed
             enable: enable
       # 次のコードは、基本的なクラスターリソースアラートルールのサンプル設定です。
       - name: res-exceptions                              # アラートルールグループの名前。これは、アラートテンプレートの Group_Name フィールドに対応します。
         rules:
           - name: node_cpu_util_high                      # アラートルールの名前。
             type: metric-cms                              # アラートルールのタイプ (Rule_Type)。有効な値: event (イベントタイプ)、metric-cms (CloudMonitor メトリック)、および metric-prometheus (Prometheus メトリック)。
             expression: cms.host.cpu.utilization          # アラートルール式。ルールタイプが metric-cms の場合、このパラメーターの値は、このトピックのデフォルトのアラートルールテンプレートの Rule_Expression_Id の値です。
             contactGroups:                                # アラートルールの連絡先グループ設定。これは ACK コンソールによって生成されます。連絡先は同じアカウントで同じであり、複数のクラスターで再利用できます。
             enable: enable                                # アラートルールのステータス。有効な値: enable と disable。
             thresholds:                                   # アラートルールのしきい値。          
               - key: CMS_ESCALATIONS_CRITICAL_Threshold
                 unit: percent
                 value: '85'                                # CPU 使用率のしきい値。デフォルト: 85%。    
               - key: CMS_ESCALATIONS_CRITICAL_Times
                 value: '3'                                # しきい値を 3 回連続で超えるとアラートがトリガーされます。
               - key: CMS_RULE_SILENCE_SEC                 # 最初のアラートが報告された後の解約待機期間。 
                 value: '900'    

   rules.thresholds を使用して、アラートのしきい値をカスタマイズできます。パラメーターの詳細については、次の表をご参照ください。たとえば、上記の設定では、クラスターノードの CPU 使用率が 3 回連続のチェックで 85% を超え、前回のアラートが 900 秒以上前にトリガーされた場合にアラート通知がトリガーされます。

   パラメーター	必須	説明	デフォルト値
   CMS_ESCALATIONS_CRITICAL_Threshold	必須	アラートのしきい値。このパラメーターが設定されていない場合、ルールの同期に失敗し、無効になります。 unit: 単位。percent、count、または qps に設定できます。 value: しきい値。	デフォルトのアラートテンプレート設定に依存します。
   CMS_ESCALATIONS_CRITICAL_Times	オプション	CloudMonitor ルールの再試行回数。設定されていない場合は、デフォルト値が使用されます。	3
   CMS_RULE_SILENCE_SEC	オプション	CloudMonitor が異常によりルールを継続的にトリガーしたときに、最初のアラートが報告された後の解約待機期間 (秒単位)。これにより、アラート疲れを防ぎます。設定されていない場合は、デフォルト値が使用されます。	900

kubectl

1. 次のコマンドを実行して、アラートルールの YAML ファイルを編集します。

   kubectl edit ackalertrules default -n kube-system

2. 必要に応じて YAML ファイルを変更し、保存して終了します。詳細については、「デフォルトのアラートルールテンプレート」をご参照ください。

   アラートルール設定 YAML

   apiVersion: alert.alibabacloud.com/v1beta1
   kind: AckAlertRule
   metadata:
     name: default
   spec:
     groups:
       # 次のコードは、クラスターイベントアラートルールのサンプル設定です。
       - name: pod-exceptions                             # アラートルールグループの名前。これは、アラートテンプレートの Group_Name フィールドに対応します。
         rules:
           - name: pod-oom                                # アラートルールの名前。
             type: event                                  # アラートルールのタイプ (Rule_Type)。有効な値: event (イベントタイプ) と metric-cms (CloudMonitor メトリックタイプ)。
             expression: sls.app.ack.pod.oom              # アラートルール式。ルールタイプが event の場合、このパラメーターの値は、このトピックのデフォルトのアラートルールテンプレートの Rule_Expression_Id の値です。
             enable: enable                               # アラートルールのステータス。有効な値: enable と disable。
           - name: pod-failed
             type: event
             expression: sls.app.ack.pod.failed
             enable: enable
       # 次のコードは、基本的なクラスターリソースアラートルールのサンプル設定です。
       - name: res-exceptions                              # アラートルールグループの名前。これは、アラートテンプレートの Group_Name フィールドに対応します。
         rules:
           - name: node_cpu_util_high                      # アラートルールの名前。
             type: metric-cms                              # アラートルールのタイプ (Rule_Type)。有効な値: event (イベントタイプ) と metric-cms (CloudMonitor メトリックタイプ)。
             expression: cms.host.cpu.utilization          # アラートルール式。ルールタイプが metric-cms の場合、このパラメーターの値は、このトピックのデフォルトのアラートルールテンプレートの Rule_Expression_Id の値です。
             contactGroups:                                # アラートルールの連絡先グループ設定。これは ACK コンソールによって生成されます。連絡先は同じアカウントで同じであり、複数のクラスターで再利用できます。
             enable: enable                                # アラートルールのステータス。有効な値: enable と disable。
             thresholds:                                   # アラートルールのしきい値。          
               - key: CMS_ESCALATIONS_CRITICAL_Threshold
                 unit: percent
                 value: '85'                                # CPU 使用率のしきい値。デフォルト: 85%。    
               - key: CMS_ESCALATIONS_CRITICAL_Times
                 value: '3'                                # しきい値を 3 回連続で超えるとアラートがトリガーされます。
               - key: CMS_RULE_SILENCE_SEC                 # 最初のアラートが報告された後の解約待機期間。 
                 value: '900'    

   rules.thresholds を使用して、アラートのしきい値をカスタマイズできます。たとえば、上記の設定では、クラスターノードの CPU 使用率が 3 回連続のチェックで 85% を超え、前回のアラートが 900 秒以上前にトリガーされた場合にアラート通知がトリガーされます。

   パラメーター	必須	説明	デフォルト値
   CMS_ESCALATIONS_CRITICAL_Threshold	必須	アラートのしきい値。このパラメーターが設定されていない場合、ルールの同期に失敗し、無効になります。 unit: 単位。percent、count、または qps に設定できます。 value: しきい値。	デフォルトのアラートテンプレート設定に依存します。
   CMS_ESCALATIONS_CRITICAL_Times	オプション	CloudMonitor ルールの再試行回数。設定されていない場合は、デフォルト値が使用されます。	3
   CMS_RULE_SILENCE_SEC	オプション	CloudMonitor が異常によりルールを継続的にトリガーしたときに、最初のアラートが報告された後の解約待機期間 (秒単位)。これにより、アラート疲れを防ぎます。設定されていない場合は、デフォルト値が使用されます。	900